nginx error log on Artemis is saying:

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.

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.

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

Thanks Sebastian! Let's find another package @alvesadrian

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

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

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.

Glad you tracked down the issue! Nice sleuthing!

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

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.

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.

Amber is Buster, yes.

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?

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.

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.

Thanks for filing the bug. I'm not sure of the issue - can you install freecad via the command line?

Removing the contents of /var/lib/apt/lists removes out of date files. Re-running apt update brings in new Release file and one can download all packages again.

I can reproduce on the L13;

Cannot reproduce on my mini running byzantium.

@joao.azevedo I'll have to update and/or repackage youtube-dl ASAP.

Excellent - we'll get to work on that. :-)

Hi @Moop - thanks for reporting this. A new live image has been released. May I ask that you test again?

FWIW Linode provides 250 Gigs for $5 a month. We could get a Terrabyte with them of web addressable storage for USD 20 per month ($240 per year).

So from a quick check it looks like /dev/md3 is the disk that holds our repos;
/dev/md3 1.8T 822G 919G 48% /srv

I don't have a power meter but I will use powertop. :-)

So how do we do this test in a way that produces useful data? Do we run it at two different settings on two laptops concurrently? Or should I measure battery level over time at specific intervals with each setting on the same device?

Following Guido's link, I ran

I'm working on pushing youtube-dl_2020.09.14 from byzantium to amber.

Yes, let me look into how quickly we can get this into Byzantium. (There are two routes - wait for an update from upstream packaging, e.g. Debian, or upload our own package directly amber.) Uploading the new package directly to amber is likely the fastest way to close this bug.