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

This may be caught in a transition from python2.7 to python3 in Debian. python2.7 is approaching end of life and will be deprecated soon. I see that libxml2 is support with another library for python3;

python3-lxml - pythonic binding for the libxml2 and libxslt libraries

It may be that the chirp application has not yet updated their python dependencies.

@alvesadrian Have you started on this one yet?

Good morning, i have installed Linux PureOS in pc but the WiFi icon does not exist on PureOS, it said that 'WiFi adapter not found. I have a High Gain Wireless Usb adapter TP-LINK, TL-WN722N, V1.10. I´ m new in Linux. Please help me.

I agree with Matthias here - having updates on by default brings security fixes quickly and is something that many folks now have come to expect. Much better to request that users opt out of secure default settings. This comports with Todd's stated policy of "smart defaults".

closing as a duplicate

Plan is to package as flatpak.

Why? We want the users to stay secure by default, and disabling automatic upgrades is the opposite of that. So I think disabling updates is a huge disservice and definitely not beginner-friendly. Users who want to disable autoupdates can always do that via the respective GUI (software-properties-gtk).

@mak ping! This is the issue ticket about unattended upgrades

Available https://hub.docker.com/repository/docker/pureos/byzantium-arm64

Ah, okay. That is a good catch, I've never seen that behavior before. I'll have to investigate and it may be a bug in GNOME-SOFTWARE, or, as you point out, it may be in the packaging.

I can install freecad via the command line. apt-get install freecad gives a functional installation. Clicking install button in gnome-software results in only freecad-common package being installed, which is not enough to run freecad.