(Unattended-upgrades) Apparently I'm running Debian... Again.

steve_v · 2021-03-13 14:06:51

Okay, let's install unattended-upgrades for a new-old headless Devuan box... This should just-work like it has for the last 20 years on Debian, right?

# apt install unattended-upgrades
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  python3-distro-info
Suggested packages:
  bsd-mailx default-mta | mail-transport-agent needrestart
The following NEW packages will be installed:
  python3-distro-info unattended-upgrades
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 86.9 kB of archives.
After this operation, 339 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.devuan.org/merged beowulf/main i386 python3-distro-info all 0.21 [7,896 B]
Get:2 http://deb.devuan.org/merged beowulf/main i386 unattended-upgrades all 1.11.2 [79.0 kB]
Fetched 86.9 kB in 4s (21.9 kB/s)              
Preconfiguring packages ...
Selecting previously unselected package python3-distro-info.
(Reading database ... 49149 files and directories currently installed.)
Preparing to unpack .../python3-distro-info_0.21_all.deb ...
Unpacking python3-distro-info (0.21) ...
Selecting previously unselected package unattended-upgrades.
Preparing to unpack .../unattended-upgrades_1.11.2_all.deb ...
Unpacking unattended-upgrades (1.11.2) ...
Setting up python3-distro-info (0.21) ...
Setting up unattended-upgrades (1.11.2) ...

Creating config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
Processing triggers for man-db (2.8.5-2) ...

And fire those updates to make sure it works...

# unattended-upgrades -d
Initial blacklist : 
Initial whitelist: 
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=beowulf,label=Debian, origin=Debian,codename=beowulf,label=Debian-Security
Using (^linux-image-[0-9]+\.[0-9\.]+-.*|^linux-headers-[0-9]+\.[0-9\.]+-.*|^linux-image-extra-[0-9]+\.[0-9\.]+-.*|^linux-modules-[0-9]+\.[0-9\.]+-.*|^linux-modules-extra-[0-9]+\.[0-9\.]+-.*|^linux-signed-image-[0-9]+\.[0-9\.]+-.*|^linux-image-unsigned-[0-9]+\.[0-9\.]+-.*|^kfreebsd-image-[0-9]+\.[0-9\.]+-.*|^kfreebsd-headers-[0-9]+\.[0-9\.]+-.*|^gnumach-image-[0-9]+\.[0-9\.]+-.*|^.*-modules-[0-9]+\.[0-9\.]+-.*|^.*-kernel-[0-9]+\.[0-9\.]+-.*|^linux-backports-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-tools-[0-9]+\.[0-9\.]+-.*|^linux-cloud-tools-[0-9]+\.[0-9\.]+-.*|^linux-buildinfo-[0-9]+\.[0-9\.]+-.*|^linux-source-[0-9]+\.[0-9\.]+-.*) regexp to find kernel packages
Using (^linux-image-4\.19\.0\-14\-686$|^linux-headers-4\.19\.0\-14\-686$|^linux-image-extra-4\.19\.0\-14\-686$|^linux-modules-4\.19\.0\-14\-686$|^linux-modules-extra-4\.19\.0\-14\-686$|^linux-signed-image-4\.19\.0\-14\-686$|^linux-image-unsigned-4\.19\.0\-14\-686$|^kfreebsd-image-4\.19\.0\-14\-686$|^kfreebsd-headers-4\.19\.0\-14\-686$|^gnumach-image-4\.19\.0\-14\-686$|^.*-modules-4\.19\.0\-14\-686$|^.*-kernel-4\.19\.0\-14\-686$|^linux-backports-modules-.*-4\.19\.0\-14\-686$|^linux-modules-.*-4\.19\.0\-14\-686$|^linux-tools-4\.19\.0\-14\-686$|^linux-cloud-tools-4\.19\.0\-14\-686$|^linux-buildinfo-4\.19\.0\-14\-686$|^linux-source-4\.19\.0\-14\-686$) regexp to find running kernel packages
pkgs that look like they should be upgraded: 
Fetched 0 B in 0s (0 B/s)                                                                                                                                                                                                                  
fetch.run() result: 0
blacklist: []
whitelist: []
No packages found that can be upgraded unattended and no pending auto-removals
Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2021-03-14 02:24:59

