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).

No, disabling the timers is completely the wrong approach. The service belonging to the timer unit has built-in logic to do only what it was configured to do + some cleanup work that we always want to have done.
All you need to do to disable upgrades is to disable them in GNOME Software as well as in software-sources-gtk which is available in GNOME Software's burger-menu as well.
See the attached picture:

It appears that one *cannot* shut off updates with GNOME Software despite the settings that would imply that this is possible. What needs to be address is apt-daily-upgrade.timer. systemctl status apt-daily-upgrade.timer says;

● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
     Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Fri 2020-12-11 10:07:48 EST; 2 weeks 5 days ago
    Trigger: Thu 2020-12-31 06:28:21 EST; 10h left
   Triggers: ● apt-daily-upgrade.service

This can be disabled which ought to turn off automatic updates. Stop the timer and disable this way;

sudo systemctl stop apt-daily-upgrade.timer
sudo systemctl disable apt-daily-upgrade.timer

I am working on getting this into Debian - There's already a Ubuntu PPA, whos maintainer I have mailed and asked if they are interested in maintaining it in Debian - If they are not, I'll ITP it, and maintain it myself.

I am in the same boat. My Lib15v4 Secure Boot. I thought came out of the box preconfigured with dual drives that I spec'd when I placed my order. I would like to make sure that both drives are properly encrypted.

luks cryptsetup- trying to change encrypt pw
I see the warning, about using GNOME Disks to change the pw. I went to the link https://tracker.pureos.net/T541, and checked for updates to the string. Seems that mladen posted an update back in June 2020 that this issue was resolved. "Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928893 indicates that this has been fixed."
We are now headed in Jan 2021, can anyone confirm this to be true? I would prefer not to be the "ginny pig".
I tried the terminal route first and ran into some issues and did not work out as described above. My drives are set up differently, I have two drives in this machine and not listed as sda's.
Before I dove down that rabbit hole, I figured I would revisit using GNOME Disks, as it would be far easier, if its safe.
I don't have a virtual machine set up yet to test it out on.
Feedback please.
12-30-20 update- used the GNOME Disks and reset the passphrase with no issues.

I reported this issue on my own (not driven by reports of others but from my prior knowledge in maintaining PureBrowser and therefore pretty exactly knowing how they differ).

The plan that was devised consists of two steps;

@jonas.smedegaard Did a user report this? Or is this bug from your own sleuthing? :-) I ask because sometimes the FSF rewards users who report freedom issues with GNU Bucks and there may be some at stake for reporting.

BTW, though I do not know what caused this, I am glad it happened. I had 86 updates awaiting that I never knew about.

Glad you tracked down the issue! Nice sleuthing!

I was finally able to make this work by erasing repo.puri.sm_pureos_dists_amber_main_binary-amd64_Packages in /var/lib/apt/lists and then doing the 'apt update.' I am not sure why this did not work by simply doing apt update, but it seems to have gotten stuck somehow.

This is important as we do not want to implement any browser prompt to install an EME plugin.

Jeremiah, you were correct. There is a difference in versions, but I do not know why my apt database has a different one, i.e. python-libxml2_2.9.4+dfsg1-7+b3_amd64.deb. I tried to purge it and get the new listing, but to no avail.

As I mentioned in my initial post, I already tried the 'update' and the --fix-missing, so your commands yield the same errors as I have mentioned before. Have you checked that the file is actually on repo.puri.sm?

What does sudo apt-update && sudo apt install python-libxml2 say?

@jeremiah.foster Yes, that repo is pulled from Debian. We are good to go with that one.

Let's pull tootle in from Debian. If there's a flatpak or package that we need in Debian then we should just default to using that.

@jeremiah.foster this on is up to date, https://source.puri.sm/librem5-apps/tootle

@jeremiah.foster I can't build Flatpaks inside of the bizantium-arm64 docker image because of this,
"Running in qemu-user, not using seccomp"
I can only build flatpaks over Intel since I don't have the right hardware to do it.

@jeremiah.foster created a repo https://source.puri.sm/librem5-apps/shortwave and pushed the flatpak built into our SLAT server, inside of /home/adrian/flatpak/shortwave/app, there is where the flatpak build it is

@jeremiah.foster our version is the same as salsa I think this one is already completed

@jeremiah.foster debian has the latest version on unstable for this one, we should build it anyway or use the one at debian?

No. The package does not appear to be in the actual repos (repo.puri.sm), even though 'apt' and your link say it should be there.

But the issue is not that you can't see it in the repos - just that it won't install on your machine, right?

No, please complete or report here if you are having issues.

@jeremiah.foster Yes, I should stop?

This is what I see for that command:

Amber is Buster, yes.

Thanks. I understand there is a transition here. I will close this, but