Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 15:11, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Aurelien Jarno (2024-05-20 11:49:32) > > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > > > Going from the other side, maybe libc6.postinst could use something > > > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > > > out the situation a bit better? > > > > Nope. > > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported > > In sbuild using unshare chroot running in a VM: > > > > | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt > > | Failed to read $container of PID 1, ignoring: Permission denied > > | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy > > | Found container virtualization none. > > | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) > > | UML virtualization not found in /proc/cpuinfo. > > | Virtualization XEN not found, /proc/xen does not exist > > | Virtualization found, CPUID=KVMKVMKVM > > | Found VM virtualization kvm > > | kvm > > would it help (and be correct) if PID 1 in sbuild unshare mode would have the > "container" environment variable set to something? And/or if sbuild unshare > mode would create the file /run/systemd/container with some content? > > I'd need input from somebody who knows how containers (if this is one) are > supposed to work. :) Does it run in PID + mount + user namespaces, on a different filesystem than the host? If so, then yeah it does look like a container
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:42, Aurelien Jarno wrote: > > On 2024-05-20 10:38, Chris Hofstaedtler wrote: > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > [..] But maybe it [glibc's postinst] should be doing some > > > more involved checks about what PID 1 is? It could then make sure to only > > > call > > > systemd telinit if systemd is pid 1. [..] > > > > Well, that would probably suck. Putting the knowledge when to call > > telinit, and a specific telinit, into a ton of different things > > makes all those things hard to get right, hard to update, the usual. > > On the glibc side, this part has always been a pain to handle (a bit > less since upstart got removed). And the systemd decision to increase > the use of dlopen() will make this step even more necessary. > > Therefore I wonder if it could be solved using the trigger mechanism, > basically glibc saying "I got upgraded" and the packages, being systemd, > sysv or any other system can then decide what to do instead of > hardcoding that on the glibc side. > > That would also simplify the chrootless case a bit. Each package's postinst already needs to do the right thing on upgrade, so yeah that sounds like a good idea to me.
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:49, Aurelien Jarno wrote: > > On 2024-05-20 10:40, Luca Boccassi wrote: > > On Mon, 20 May 2024 at 10:37, Aurelien Jarno wrote: > > > > > > On 2024-05-20 10:22, Luca Boccassi wrote: > > > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > > > * Johannes Schauer Marin Rodrigues [240520 > > > > > > 07:35]: > > > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > > > more involved checks about what PID 1 is? It could then make sure > > > > > > > to only call > > > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > > > telinit, and a specific telinit, into a ton of different things > > > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > > > they are not that different. Both try to talk to their respective > > > > > > pid1 daemons first using their respective communication socket. > > > > > > > > > > > > But then, if that doesn't work, they diverge: > > > > > > - sysvinit's telinit just gives up > > > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > > > being in a chroot, before doing any of that. > > > > > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, > > > > > > and glibc's > > > > > > postinst (and other places) can become simpler again. > > > > > > > > > > via irc, jochen also pointed out: telinit could be the component > > > > > which checks > > > > > what PID 1 actually is and only do its thing after it confirmed that > > > > > it is > > > > > indeed an init system like systemd that is providing PID 1? > > > > > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > > Going from the other side, maybe libc6.postinst could use something > > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > > out the situation a bit better? > > > > > > Nope. > > > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported > > In sbuild using unshare chroot running in a VM: > > | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt > | Failed to read $container of PID 1, ignoring: Permission denied > | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy > | Found container virtualization none. > | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) > | UML virtualization not found in /proc/cpuinfo. > | Virtualization XEN not found, /proc/xen does not exist > | Virtualization found, CPUID=KVMKVMKVM > | Found VM virtualization kvm > | kvm Is sbuild running unshare with a user namespace (-U)? If so, systemd-detect-virt --private-users should catch that
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:37, Aurelien Jarno wrote: > > On 2024-05-20 10:22, Luca Boccassi wrote: > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > wrote: > > > > > > Hi, > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > more involved checks about what PID 1 is? It could then make sure to > > > > > only call > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > telinit, and a specific telinit, into a ton of different things > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > they are not that different. Both try to talk to their respective > > > > pid1 daemons first using their respective communication socket. > > > > > > > > But then, if that doesn't work, they diverge: > > > > - sysvinit's telinit just gives up > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > being in a chroot, before doing any of that. > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > > glibc's > > > > postinst (and other places) can become simpler again. > > > > > > via irc, jochen also pointed out: telinit could be the component which > > > checks > > > what PID 1 actually is and only do its thing after it confirmed that it is > > > indeed an init system like systemd that is providing PID 1? > > > > That's all legacy stuff and I really don't want to touch it anymore. > > Going from the other side, maybe libc6.postinst could use something > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > out the situation a bit better? > > Nope. What's the output? With SYSTEMD_LOG_LEVEL=debug exported
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > [..] But maybe it [glibc's postinst] should be doing some > > > more involved checks about what PID 1 is? It could then make sure to only > > > call > > > systemd telinit if systemd is pid 1. [..] > > > > Well, that would probably suck. Putting the knowledge when to call > > telinit, and a specific telinit, into a ton of different things > > makes all those things hard to get right, hard to update, the usual. > > > > I've checked the sysvinit and the systemd implementations now, and > > they are not that different. Both try to talk to their respective > > pid1 daemons first using their respective communication socket. > > > > But then, if that doesn't work, they diverge: > > - sysvinit's telinit just gives up > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > being in a chroot, before doing any of that. > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > fallback to stick with sysvinit's behaviour? > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and glibc's > > postinst (and other places) can become simpler again. > > via irc, jochen also pointed out: telinit could be the component which checks > what PID 1 actually is and only do its thing after it confirmed that it is > indeed an init system like systemd that is providing PID 1? That's all legacy stuff and I really don't want to touch it anymore. Going from the other side, maybe libc6.postinst could use something more reliable than ischroot()? Is systemd-detect-virt able to figure out the situation a bit better?
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne wrote: > the init process should handle SIGTERM more like an init system would handle that This seems the obvious answer to me. sbuild is setting up a system such that its component runs as pid1, so it needs to behave like a pid1. We know this is special and requires supporting a number of interfaces. If a program doesn't, then it shouldn't be running as pid1 in a namespace. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1038798: locales: transition from /etc/default/locale to /etc/locale.conf
Package: locales Version: 2.36-9 Tags: patch X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Dear Maintainer(s), As discussed before Bookworm released, for Trixie we'd like to drop a lot of out-of-tree debian code and transition from the debian-only /etc/default/locale location to the more common /etc/locale.conf which is shared by most other distributions. The content is the same, so there's no functional change. We can add a compat symlink in the old location to ensure existing scripts or programs are not affected. MR open on Salsa: https://salsa.debian.org/glibc-team/glibc/-/merge_requests/19 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#822733: tzdata: Drop /etc/timezone
On Mon, 6 Feb 2023 at 13:13, Benjamin Drung wrote: > > On Sun, 2023-01-29 at 15:45 +0100, Michael Biebl wrote: > > Am 29.01.2023 um 15:38 schrieb Luca Boccassi: > > > On Sun, 29 Jan 2023, 13:15 Michael Biebl, > > <mailto:bi...@debian.org>> wrote: > > > > > > Am 28.01.2023 um 02:12 schrieb Luca Boccassi: > > > > I'm looking at this again, because handling /etc/timezone is one > > > of the > > > > last large technical debt patches that we carry in Debian for > > > > src:systemd, and we want to drop it for Trixie. > > > > The idea is to add a tmpfiles.d entry in the systemd package that > > > > unconditionally deletes /etc/timezone if present. If someone wants > > > to > > > > keep using it, they can simply override the tmpfiles.d entry with > > > the > > > > usual mechanisms. > > > > > > > > So, could you please reconsider the proposal to stop creating it > > > if it > > > > doesn't exist (but keep updating if it does) in the tzdata > > > postinst as > > > > above for Trixie? > > > > > > I'm a bit confused: If you forcefully want to delete /etc/timezone > > > via a > > > tmpfiles snippet, why let tzdata update an existing /etc/timezone? > > > > > > > > > Because it can be overridden as mentioned, so in case there are unknown > > > corner cases where it's still needed, a drop-in can be added to avoid > > > deleting the file and it will still get updated. In the future we can > > > then consider removing this as well. > > > > > > > I would prefer, if all this is handled within tzdata. > > - It should stop creating /etc/timezone > > - It should delete /etc/timezone on upgrades as a one-time action > > - If users manually create the file afterwards (say touch /etc/timezone) > > a dpkg-reconfigure tzdata would update the file. > > I will implement exactly this for tzdata since that approach makes the > most sense. Sounds great, thank you
Bug#822733: tzdata: Drop /etc/timezone
On Sun, 29 Jan 2023 at 14:45, Michael Biebl wrote: > > Am 29.01.2023 um 15:38 schrieb Luca Boccassi: > > On Sun, 29 Jan 2023, 13:15 Michael Biebl, > <mailto:bi...@debian.org>> wrote: > > > > Am 28.01.2023 um 02:12 schrieb Luca Boccassi: > > > I'm looking at this again, because handling /etc/timezone is one > > of the > > > last large technical debt patches that we carry in Debian for > > > src:systemd, and we want to drop it for Trixie. > > > The idea is to add a tmpfiles.d entry in the systemd package that > > > unconditionally deletes /etc/timezone if present. If someone wants to > > > keep using it, they can simply override the tmpfiles.d entry with the > > > usual mechanisms. > > > > > > So, could you please reconsider the proposal to stop creating it > > if it > > > doesn't exist (but keep updating if it does) in the tzdata > > postinst as > > > above for Trixie? > > > > I'm a bit confused: If you forcefully want to delete /etc/timezone > > via a > > tmpfiles snippet, why let tzdata update an existing /etc/timezone? > > > > > > Because it can be overridden as mentioned, so in case there are unknown > > corner cases where it's still needed, a drop-in can be added to avoid > > deleting the file and it will still get updated. In the future we can > > then consider removing this as well. > > > > I would prefer, if all this is handled within tzdata. > - It should stop creating /etc/timezone > - It should delete /etc/timezone on upgrades as a one-time action > - If users manually create the file afterwards (say touch /etc/timezone) > a dpkg-reconfigure tzdata would update the file. > > This should all be under tzdata's control. Without the tmpfiles.d in src:systemd, we can't drop the patch for one release I'd think?
Bug#822733: tzdata: Drop /etc/timezone
On Sun, 29 Jan 2023, 13:15 Michael Biebl, wrote: > Am 28.01.2023 um 02:12 schrieb Luca Boccassi: > > I'm looking at this again, because handling /etc/timezone is one of the > > last large technical debt patches that we carry in Debian for > > src:systemd, and we want to drop it for Trixie. > > The idea is to add a tmpfiles.d entry in the systemd package that > > unconditionally deletes /etc/timezone if present. If someone wants to > > keep using it, they can simply override the tmpfiles.d entry with the > > usual mechanisms. > > > > So, could you please reconsider the proposal to stop creating it if it > > doesn't exist (but keep updating if it does) in the tzdata postinst as > > above for Trixie? > > I'm a bit confused: If you forcefully want to delete /etc/timezone via a > tmpfiles snippet, why let tzdata update an existing /etc/timezone? > Because it can be overridden as mentioned, so in case there are unknown corner cases where it's still needed, a drop-in can be added to avoid deleting the file and it will still get updated. In the future we can then consider removing this as well. >
Bug#822733: tzdata: Drop /etc/timezone
On Wed, 27 Apr 2016 11:41:14 +0200 Martin Pitt wrote: > Hello Aurelien, > > Aurelien Jarno [2016-04-27 11:13 +0200]: > > Unfortunately it seems a lot of software are actually using > > /etc/timezone to configure the time zone. When switching to a symlink > > this made people unhappy, see for example bug#813226. This bug points to > > the following query: > > > > https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata=Code=%E2%9C%93 > > Interesting, thanks for that link. It seems the majority is writing > that file for a subsequent dpkg-reconfigure, but I've seen a few reads > as well. It seems over time a lot of software out there has adopted > this Debianism. > > Wrt. to #813226, I admittedly don't understand why /etc/localtime > being a file or symlink is in any way related to which of > /etc/localtime vs. /etc/timezone should have priority over the other > on reconfiguration. I mean, the *.config scripts surely may treat them > differently, but that's just an implementation detail, not a > conceptual/design problem? > > Software (both tzdata itself and also other things reading/changing > it) needs to get along with /etc/localtime being a symlink either way, > even before tzdata 2016a-1. > > > What we can probably do is to stop looking or creating /etc/timezone > > if it doesn't exist, but keep updating it if it exists. What do you > > think? > > That might be cleaner in situations where someone explicitly removes > it, but a lot less useful to avoid the redundancy problem. > > Anyway, it seems to me that this is too deeply entrenched in the > software world by now, so I figure is is a case for 'wontfix' and > just closing this report? > > Thanks! > > Martin Hi, I'm looking at this again, because handling /etc/timezone is one of the last large technical debt patches that we carry in Debian for src:systemd, and we want to drop it for Trixie. The idea is to add a tmpfiles.d entry in the systemd package that unconditionally deletes /etc/timezone if present. If someone wants to keep using it, they can simply override the tmpfiles.d entry with the usual mechanisms. So, could you please reconsider the proposal to stop creating it if it doesn't exist (but keep updating if it does) in the tzdata postinst as above for Trixie? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#992653: glibc breaks openconnect autopkgtest: FAIL: auth-nonascii
On Sun, 22 Aug 2021 01:05:25 +0200 Aurelien Jarno wrote: > control: tag -1 patch > > Hi, > > On 2021-08-21 21:52, Paul Gevers wrote: > > Source: glibc, openconnect > > Control: found -1 glibc/2.31-16 > > Control: found -1 openconnect/8.10-2 > > Severity: serious > > Tags: sid bookworm > > X-Debbugs-CC: debian...@lists.debian.org > > User: debian...@lists.debian.org > > Usertags: breaks needs-update > > > > Dear maintainer(s), > > > > With a recent upload of glibc the autopkgtest of openconnect fails in > > testing when that autopkgtest is run with the binary packages of glibc > > from unstable. It passes when run with only packages from testing. In > > tabular form: > > > > pass fail > > glibc from testing 2.31-16 > > openconnect from testing 8.10-2 > > versioned deps [0] from testing from unstable > > all others from testing from testing > > > > I copied some of the output at the bottom of this report. Unfortunately, > > the log is rather brief. > > > > Currently this regression is blocking the migration of glibc to testing > > [1]. Due to the nature of this issue, I filed this bug report against > > both packages. Can you please investigate the situation and reassign the > > bug to the right package? > > The openconnect auth-nonascii test uses two locales for its tests: > cs_CZ.UTF-8 and cs_CZ.ISO8859-2. It get those locales from the > locales-all package. Starting with glibc 2.31-14, non-UTF-8 locales are > deprecated and not provided anymore by locales-all. Therefore the test > fails as the cs_CZ.ISO8859-2 is not available anymore. > > One option would simply be to disable the test with the cs_CZ.ISO8859-2 > locale as done in the attached patch. If non-UTF-8 locales are not > supported anymore, I don't think we need to test them. > > Also please note that while this new glibc broke the openconnect > testsuite, it didn't break openconnect itself which is still functional > from the user point of view. In that regard there is no need to declare > a Breaks: openconnect on the glibc side. > > Regards, > Aurelien Hi, Thanks for the analysis - are these locales installed by alternative packages? Or completely gone? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