Huh. That's odd, I was expecting some updates...

Wait, what? Debian beowulf?

Oh look:

# grep -i devuan /etc/apt/apt.conf.d/50unattended-upgrades

*crickets*

# grep -i debian /etc/apt/apt.conf.d/50unattended-upgrades     
//     site          (eg, "http.debian.net")
// derived from /etc/debian_version:
root@mpdsrv:/etc/apt/apt.conf.d# grep -i debian /etc/apt/apt.conf.d/50unattended-upgrades 
//   l,label         (eg, "Debian", "Debian-Security")
//   o,origin        (eg, "Debian", "Unofficial Multimedia Packages")
//     site          (eg, "http.debian.net")
// derived from /etc/debian_version:
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
//      "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";

Ahh. I see. This again.

Look, I realise it's a small team and all that, but can we please at least try to get the name of the distro right?
A bootloader that still says "Debian" is kind of embarrassing, but harmless. Borking things like unattended-upgrades is going to get someone pwned.

Best of all, according to the bugtracker this was supposedly fixed in 2017. Yet here it is again.

dice · 2021-03-13 14:35:59

I have never used unattended upgrades. Could the devuan 3.1 release notes shed a bit more light on this issue?

Changing the ID of the operating system.
- This point-release (3.1.0) fixes a bug in the last release that
showed "Debian" in the boot menu instead of "Devuan".
If you need the system to identify itself as Debian, you can edit
/etc/os-release to show ID=debian. This may be needed for third-party
software that expects to see debian.

https://files.devuan.org/devuan_beowulf … _notes.txt

steve_v · 2021-03-13 16:40:59

dice wrote:

I have never used unattended upgrades.

How many headless boxes do you administer? If you don't like needing to ssh into each one to apply updates, and want your machines to keep themselves up to date, mail you with results and schedule their own reboots for when there are no users logged in, unattended-upgrades is for you.

It's been in main at least as far back as etch, so it's not exactly exotic and I'm fairly confident I'm not the only one using it.

dice wrote:

Could the devuan 3.1 release notes shed a bit more light on this issue?

It sheds light on the grub menu problem, but this being a new (post point-release) install it already has that fix.

PRETTY_NAME="Devuan GNU/Linux 3 (beowulf)"
NAME="Devuan GNU/Linux"
VERSION_ID="3"
VERSION="3 (beowulf)"
VERSION_CODENAME=beowulf
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

This is another problem of the same class all right though, i.e. rolling debian packages into the repos without checking them for debianisms.

Head_on_a_Stick · 2021-03-13 16:55:17

steve_v wrote:

rolling debian packages into the repos without checking them for debianisms.

That's not how it works: https://dev1galaxy.org/viewtopic.php?id=3192

So you do understand how to make unattended-upgrades work then? I think the community would appreciate a quick HowTo thread in the Freedom Hacks section more than this pointless rant.

steve_v · 2021-03-13 18:53:36

Head_on_a_Stick wrote:

That's not how it works

Yes yes, perhaps I should have said "let the automation pull packages from Debian without checking them for functionality on Devuan." The result is the same.

Head_on_a_Stick wrote:

So you do understand how to make unattended-upgrades work then?

Anyone who has a passing familiarity with sed can make unattended-upgrades work. Perhaps somebody should teach amprolla the same trick.
Likewise anyone who can search a bugtracker can realise that pulling down such packages from Debian without any squishy eyeballs on them is going to reintroduce bugs just like this one.

Head_on_a_Stick wrote:

I think the community would appreciate a quick HowTo thread in the Freedom Hacks section

Frankly I suspect what the community would appreciate even more would be a little look into where that fix committed 4 years ago wandered off to in the first place.

On a completely off-topic note, you're extremely unlikely to see me in the "Freedom Hacks" sub, ever. The pretentious name alone is enough to keep me away.

Last edited by steve_v (2021-03-13 18:54:42)

