I did two runs of 1000 calls to the server and did not see any anomalies.

This is a good idea @guido, thanks for logging this. Package reproducibility is easy to test with reprotest, I'll check with @mak to see where we can include this.

I also tried messing with timeouts on APTs transport methods, with no luck - according to APT, the server just stops responding (according to curl though, it doesn't).

I pasted the wrong log, but the connection timeout is actually even more frequent now than the Resource temporarily unavailable issue - but both appear.

I tested this with https::Verify-Peer false, still the same issue happens:

Fetched 1016 MB in 4min 12s (4025 kB/s)                                        
2021/03/04 22:30:39 apt | E: Failed to fetch https://repo.pureos.net/pureos/pool/main/f/fftw3/libfftw3-double3_3.3.8-2_amd64.deb  Connection timed out [IP: 138.201.228.45 443]
2021/03/04 22:30:39 apt | E: Failed to fetch https://repo.pureos.net/pureos/pool/main/s/spice-gtk/libspice-client-glib-2.0-8_0.39-1_amd64.deb  Connection timed out [IP: 138.201.228.45 443]
2021/03/04 22:30:39 apt | E: Failed to fetch https://repo.pureos.net/pureos/pool/main/libs/libsodium/libsodium23_1.0.18-1_amd64.deb  Connection timed out [IP: 138.201.228.45 443]
2021/03/04 22:30:39 apt | E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

removed from landng as per request

odd tarball in the archive - lets revisit for > 0.4.0

cleaned up in landing

we can close this since we can't clean it up for byzantium due to a tarball checksum mismatch - i lack the power to close bugs thouh.

https://tracker.pureos.net/w/development/synchrotron/

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.