Note that on the phone side we use a separate system to allow for this but it woudl be great if laneakia would handle that natively since this would shorten the pipeline where anything could go wrong and it makes it quicker to spot problems.

A likey simple way would be to assume a fixed location in gitlab like

Still working on this flatpak

I'm working on a flatpak for Tootle

Uh, because this website doesn't move me to the newly created issue, when I wanted to edit my issue I accidentally created a new one, mistaking the remaining issue creation page as an edition page… it's now a duplicate of https://tracker.pureos.net/T1004.

https://serverfault.com/a/950568 mentions intermittent OCSP failures tied to IPv6.

https://stackoverflow.com/a/60243923 mentions how to disable OCSP for apt:

touch /etc/apt/apt.conf.d/99verify-peer.conf \
&& echo >>/etc/apt/apt.conf.d/99verify-peer.conf "Acquire { https::Verify-Peer false }"

maybe relevant to your research:
curl -O https://repo.pureos.net/pureos/dists/amber/main/source/Sources.xz works fine,
but curl -O --cert-status https://repo.pureos.net/pureos/dists/amber/main/source/Sources.xz fails:

curl: (91) No OCSP response received

Commit https://github.com/systemd/systemd/pull/18552/files disabled the Purism keyboard rules in systemd upstream.

Phabricator's API is called conduit. I can pull data from conduit and it looks like this;

gitlab would be nice too but likely fine grained (e.g. calls -> calls channel, phosh/phoc/squeekboard -> phosh channel) - we had a bug for that somewhere in gitlab iirc, the above is about the pureos tracker only.

@jeremiah.foster: please don't discuss [multiple issues] issues directly, but instead file a separate issue report for the part you have input on and discuss it there.

I think "blobs" is tricky terminology which might confuse - it confuses me. I prefer talking about 'firmware'. Firmware is stored in Read Only Memory (ROM) as a binary. It usually cannot be changed and it just meant to make the hardware work at all. The FSF says "Firmware that is installed during use is software; firmware that is delivered inside the device and can't be changed is software by nature, but we can treat it as if it were a circuit." This makes firmware closer, or even the same as, hardware. And while all hardware should have free designs, like Purism's, we don't have to reject non-free hardware the way we have to reject non-free software according to the FSF.

Do we need or want a channel from Gitlab to Matrix too?

Is this a Tracker <--> Matrix channel? We already have #dev/pureos-changes so you don't mean that channel I assume.

to add some context:

I've been informed that it is at least *theoretically* possible to point snapd to a only free "store" https://forum.snapcraft.io/t/external-repositories/1760/7
This might help us not have to remove snapd and then patch and maintain all the software that depends on snap and snapd.

This issue is not about what is acceptable for people hired by or representing Purism to do.

Might be cool to put that documentation here: https://tracker.pureos.net/w/development/

Although I agree that people at Purism shouldn't instruct how to install proprietary software, It would be difficult to forbid instructions or discussions about installing or upgrading Coreboot, which still contains blobs.

@evangelos.tzaras for phone development you'd usually not use dput.

i was just wondering under which circumstances i would use dput?
my understanding was that when pushing a signed tag in the packaging repos (those which are pointed to from deb-build-jobs (?)) that the build server would automagically start the build.

I am unaware of any issues with Firefox ESR violating the FSF Free System Distribution Guidelines.
We are aware of a some issues that might violate FSDG, and we are examining each of those individually.

I am unaware of any issues with Chromium violating the FSF Free System Distribution Guidelines.

Thanks again. You can do that now at T992.

OK @jonas.smedegaard ! I'll copy-paste-crop my comment on the proper issue when it's ready! ;)

thanks for your input, @francois - but please wait until this multi-issue has been broken into parts before contributing further, because a) it is too difficult to discuss multiple issues at once in this interface, and b) it is not possible to reassign comments to other more narrow-scoped issue reports once made.

Regarding the first issue, although I agree that people at Purism shouldn't instruct how to install proprietary software (especially this kind of critical drivers!), It would be difficult to forbid instructions or discussions about installing or upgrading Coreboot, which still contains blobs.