dice · 2021-03-14 10:24:24

steve_v wrote:

dice wrote:
I have never used unattended upgrades.
How many headless boxes do you administer? If you don't like needing to ssh into each one to apply updates, and want your machines to keep themselves up to date, mail you with results and schedule their own reboots for when there are no users logged in, unattended-upgrades is for you.
It's been in main at least as far back as etch, so it's not exactly exotic and I'm fairly confident I'm not the only one using it.

I dont run any headless boxes. But it sounds like a good idea if you have a network of many systems you need to look after. Sorry i couldnt be of any help. Maybe file a bug report again ??

steve_v · 2021-03-15 08:59:56

dice wrote:

Sorry i couldnt be of any help.

No worries, and no apology needed. This was more a "(loudly) bring it to somebody's attention that this stuff is slipping through again" than a "how do I fix it". Fixing it is easy, it's the "making sure 'debian' doesn't keep slipping into our default configs and breaking things" bit that I'm after.

dice wrote:

Maybe file a bug report again ??

Yeah, I'll get to that just as soon as I get around to figuring out how to report bugs... Round tuits are in short supply right now.

Last edited by steve_v (2021-03-15 09:02:36)

ralph.ronnquist · 2021-03-15 10:45:34

The steps for a bug report are almost as simple as your fixing of that file:

find out which package is concerned (unattended-upgrades)
find out which version of that package you'r using (1.11.2)
send an email to submit@devuan.org with a useful subject, and the body starting "formally" with 2 lines:
```
Package: unattended-upgrades
Version: 1.11.2
```
then followed by a polite and useful treatise outlining the issue and preferrably including a patch that resolves it.

In this particular case, the "bug" is lack of maintaner effort to upgrade the fork of unattended-upgrades. Therefore beowulf got committed with the debian package version.

Your patch will go part of the way towards upgrading the forked package, which also needs any other changes since the last fork version, 0.93.1+vua2.0, including any adaption to the current package building pipline.

As it happens, the maintainer role for that forked package is currently vacant.

icosahedral · 2021-06-10 15:08:58

I'm a not-especially-experienced user trying to figure out why my Devuan machines are not automatically updating themselves, or at least prompting me to do so. (I assumed this would most likely happen by default, as on Ubuntu, from which I migrated, so it took me a while to notice that they weren't.) I've searched for further information, and your discussion here is the best lead I've found: it seems, I think, that the unattended-upgrades package should do this for me, but doesn't, due to a bug.

I understand from the above that there's some straightforward fix that can be applied by editing /etc/apt/apt.conf.d/50unattended-upgrades and that it can be implemented by anyone with a passing familiarity with sed (which I have, barely). But I don't understand what that fix actually *is*.

Could someone please tell me explicitly how to fix this bug?

Last edited by icosahedral (2021-06-10 15:09:11)

Head_on_a_Stick · 2021-06-10 17:44:38

icosahedral wrote:

Could someone please tell me explicitly how to fix this bug?

Edit /etc/apt/apt.conf.d/50unattended-upgrades and change the Debian repository references to the correct Devuan equivalents.

bai4Iej2need · 2023-01-08 15:03:36

Tested this at beowulf and after

aptitude show unattended-upgrades
Paket: unattended-upgrades                      
Version: 2.8

vi 50unattended-upgrades

%s/debian/devuan/g
%s/Debian/Devuan/g
:wq

unattended-upgrade --debug | wc -l

189 lines showed up (many) of debs, which can be upgraded.
In Devuan beowulf the problem is not fixed yet

Last edited by bai4Iej2need (2023-01-08 15:57:02)

GlennW · 2023-01-10 02:15:01

steve_v wrote:

