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.

thanks @mak !

Done :-)

Fixed now. Apparently dak forgot a source package... Not sure how that happened, this could only occur if something was manually deleted the wrong way, or a bad database backup was restored...
It's fixed now though, and I checked for any more of this kind of issue and found none.

Noticed this too late because the warning email went straight to spam (the attached logfile apparently was suspicious).
This is caused by either a dak bug or something feeding dak bad data:

  File "/srv/dist/dak/daklib/archive.py", line 164, in install_binary
    .filter(Suite.suite_id == source_suites.c.id)
AttributeError: 'NoneType' object has no attribute 'c'

nginx error log on Artemis is saying:

Can be closed, we have a working store now.

Both amber-phone and byzantium have now adaptive versions of iagno.

@jeremiah.foster how did i get pulled in here?

Get:289 https://repo.pureos.net/pureos byzantium/main arm64 xdg-user-dirs arm64 0.17-2 [53.2 kB]
E: Failed to fetch https://repo.pureos.net/pureos/pool/main/c/chardet/python3-chardet_4.0.0-1_all.deb Error reading from server - read (5: Input/output error) [IP: 138.201.228.45 443]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Fetched 94.6 MB in 9s (10.1 MB/s)

@guido - have you seen this issue?

This should be fixed in later versions.