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.
]]>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.
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.
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.
]]>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).
]]>Works fine on beowulf as far as a cursory test in a VM.
Encouraging, thanks,
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
]]>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.
]]>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
]]>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.
]]>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.
]]>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.
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. :-)
]]>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
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.
]]>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?
]]>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.
]]>