Head_on_a_Stick wrote:
That's not how it works
Yes yes, perhaps I should have said "let the automation pull packages from Debian without checking them for functionality on Devuan." The result is the same.
Head_on_a_Stick wrote:
So you do understand how to make unattended-upgrades work then?
Anyone who has a passing familiarity with sed can make unattended-upgrades work. Perhaps somebody should teach amprolla the same trick.
Likewise anyone who can search a bugtracker can realise that pulling down such packages from Debian without any squishy eyeballs on them is going to reintroduce bugs just like this one.
Head_on_a_Stick wrote:
I think the community would appreciate a quick HowTo thread in the Freedom Hacks section
Frankly I suspect what the community would appreciate even more would be a little look into where that fix committed 4 years ago wandered off to in the first place.
On a completely off-topic note, you're extremely unlikely to see me in the "Freedom Hacks" sub, ever. The pretentious name alone is enough to keep me away.

I would wager that the company that made your computer did not envison you running linux and therefore you have theoretically hacked your computer by installing GNU/Linux. Not all hacking is criminal, check out "Game Theory", know the rules of the game you can better get value from the experience.

Al the best. :-)

steve_v · 2023-01-10 04:31:29

GlennW wrote:

I would wager that the company that made your computer did not envison you running linux and therefore you have theoretically hacked your computer by installing GNU/Linux. Not all hacking is criminal, check out "Game Theory", know the rules of the game you can better get value from the experience.

I use "hack" and derivatives in their original meanings, always have.
Media droids conflating "hack" and "hacker" with the correct "crack" and "cracker" is not my problem, nor are ignorant muggles who do the same.

My problem with "Freedom Hacks" is the same problem I have with this board in general - a tendency to slap "freedom" on everything Devuan, as if it were some kind of philosophical fight against an oppressor, rather than a 90%+ Debian fork that retains support for multiple init implementations... Which is functionally what it is and always has been.
... That and it apparently being irresistible to preachers, rebels, "free thinkers", free speech advocates, conspiracy theorists and anti-establishment/anti-conformists in general.

Call that tutorial/howto sub something less ridiculous and I might be inclined... But not for this, because this is a packaging bug that got swept under the rug, plain and simple. It doesn't need a hack, it needs to be fixed.
Besides, if somebody needs a "freedom hack" post for a word replacement as obvious as this, I expect they probably need spoon-feeding and burping as well.

GlennW · 2023-01-10 21:51:34

steve_v wrote:

GlennW wrote:
I would wager that the company that made your computer did not envison you running linux and therefore you have theoretically hacked your computer by installing GNU/Linux. Not all hacking is criminal, check out "Game Theory", know the rules of the game you can better get value from the experience.
I use "hack" and derivatives in their original meanings, always have.
Media droids conflating "hack" and "hacker" with the correct "crack" and "cracker" is not my problem, nor are ignorant muggles who do the same.
My problem with "Freedom Hacks" is the same problem I have with this board in general - a tendency to slap "freedom" on everything Devuan, as if it were some kind of philosophical fight against an oppressor, rather than a 90%+ Debian fork that retains support for multiple init implementations... Which is functionally what it is and always has been.
... That and it apparently being irresistible to preachers, rebels, "free thinkers", free speech advocates, conspiracy theorists and anti-establishment/anti-conformists in general.
Call that tutorial/howto sub something less ridiculous and I might be inclined... But not for this, because this is a packaging bug that got swept under the rug, plain and simple. It doesn't need a hack, it needs to be fixed.
Besides, if somebody needs a "freedom hack" post for a word replacement as obvious as this, I expect they probably need spoon-feeding and burping as well.

Good for you. I thought I was extremist.

Head_on_a_Stick · 2023-01-11 06:51:13

steve_v wrote:

I use "hack" and derivatives in their original meanings, always have.

Oh c'mon Steve, that's just begging the question

Language is fluid and meanings change over time. I'm really annoyed that Richard Dawkins' original meaning of the word "meme" has been subverted by ignorant youths sharing silly gifs but I've learned to live with it. Bloody kids.

LeePen · 2023-01-16 18:14:53

Steve,

Apparently the issue with unattended-upgrades is that Devuan support is in the Debian source, but the source also needs to be recompiled on a Devuan system.

I have added preliminary support for us doing that to the Devuan jenkins instance. Could you please test these artifacts and report back?

Thanks

Mark

steve_v · 2023-01-16 23:00:20

