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.

Similar issue:

The idea of "shadowing" upstream or downstream as the case may be seems pretty useful though my brain is more accustomed to having the PureOS version of a package be higher.

just to add - this is during video playback (e.g. YouTube)

we have it in byzantium and amber-phone hence this can be closed.

I did these steps and now my installation ends up on a black screen with a flashing cursor.

AppStream is more for app meta-data while apt-file basically searches a directory of ASCII text to find specific files inside packages. I'm not sure if you could use AppStream as an apt-file replacement.

Since we have AppStream and this feature isn't one of the most popular ones, its priority is low.

Basically my fear is that people will end up having chromium installed in their systems 📦

@mak pinging you here because the changelog of these packages indicates you were the last person to update them. But feel free to assign to someone else 😄

If this is an issue with Thunderbird, it should be filed upstream

I have gnome-authenticator and its dependencies (pyfavicon, pyzbar and yoyo) backported to amber-phone locally on my phone already, just need to push it out and set up CI.

I don't think it's feasible to package Fractal for amber-phone; however, it should be possible to have it in byzantium. Mobian has a preliminary packaging at https://gitlab.com/mobian1/packages/fractal

Thanks Sebastian! Let's find another package @alvesadrian

@alvesadrian FWIW you don't need to build flatpaks inside a docker container; flatpak-builder already builds apps using a contained environment.

Tootle is now in byzantium and a amber-phone backport is waiting in NEW at the moment.

Already available in amber-phone-staging and byzantium: https://software.pureos.net/package/bin/byzantium/giara

This is not a bug report. If you forgot your password that is not an OS' issue.

Just to be clear: this is about https://repo.pureos.net/pureos-debug/dists/amber-debug/main/binary-arm64/Packages.xz and https://repo.pureos.net/pureos-debug/dists/byzantium-debug/main/binary-arm64/Packages.xz being empty (hence making debugging problems on user systems basically impractical).

I'm the maintainer of the firmware-ath9k-htc package in Debian which applies to this hardware. Unfortunately it is not installed by default in Debian or PureOS, but it should work after being installed and possibly rebooting/reinserting the device. The firmware is installed under a non-standard file name as you've noticed, but the package comes with a configuration file that should enable it to be recognized under that name.

related issues in the upstream issue tracker: https://github.com/calamares/calamares/issues?q=is:issue+is:open+lvm+label:"N+lvm2"

I just tried to delete the partitions and let the installer create them. It still does not ask for a LUKS passphrase and crashes. I also tried manually setting up partitions, LUKS, LVM and various combinations before running the installer. I don't know how I got this to work before but it always crashes now. Seems that PureOS no longer likes me (it was a difficult relationship to begin with).

I just ran into this issue. I have installed PureOS with encrypted root before and dont remember allowing it to create the partitions but it seems that way based on reading this. I would prefer not to delete the partitions every time I have to re-install (with PureOS is about every 6 months).

Has this been done? I think only sysadmins have the necessary privileges to destroy a user account, all I can do is disable them.

Then this should have worked - they should verify that /etc/apt/apt.conf.d/20auto-upgrades exists and has the correct values.

In T978#17857, @mak wrote:

the issue is the "Software & Updates > Updates > Automatically check for updates: Never" configuration is not preventing the system from automatically checking for updates every day.

they have to do that *and* disable updates in GNOME: "GNOME Software" > "Burger Menu" > "Update Preferences" > Toggle Automatic Updates
(as shown in the image I posted above)

the issue is the "Software & Updates > Updates > Automatically check for updates: Never" configuration is not preventing the system from automatically checking for updates every day.

The Original Poster is stating that their use case is customers at sea who have expensive connection charges which require they disable unnecessary network communication.

The user writes back saying that they disabled GNOME Software and was unable to stop automatic upgrades. There is no effect of the GNOME Software settings observed. I think the next step on my side is to run strace on GNOME Software and settings to see what is happening (or not happening).