LeePen wrote:

Could you please test

Works fine on beowulf as far as a cursory test in a VM. Not so much on chimaera if one is using codename matching though...

I see the config template for Debian (50unattended-upgrades.Debian) references release as ${distro_codename}, and AFAICT from the python script, that's pulled from the output of lsb_release.
The config for Devuan does not (though it retains the reference to /etc/debian_version, which is nonsensical on Devuan), instead including hardcoded lines for beowulf.
The relevant (main, security) lines are also commented in the Devuan config, whereas for Debian they are not. Minor detail and all.

IMO since lsb_release returns correct information on Devuan, it would make sense to use ${distro_codename} by default here as well. Also changing /etc/debian_version to /etc/devuan_version for less confusion, since the former doesn't actually contain a release codename.

TBH I'm a little confused that the Devuan config deviates so far from the Debian version to begin with - all that's really needed is s/Debian/Devuan/g and some minor cleanup of the comments.

Last edited by steve_v (2023-01-16 23:09:34)

LeePen · 2023-01-17 07:21:14

steve_v wrote:

Works fine on beowulf as far as a cursory test in a VM.

Encouraging, thanks,

steve_v wrote:

I'm a little confused that the Devuan config deviates so far from the Debian version to begin with - all that's really needed is s/Debian/Devuan/g and some minor cleanup of the comments.

It may date from a few years ago when lsb-release returned confusing data on Devuan to fix UEFI boot. That is now resolved.

If you have a better/improved default config for Devuan, could you submit it to Debian's BTS please?

Many thanks.

Mark

Marjorie · 2023-01-17 11:23:04

dice wrote:

I have never used unattended upgrades. Could the devuan 3.1 release notes shed a bit more light on this issue?

I use unattended upgrades to install security upgrades on both my main PC and my mail server.

I didn't find it that difficult to get working.

1. Install package

2. Consult man page

man unattended-upgrades

read the lines

CONFIGURATION
       The  configuration  is  done  via  the  apt  configuration  mechanism.  The  default  configuration  file can be found at
       /etc/apt/apt.conf.d/50unattended-upgrades

3. Open (as root/sudo) the file /etc/apt/apt.conf.d/50unattended-upgrades and configure.
The file is largely self-documenting.

This includes changing the default distribution and package.

This is my fixed/working version. I suspect its unchanged (apart from changing ascii to chimaera in line 43) since I used ascii.

// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component     (eg, "main", "contrib", "non-free")
//   l,label         (eg, "Devuan", "Devuan-Security")
//   o,origin        (eg, "Devuan")
//   n,codename      (eg, "ascii", "ascii-updates")
//     site          (eg, "deb.devuan.org")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "ascii")
Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
//      "o=Devuan,n=ascii";
//      "o=Devuan,n=ascii-updates";
//      "o=Devuan,n=ascii-proposed-updates";

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Devuan,a=stable";
//      "o=Devuan,a=stable-updates";
//      "o=Devuan,a=proposed-updates";

        // Activate *-security by default.
        // This will make it easier for Devuan derivatives.
        // "a=*-security";
	//
	"o=Devuan,n=chimaera-security";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
//	"vim";
//	"libc6";
//	"libc6-dev";
//	"libc6-i686";
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shutting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade 
//Unattended-Upgrade::Automatic-Reboot "false";

// Automatically reboot even if there are users currently logged in.
//Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

// Enable logging to syslog. Default is False
Unattended-Upgrade::SyslogEnable "true";

// Specify syslog facility. Default is daemon
// Unattended-Upgrade::SyslogFacility "daemon";

It might be nicer if the Chimaera version included Devuan/Chimaera/security defaults (my line 43):

       "o=Devuan,n=chimaera-security";

But not sure its really worth pestering our admins to do this every time Debian change it upstream as there are other options in the config you might want to change anyway ( I don't do auto reboots or install non-security ungrades, I do ask it to email me when upgrades happen) though a mention in the release notes might help as at the very least you do need to change that line, or it's equivalent, to include 'chimaera' when upgrading.

I run apt both on my mail server and my main PC via 0anacron and apt-compat in /etc/cron.daily so it should check for updates daily. For a server you could just call it directly from cron, however as I often hibernate rather than reboot my main PC overnight I also get it to check for updates on resume (cron doesn't run jobs called when the computer is turned off at the designated time).

Last edited by Marjorie (2023-01-17 11:36:11)

steve_v · 2023-01-17 11:47:00

Marjorie wrote:

This is my fixed/working version. I suspect its unchanged (apart from changing ascii to chimaera in line 43) since I used ascii.

If your install dates back to ascii (and you haven't let dpkg clobber the config files) you would have correct distro name, as this predates the fix getting lost and the package reverted to upstream Debian.

Marjorie wrote:

not sure its really worth pestering our admins to do this every time Debian change it upstream as there are other options in the config you might want to change anyway

That's kinda my point WRT using ${distro_codename} instead of a hardcoded release. That's how Debian does it, and it allows unattended-upgrades to track the new release after a dist-upgrade with no manual changes to its configuration at all.

Ditto for the devuan-security line, I see no reason not to use ${distro_codename} there either, unless to create more packaging work.

Marjorie · 2023-01-17 21:30:36

steve_v wrote:

That's kinda my point WRT using ${distro_codename} instead of a hardcoded release. That's how Debian does it, and it allows unattended-upgrades to track the new release after a dist-upgrade with no manual changes to its configuration at all.
Ditto for the devuan-security line, I see no reason not to use ${distro_codename} there either, unless to create more packaging work.

Surely that would only make sense if I wanted to upgrade immediately 'testing' became 'stable'?
I'm far too conservative to want to do that - I'd rather wait a decent interval and let other find out for me what problems are surfaced.
Note the latest fubar with Windows ( https://www.theregister.com/2023/01/16/ … e_scripts/).
This is also why I only update security patches immediately.

steve_v · 2023-01-17 23:54:22

Marjorie wrote:

Surely that would only make sense if I wanted to upgrade immediately 'testing' became 'stable'?

No, that's what "archive" (a=foo) matching is for.

a=stable will track whatever release is currently marked as stable (so it's liable to silently start pulling in packages from a new stable release as soon as it becomes available).
n=<codename> will track <codename> forever until you change it manually, regardless of unstable/testing/stable status.
n=${distro_codename} does the same, except that it uses lsb_release to determine which release codename you are currently running. When (and only when) you switch to a different release (i.e. change your sources and do a manual dist-upgrade), lsb_release picks it up, nobody needs to look at that file.

That last one has been the "safe" default in Debian for a long time now, and AFAICT the only reason it isn't on Devuan is that lsb_release was broken for a while (returning Debian release names).
IIRC lsb_release in turn was broken to work around yet another "we're 99% Debian but trying to pretend we're not" class bug. Of course.

All that is now fixed, so I see no reason not to put this trivial bit of automation back.

Last edited by steve_v (2023-01-18 00:19:05)

The officially official Devuan Forum!

#1 2021-03-13 14:06:51

(Unattended-upgrades) Apparently I'm running Debian... Again.

#2 2021-03-13 14:35:59

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#3 2021-03-13 16:40:59

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#4 2021-03-13 16:55:17

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#5 2021-03-13 18:53:36

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#6 2021-03-14 10:24:24

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#7 2021-03-15 08:59:56

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#8 2021-03-15 10:45:34

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#9 2021-06-10 15:08:58

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#10 2021-06-10 17:44:38

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#11 2023-01-08 15:03:36

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#12 2023-01-10 02:15:01

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#13 2023-01-10 04:31:29

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#14 2023-01-10 21:51:34

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#15 2023-01-11 06:51:13

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#16 2023-01-16 18:14:53

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#17 2023-01-16 23:00:20

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#18 2023-01-17 07:21:14

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#19 2023-01-17 11:23:04

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#20 2023-01-17 11:47:00

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#21 2023-01-17 21:30:36

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

#22 2023-01-17 23:54:22

Re: (Unattended-upgrades) Apparently I'm running Debian... Again.

Board footer