Bug#1061493: consolekit: install PAM module and udev files into /usr
Control: notfound -1 1.2.6-3 On Wed, Mar 13, 2024 at 10:40:40PM +0100, Andreas Beckmann wrote: > Followup-For: Bug #1061493 > Control: found -1 1.2.6-3.1~exp1 > Control: severity -1 serious > Control: tag -1 ftbfs > > This change causes consolekit2 to to FTBFS in experimental: Indeed. As it was an NMU, I think the etiquette is for the NMUer to fix. In sid consolekit2 still builds cleanly. Therefore, marking notfound there. Michael, perhaps you would fix your NMU, or provide a better patch? Thanks Mark
Bug#1063099: openrc: NMU diff for 64-bit time_t transition
Control: severity -1 normal Preventing autoremoval due to uninstallable dpkg-dev version in testing. Mark
Bug#1066531: policykit-1: FTBFS: ../subprojects/mocklibc-1.0/src/netgroup-debug.c:25:3: error: implicit declaration of function ‘print_indent’ [-Werror=implicit-function-declaration]
Control: tags -1 patch I also bumped into this whilst rebuilding src:policykit-1 yesterday. There is an upstream patch[1], but it doesn't fix the build for me; I think it is patching the wrong files.The problem appears to be multiple copies of mocklibc. AFAICS ./test/mocklibc is not used in favour of a meson subproject. The pkla-compat tarball also has mocklibc, but that is also patched already. Getting the multiple layers of quilt and meson patches to work was unpleasant. So the attached patch may save you some time. HTH Mark [1] https://github.com/polkit-org/polkit/commit/0d78d1e4bf5ab3ce11678005b220aac0cfc5bee5 >From f50131bcb98802a66dcc1ee4cc952ca1cc9f8ff4 Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Wed, 13 Mar 2024 09:13:27 + Subject: [PATCH] Import upstream patch to fix embedded mocklibc subproject FTBFS with gcc 14. --- ...e-print_indent-function-to-the-file-.patch | 91 +++ debian/patches/series | 1 + 2 files changed, 92 insertions(+) create mode 100644 debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch diff --git a/debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch b/debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch new file mode 100644 index ..184161b7 --- /dev/null +++ b/debian/patches/06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch @@ -0,0 +1,91 @@ +--- a/subprojects/mocklibc.wrap b/subprojects/mocklibc.wrap +@@ -8,3 +8,5 @@ + patch_url = https://wrapdb.mesonbuild.com/v1/projects/mocklibc/1.0/2/get_zip + patch_filename = mocklibc-1.0-2-wrap.zip + patch_hash = 0280f96a2eeb3c023e5acf4e00cef03d362868218d4a85347ea45137c0ef6c56 ++diff_files = mocklibc-move-the-print_indent-function-to-the-file.patch ++ +--- /dev/null b/subprojects/packagefiles/mocklibc-move-the-print_indent-function-to-the-file.patch +@@ -0,0 +1,69 @@ ++From 0d78d1e4bf5ab3ce11678005b220aac0cfc5bee5 Mon Sep 17 00:00:00 2001 ++From: Vincent Mihalkovic ++Date: Fri, 8 Mar 2024 14:04:33 +0100 ++Subject: [PATCH] mocklibc: move the print_indent function to the file where it ++ is used ++MIME-Version: 1.0 ++Content-Type: text/plain; charset=UTF-8 ++Content-Transfer-Encoding: 8bit ++ ++This fixes build error with GCC >= 14 and clang >= 17, ++failing on: ++``` ++../subprojects/mocklibc-1.0/src/netgroup-debug.c:25:3: error: implicit declaration of function ‘print_indent’ [-Wimplicit-function-declaration] ++ 25 | print_indent(stream, indent); ++ | ^~~~ ++``` ++ ++Closes: #6 ++--- ++ src/netgroup-debug.c | 11 +++ ++ src/netgroup.c | 11 --- ++ 2 files changed, 11 insertions(+), 11 deletions(-) ++ ++diff --git a/src/netgroup-debug.c b/src/netgroup-debug.c ++index 81d6e728..46e5b25f 100644 ++--- a/src/netgroup-debug.c + b/src/netgroup-debug.c ++@@ -21,6 +21,17 @@ ++ #include ++ #include ++ +++/** +++ * Print a varaible indentation to the stream. +++ * @param stream Stream to print to +++ * @param indent Number of indents to use +++ */ +++static void print_indent(FILE *stream, unsigned int indent) { +++ int i; +++ for (i = 0; i < indent; i++) +++fprintf(stream, " "); +++} +++ ++ void netgroup_debug_print_entry(struct entry *entry, FILE *stream, unsigned int indent) { ++ print_indent(stream, indent); ++ ++diff --git a/src/netgroup.c b/src/netgroup.c ++index 06a8a894..e16e4519 100644 ++--- a/src/netgroup.c + b/src/netgroup.c ++@@ -71,17 +71,6 @@ static char *parser_copy_word(char **cur) { ++ return result; ++ } ++ ++-/** ++- * Print a varaible indentation to the stream. ++- * @param stream Stream to print to ++- * @param indent Number of indents to use ++- */ ++-void print_indent(FILE *stream, unsigned int indent) { ++- int i; ++- for (i = 0; i < indent; i++) ++-fprintf(stream, " "); ++-} ++- ++ /** ++ * Connect entries with 'child' type to their child entries. ++ * @param headentry Head of list of entries that need to be connected ++-- ++2.39.2 +--- a/meson.build b/meson.build +@@ -7,7 +7,7 @@ + 'prefix=/usr', + 'cpp_std=c++17', + ], +- meson_version: '>= 0.50.0', ++ meson_version: '>= 0.63.0', + ) + + pk_version = meson.project_version() diff --git a/debian/patches/series b/debian/patches/series index ddbec3c1..24156d33 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ +06-embedded-mocklibc-move-the-print_indent-function-to-the-file-.patch 04-fix-pkexec-fails-with-GDBus.Error-org.freedesktop.Po.patch 01_devuan-pkexec-pass-gtk-vars.patch 02_gettext.patch -- 2.39.2
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: severity -1 normal On Tue, Feb 06, 2024 at 05:43:41PM +, Mark Hindley wrote: > Whilst I am not an expert on this transition or the abi-compliance-checker, a > quick look at the logs[1] suggests this is a tool configuration issue and > src:consolekit2 may not require t64 migration. > > Can you clarify? I would appreciate some help here. Your patch FTBFS and I need to be convinced it is actually required before spending time on it. In the meantime, downgrading severity to prevent autoremoval. Thanks Mark
Bug#1063474: insserv messages about loops are too obtuse
Control: tags -1 upstream Jakob, Many thanks for this. Jesse, What are your thoughts? Is this something you can improve or address upstream? Thanks Mark
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Whilst I am not an expert on this transition or the abi-compliance-checker, a quick look at the logs[1] suggests this is a tool configuration issue and src:consolekit2 may not require t64 migration. Can you clarify? Thanks Mark [1] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libconsolekit-dev/time_t/log.txt
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Michael, On Tue, Jan 30, 2024 at 01:24:19AM +, mwhud...@debian.org wrote: > Source: consolekit2 > Version: 1.2.6-3 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t This patch appears to be broken and all the experimental builds FTBFS[1]. In addition, the bug severity is triggering autoremoval[2] That seems a sub-optimal combination. I am minded to reduce the bug severity. But I will wait for your response if you have a better suggestion. Thanks Mark [1] https://buildd.debian.org/status/package.php?p=consolekit2=experimental [2] https://udd.debian.org/cgi-bin/autoremovals.cgi
Bug#1061280: sysvinit crashes podman container on install
Control: tags -1 patch On Mon, Jan 22, 2024 at 02:37:39PM -0700, Sam Hartman wrote: > >>>>> "Mark" == Mark Hindley writes: > > Mark> Can you confirm? > > I agree that should work. > I have enough confidence and am busy enough today that I don't want to > build just to apply the patch. Thanks. Mark
Bug#1061280: sysvinit crashes podman container on install
Sam, Thanks for this. A quick look at sysvinit-core postinst reveals: restart=yes if ischroot --default-true ; then restart=no fi if [ -n "${DPKG_ROOT:-}" ]; then restart=no fi # If systemd is running, don't restart init or doing any initctl # migration. if [ -d "$DPKG_ROOT/run/systemd/system" ]; then restart=no fi if [ "$(uname -s)" = "GNU" ]; then restart=no fi if [ "$restart" = "yes" ]; then do_restart else echo "Not restarting sysvinit" fi My initial thought is that restart should really be 'no' if it is a new sysvinit-core installation. The attached patch fixes sysvinit-core installation within a podman container for me. I need to do more testing to check that it doesn't cause breakage elsewhere. Can you confirm? Thanks Mark >From a14a542cf08db3ef53a154d0366e873375662f4a Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Mon, 22 Jan 2024 16:45:11 + Subject: [PATCH] d/sysvinit-core.postinst: don't do_restart() for new installations. Closes: #1061280 --- debian/sysvinit-core.postinst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/sysvinit-core.postinst b/debian/sysvinit-core.postinst index ecb27a5b..d0ac5841 100755 --- a/debian/sysvinit-core.postinst +++ b/debian/sysvinit-core.postinst @@ -112,6 +112,9 @@ fi restart=yes +if [ -z "${oldver}" ]; then +restart=no +fi if ischroot --default-true ; then restart=no fi -- 2.39.2
Bug#1061297: libelogind0: does not implement all ABI required by important packages like procps
Simon, Thanks for this. On Mon, Jan 22, 2024 at 10:47:08AM +, Simon McVittie wrote: > Package: libelogind0 > Version: 252.9-1debian3 > Severity: important > Tags: trixie sid > > Steps to reproduce: attempt to install a Debian unstable virtual machine > (I used amd64) with sysvinit-core, libpam-elogind, dbus-x11, and a small > X11 system (I used xdm and openbox). > > Expected result: libelogind0 is a drop-in replacement for libsystemd0 in > this scenario, This used to be the case, but in sid/trixie to resolve[1] the lag in upstream elogind releases[2], we now have a patch for elogind which enables it to use libsystemd0 directly[3]. That means that the expected dependencies are now libpam-elogind -> elogind -> libsystemd0 with procps installable and libelogind0 not installed. So, I am curious why libelogind0 was being installed in your VM. Did you request it specifically? Bin:libelogind0 is still built by src:elogind and available in the archive. I hesitated to remove it before being certain that the elogind cgroups patch to use libsystemd0 was reliable. But maybe libelogind0 should become a dependency package to smooth upgrades? Or is there another detail in the dependency chain I have missed? Mark [1] https://bugs.debian.org/1052064 [2] Upstream has still not released 254 [3] https://git.devuan.org/devuan/elogind/src/branch/debian/debian/patches/Use-libsystemd0-compatible-cgroups-layout.patch
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Chris, Thanks On Wed, Dec 06, 2023 at 05:57:55PM +0100, Chris Hofstaedtler wrote: > * Mark Hindley : > > On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > > > Please note that the start target refers to a non-existing > > > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > > > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > > > reference to rtc0 that probably needs fixing for Hurd as well. > > > > Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. > > That would be my understanding as well. > > However on linux, the file should be named 85-hwclock.rules again. > Maybe this could be fixed too? Of course, queued and pending. > For hurd (and maybe linux), the big question remains, _if_ updating > the hwclock should be done by hwclock.sh by default. > I don't know the answer to this design question for hurd, or for > linux-with-sysvinit systems. I don't have a definitive answer either, but either way the script should not fail on Hurd and by downgrading the Depends to Recommends it is easy to change the behaviour if it is not to your liking. Mark
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Martin, On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote: > Please note that the start target refers to a non-existing > /usr/lib/udev/rules.d/85-hwclock.rules. The correct file is > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a > reference to rtc0 that probably needs fixing for Hurd as well. Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd. > Anyhow, what I get with the patched init script: > > [2023-12-06 18:04](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh start > [2023-12-06 18:04](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh restart > Saving the system clock to CMOS. > Hardware Clock updated to Wed Dec 6 18:05:05 EET 2023. > [2023-12-06 18:05](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh stop > Saving the system clock to CMOS. > Hardware Clock updated to Wed Dec 6 18:05:12 EET 2023. > [2023-12-06 18:05](HURD i386)perkelix@pxeth:~$ LC_ALL=C sudo > /etc/init.d/hwclock.sh show > 2023-12-06 18:05:18.129566+02:00 Thanks. Looks OK to me. Mark
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Control: tags -1 = patch Svante, On Wed, Dec 06, 2023 at 02:20:09PM +0100, Svante Signell wrote: > On a qemu Hurd image: > > /sbin/hwclock --help | grep rtc > --directisa use the ISA bus instead of /dev/rtc0 access > > /sbin/hwclock --directisa --show > 2023-12-06 14:17:54.949951+01:00 Many thanks, that is a great help. Could you and Martin test this patch, please? I also propose downgrading the initscripts Depends: util-linux-extra to Recommends. Even on non-systemd systems, hwclock.sh is far from essential as many now use NTP and hwclock.sh already handles a missing /sbin/hwclock gracefully. Mark commit acdbb98f05db8f24ddc9e72adb2b6a0982e69748 Author: Mark Hindley Date: Wed Dec 6 10:20:41 2023 + hwclock.sh: support HURD direct ISA I/O. Closes: #1057634 diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh b/debian/src/initscripts/etc/init.d/hwclock.sh index a9872b64..055508e7 100644 --- a/debian/src/initscripts/etc/init.d/hwclock.sh +++ b/debian/src/initscripts/etc/init.d/hwclock.sh @@ -38,13 +38,24 @@ hwclocksh() # Updates the Hardware Clock with the System Clock time. # This will *override* any changes made to the Hardware Clock, # for example by the Linux kernel when NTP is in use. -log_action_msg "Saving the system clock to /dev/$HCTOSYS_DEVICE" -if /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc; then -verbose_log_action_msg "Hardware Clock updated to `date`" -fi + if [ "$(uname -s)" = GNU ]; then + log_action_msg "Saving the system clock to CMOS" + /sbin/hwclock --directisa --systohc + else + log_action_msg "Saving the system clock to /dev/$HCTOSYS_DEVICE" + /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc + fi +if [ $? -eq 0 ]; then + verbose_log_action_msg "Hardware Clock updated to `date`" + fi + ;; show) -/sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show + if [ "$(uname -s)" = GNU ]; then + /sbin/hwclock --directisa --show + else + /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --show + fi ;; *) log_success_msg "Usage: hwclock.sh {stop|reload|force-reload|show}"
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Chris, Thanks for your input. On Wed, Dec 06, 2023 at 11:56:56AM +0100, Chris Hofstaedtler wrote: > * Mark Hindley [231206 11:42]: > > Is hwclock actually useful on Hurd? I (naively) expected it to be linux > > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used > > in the > > initscripts just wrong on Hurd? > > I have zero knowledge about hurd, but it looks like[1] hwclock is built > with CMOS support on hurd. So maybe it could work? > > It certainly is built without the RTC support, so --rtc=... doesn't > work. A superficial attempt on exodar.debian.net isn't particularly encouraging: leepen@exodar:~$ /sbin/hwclock --test hwclock from util-linux 2.39.2 System Time: 1701863851.810595 No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method. I suggest we wait for a response from the Hurd experts. But maybe util-linux-extra should be arch:linux-any? Mark
Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'
Control: tags -1 moreinfo Martin, Thanks for this On Wed, Dec 06, 2023 at 11:16:57AM +0200, Martin-Éric Racine wrote: > Package: initscripts > Version: 3.08-3 > Severity: important > > $ LC_ALL=C sudo invoke-rc.d hwclock.sh restart > Saving the system clock to /dev/rtc0. > /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0' > > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: hurd-i386 (i686-AT386) > > Kernel: GNU-Mach 1.8+git20230830-486/Hurd-0.9 So you are running Hurd. I have very little experience of that arch, so would appreciate some more information from you. > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages initscripts depends on: > ii sysv-rc 3.08-3 > ii sysvinit-utils3.08-3 > ii util-linux-extra 2.39.3-2 Is hwclock actually useful on Hurd? I (naively) expected it to be linux only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used in the initscripts just wrong on Hurd? Does your Hurd system usually have util-linux-extra installed or was it only pulled in by the initscript dependency? Mark [1] https://salsa.debian.org/debian/util-linux/-/blob/master/debian/util-linux-extra.install
Bug#1057419: consolekit2 FTCBFS: configures twice - once for the build architecture and fails
Control: tags -1 pending Helmut, Many thanks for spotting this. Queued for next upload. Mark
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
On Sat, Dec 02, 2023 at 01:02:48AM +0100, Lorenzo wrote: > > > > The cronjob that will be removed soon is still a problem as it checks > > the arrays periodically > > I'm not saying that it's not a problem, but I think it's a separate bug. > Also, before doing any attempts on this, Matthew has to say if he's ok > with maintaining cronjobs in this package and if yes, how this should > be done. I think he has already said he isn't happy with that. I have already submitted a bug with patch to reinstate the cron jobs[1] alongside the systemd timers. Mark [1] https://bugs.debian.org/1055994
Bug#1057122: initscripts has an undeclared file conflict on /usr/lib/udev/hwclock-set
Helmut, Thanks for this On Tue, Nov 28, 2023 at 10:27:41AM +0100, Helmut Grohne wrote: > Package: initscripts > Version: 3.08-3~bpo12+1 > Severity: serious > User: debian...@lists.debian.org > Usertags: fileconflict > Control: affects -1 + util-linux > Tags: bookworm > > initscripts has an undeclared file conflict. This may result in an > unpack error from dpkg. > > The file /usr/lib/udev/hwclock-set is contained in the packages > * initscripts/3.08-3~bpo12+1 as present in bookworm-backports > * util-linux/2.36.1-8+deb11u1 as present in bullseye|bullseye-security Are the suites and versions reported here really the problematic ones? I agree there is a conflict, but I think it is between initscripts/3.08-3~bpo12+1 in bookworm-backports and util-linux-extra/2.38.1-5 in bookworm. My proposed fix is attached. It reverts the transition of the hwclock machinery to initscripts, since this is still present in bookworm src:util-linux. Or, have I misunderstood? Best wishes, Mark diff --git a/debian/control b/debian/control index 551b7abc..02bfe1b5 100644 --- a/debian/control +++ b/debian/control @@ -99,15 +99,12 @@ Multi-Arch: foreign Depends: sysvinit-utils (>= 3.05-1), sysv-rc | file-rc | openrc, - util-linux-extra, ${misc:Depends}, Recommends: e2fsprogs, psmisc, Breaks: udev (<< 254.3-1), - util-linux-extra (<< 2.39.2-2.1~) Replaces: udev (<< 254.3-1), - util-linux-extra (<< 2.39.2-2.1~) Description: scripts for initializing and shutting down the system The scripts in this package initialize a standard Debian system at boot time and shut it down at halt or reboot time. diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst index 0074f2a3..eb126710 100755 --- a/debian/initscripts.postinst +++ b/debian/initscripts.postinst @@ -42,7 +42,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness hostname.sh mountdevsubfs. checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \ mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \ udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \ - bootlogs rc.local rmnologin hwclock.sh" + bootlogs rc.local rmnologin" for F in $INITSCRIPTS; do if [ -x /etc/init.d/$F ]; then diff --git a/debian/initscripts.postrm b/debian/initscripts.postrm index 25bbb932..e53672dc 100755 --- a/debian/initscripts.postrm +++ b/debian/initscripts.postrm @@ -9,7 +9,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness hostname.sh mountdevsubfs. checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \ mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \ udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \ - bootlogs rc.local rmnologin hwclock.sh" + bootlogs rc.local rmnologin" case "$1" in purge) diff --git a/debian/src/initscripts/Makefile b/debian/src/initscripts/Makefile index 5da80089..b13eafa3 100644 --- a/debian/src/initscripts/Makefile +++ b/debian/src/initscripts/Makefile @@ -34,9 +34,6 @@ install: $(INSTALL) -d $(DESTDIR)$(sbindir)/. $(INSTALL) sbin/fsck.nfs $(DESTDIR)$(sbindir)/fsck.nfs - $(INSTALL_DATA) -Dt $(DESTDIR)/usr/lib/udev/rules.d usr/lib/udev/rules.d/hwclock.rules - $(INSTALL) usr/lib/udev/hwclock-set $(DESTDIR)/usr/lib/udev/hwclock-set - $(INSTALL) -d $(DESTDIR)/usr/share/man/man8 $(INSTALL_DATA) man/fsck.nfs.8 \ $(DESTDIR)/usr/share/man/man8/fsck.nfs.8 diff --git a/debian/src/initscripts/etc/default/hwclock b/debian/src/initscripts/etc/default/hwclock deleted file mode 100644 index 44b04312.. --- a/debian/src/initscripts/etc/default/hwclock +++ /dev/null @@ -1,2 +0,0 @@ -# Settings for the hwclock init script. -# See hwclock(5) for supported settings. diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh b/debian/src/initscripts/etc/init.d/hwclock.sh deleted file mode 100644 index a9872b64.. --- a/debian/src/initscripts/etc/init.d/hwclock.sh +++ /dev/null @@ -1,57 +0,0 @@ -#!/bin/sh - -### BEGIN INIT INFO -# Provides: hwclock -# Required-Start: -# Required-Stop: mountdevsubfs -# Should-Stop: umountfs -# Default-Start: S -# Default-Stop: 0 6 -# Short-Description: Save system clock to hardware on shutdown. -### END INIT INFO - -# Note: this init script and related code is only useful if you -# run a sysvinit system, without NTP synchronization. - -if [ -e /run/systemd/system ] ; then -exit 0 -fi - -unset TZ - -hwclocksh() -{ -HCTOSYS_DEVICE=rtc0 -[ ! -x /sbin/hwclock ] && return 0 -[ ! -r /etc/default/rcS ] || . /etc/default/rcS -[ ! -r /etc/default/hwclock ] || . /etc/default/hwclock - -. /lib/lsb/init-functions -verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_action_msg "$@"; } - -case "$1" in -start) -# start is handled by /usr/lib/udev/rules.d/85-hwclock.rules. -
Bug#1056363: initscripts: Backport 3.08 to stable (bookworm) for udev init script
Control: tags -1 pending On Wed, Nov 22, 2023 at 02:08:58AM +0800, Chen-Yu Tsai wrote: > Package: initscripts > Version: 3.08-3 > Severity: important > > Dear Maintainer, > > initscripts 3.08 needs to be backported to bookworm, as the systemd version > that removed the udev init script and forced initscripts to take over it was > already backported. I have uploaded src:sysvinit 3.08-3~bpo12+1. It is waiting in backports-new[1] Mark [1] https://ftp-master.debian.org/new/sysvinit_3.08-3~bpo12%2B1.html
Bug#1056321: elogind conflicts with same version libelogind0
Hi Thorsten, On Tue, Nov 21, 2023 at 12:58:40AM +0100, Thorsten Glaser wrote: > Did you forget to not build the libelogind0 binary package any more > then? It was a conscious decision on my part to keep it for now. I see 2 benefits:- 1. If we need to revert this approach, it will save a trip through NEW 2. I suppose somebody may have a use for libelogind0 or libelogind-dev, and I didn't want to remove that option. Is that reasonable? Thanks and best wishes Mark
Bug#1056176: insserv: please support DPKG_ROOT
Control: tags -1 pending Thanks. Queued for the next upload. Mark
Bug#1056049: consolekit2: Not buildable on hurd-i386
Control: tags -1 pending Svante, Many thanks for this. Queued for upload. Best wishes Mark
Bug#1055994: mdadm: Please restore cron scripts for use when systemd timers are not available
Package: mdadm Version: 4.2+20230508-7 Severity: normal Tags: patch Dear Daniel, As was discussed in #1037496, the removal of cron scripts from mdadm means that no mdamd housekeeping is performed when systemd timers are not available. I attach a patch which restores the cron scripts in mdadm, but protects them with a test for running systemd. This should mean that housekeeping tasks are performed an all systems, but that there is no duplication when systemd timers are available. I hope this is an acceptable compromise and I look forward to your comments. With best wishes Mark >From 1f4b2370e6ffaab0b6352b893f268e0fa39df55b Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Tue, 14 Nov 2023 19:52:52 + Subject: [PATCH] Restore cron fragments, but prefer systemd timers. --- debian/mdadm.cron.d | 12 debian/mdadm.cron.daily | 23 +++ debian/mdadm.maintscript | 2 -- debian/mdadm.postinst| 3 ++- 4 files changed, 37 insertions(+), 3 deletions(-) create mode 100644 debian/mdadm.cron.d create mode 100644 debian/mdadm.cron.daily diff --git a/debian/mdadm.cron.d b/debian/mdadm.cron.d new file mode 100644 index 000..63f186d --- /dev/null +++ b/debian/mdadm.cron.d @@ -0,0 +1,12 @@ +# +# cron.d/mdadm -- schedules periodic redundancy checks of MD devices +# +# Copyright © martin f. krafft +# distributed under the terms of the Artistic Licence 2.0 +# + +# By default, run at 00:57 on every Sunday, but do nothing unless the day of +# the month is less than or equal to 7. Thus, only run on the first Sunday of +# each month. crontab(5) sucks, unfortunately, in this regard; therefore this +# hack (see #380425). +57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ ! -d /run/systemd/system ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi diff --git a/debian/mdadm.cron.daily b/debian/mdadm.cron.daily new file mode 100644 index 000..8d1bfeb --- /dev/null +++ b/debian/mdadm.cron.daily @@ -0,0 +1,23 @@ +#!/bin/sh +# +# cron.daily/mdadm -- daily check that MD devices are functional +# +# Copyright © 2008 Paul Slootman +# distributed under the terms of the Artistic Licence 2.0 + +# As recommended by the manpage, run +# mdadm --monitor --scan --oneshot +# every day to ensure that any degraded MD devices don't go unnoticed. +# Email will go to the address specified in /etc/mdadm/mdadm.conf . +# +set -eu + +MDADM=/sbin/mdadm +[ -x $MDADM ] || exit 0 # package may be removed but not purged + +[ -d /run/systemd/system ] || exit 0 # Defer to systemd timers if possible + +[ -e /etc/default/mdadm ] && . /etc/default/mdadm +[ $AUTOSCAN = false ] && exit 0 + +exec $MDADM --monitor --scan --oneshot diff --git a/debian/mdadm.maintscript b/debian/mdadm.maintscript index 17b5e28..1298978 100644 --- a/debian/mdadm.maintscript +++ b/debian/mdadm.maintscript @@ -1,4 +1,2 @@ -rm_conffile /etc/cron.d/mdadm 4.2+20230227-1~ -rm_conffile /etc/cron.daily/mdadm 4.2+20230227-1~ rm_conffile /etc/init.d/mdadm 4.2+20230227-1~ rm_conffile /etc/init.d/mdadm-waitidle 4.2+20230227-1~ diff --git a/debian/mdadm.postinst b/debian/mdadm.postinst index c8a3420..021912a 100755 --- a/debian/mdadm.postinst +++ b/debian/mdadm.postinst @@ -76,7 +76,8 @@ AUTOCHECK=$AUTOCHECK # AUTOSCAN: # should mdadm check once a day for degraded arrays? See -# /lib/systemd/system/mdmonitor-oneshot.service +# /lib/systemd/system/mdmonitor-oneshot.service and +# /etc/cron.daily/mdadm. AUTOSCAN=$AUTOSCAN # START_DAEMON: -- 2.39.2
Bug#810018: Bug #810018: Consider shipping pidof with procps
Craig, Thanks for this. On Mon, Nov 13, 2023 at 08:08:37PM +1100, Craig Small wrote: > I'll need the assistance of the sysvinit-utils maintainers (CC'ed) as >well, as pidof will be moving from that package. IIUC, the proposal[1] was to create a new Essential procps-base just containing pidof. Otherwise bin:procps would have to become Essential itself. Its installed size is about 20 times larger than sysvinit-util and that wouldn't contribute to shrinking the Essential set. I think this approach would also require a debian-devel email announcing the addition to the Essential set and I suppose the new src:procps will need a trip through NEW. >So I'm looking at https://wiki.debian.org/PackageTransition >and assuming procps is 2:4.0.4-2 and sysvinit-utils is 3.08-3 >I would create procps 2:4.0.4-3 with pidof and Breaks: sysvinit-utils >(<< 3.0.8-4) and Replaces: sysvinit-utils (<< 3.0.8-4) >sysvinit-utils maintainers create 3.08-4 without pidof and have Breaks: >procps (<< 2:4.0.4-3) The dependencies would then be:- procps-base: Breaks: sysvinit-utils (<< 3.0.8-4) Replaces: sysvinit-utils (<< 3.0.8-4) sysvinit-utils without pidof: Breaks: procps-base (<< 2:4.0.4-3) I hope I have understood the previous discussions correctly . I am not trying to stand in the way at all, just ensure that this transition is worthwhile and done correctly. With best wishes Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810018#10
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Control: block -1 1055562 Helmut, On Tue, Nov 07, 2023 at 08:39:23AM +, Mark Hindley wrote: > I think all suitable dependencies now use default-logind | logind. I will > check that is correct. If it is, libpam-elogind-compat could just be > removed. It was never available outside experimental. AFAICS, all supported cases now use Depends: default-logind | logind or have demoted the Depends to Recommends. I have filed a RM request[1]. Mark [1] https://bugs.debian.org/1055562
Bug#1055562: RM: libpam-elogind-compat/experimental -- ROM; Not required anymore.
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hello, Please remove src:libpam-elogind-compat from experimental. It has served its purpose and is no longer required now the virtual packages default-logind and logind are used in all Depends. Thanks Mark
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Helmut, Thanks for this. libpam-elogind-compat was used when elogind was first introduced as a hack to circumvent missing dependencies and allow testing. I think all suitable dependencies now use default-logind | logind. I will check that is correct. If it is, libpam-elogind-compat could just be removed. It was never available outside experimental. Mark
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Control: tags -1 upstream Control: retitle -1 Upstream testsuite fails to produce deterministic results Santiago, On Sun, Oct 29, 2023 at 02:39:44PM +0100, Santiago Vila wrote: > However, I can create a machine for you to reproduce the problem. Thanks. I have reproduced on your provided machine, but still not locally and I can't identify the underlying difference between the builds. In the failure case the problem is in the upstream testsuite, specifically the test for #491391 in tests/run-testsuite which produces init.d: bootchart four one rmnologin three two insserv: override rc0.d: rc1.d: rc2.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc3.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc4.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc5.d: S01one S01three S01two S02four S98rmnologin S99bootchart rc6.d: rcS.d: error: incorrect 5 sequence bootchart not before rmnologin The same failure mode appears to be responsible for armel and armhf autopkgtest failures logged on ci.debian.net[1] As Ian pointed out[2], there are significant and surprising changes in looping order and behaviour between the successful and failing testsuites. The diff is attached. Having said that, I still can't reproduce locally or determine a good fix. Hopefully Jesse will have a useful contribution Mark [1] https://ci.debian.net/data/autopkgtest/unstable/armel/i/insserv/38435862/log.gz [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052942#15 diff -u --label /sshx\:atlas\:/tmp/build.log --label /home/mark/src/debian/insserv/build.log /tmp/tramp.mDUEXG.log /home/mark/src/debian/insserv/build.log --- /sshx:atlas:/tmp/build.log +++ /home/mark/src/debian/insserv/build.log @@ -4,8 +4,15 @@ dpkg-buildpackage: info: source changed by Mark Hindley dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 - fakeroot debian/rules clean -echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection +dpkg-source: info: using patch list from debian/patches/series +dpkg-source: info: applying install-binaries-ignore-PREFIX.patch +dpkg-source: info: applying 11_debian_conf.patch +dpkg-source: info: applying 110_portmap.patch +dpkg-source: info: applying warn_in_ignore_mode.patch +dpkg-source: info: applying 0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch +dpkg-source: info: applying 0005-Fix-spelling-error-in-manpage.patch + debian/rules clean +echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection dh clean --with=bash-completion dh_auto_clean @@ -18,7 +25,7 @@ make[1]: Leaving directory '/home/mark/insserv-1.24.0' dh_clean debian/rules build -echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection +echo -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection dh build --with=bash-completion dh_update_autotools_config @@ -31,14 +31,14 @@ cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe -c map.c cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe -c listing.c cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/home/mark/insserv-1.24.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DINITDIR=\"/etc/init.d\" -DINSCONF=\"/etc/insserv.conf\" -pipe insserv.c -c -insserv.c: In function ‘main’: -insserv.c:2923:20: warning: ignoring return value of ‘asprintf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] +insserv.c: In function 'main': +insserv.c:2923:20: warning: ignoring return value of 'asprintf' declared with attribute 'warn_unused_result' [-Wunused-res
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Lucas, I am afraid I still cannot reproduce this. I attach my successful .buildinfo. What are the differences to yours? Thanks Mark Format: 1.0 Source: insserv Binary: insserv insserv-dbgsym Architecture: amd64 Version: 1.24.0-1 Checksums-Md5: 3c928ff0990c2942950fa368b3978086 79480 insserv-dbgsym_1.24.0-1_amd64.deb 9bffd1e3395d57a5979030bc472dc80c 50572 insserv_1.24.0-1_amd64.deb Checksums-Sha1: aa26018adc027c1af58704991d3339c1a43dccf2 79480 insserv-dbgsym_1.24.0-1_amd64.deb 1d1a7b8f6e5b5ea864a7661f34e767b9a93e4b77 50572 insserv_1.24.0-1_amd64.deb Checksums-Sha256: 39912ad2e18538a91ae397467a6cd96519dd948fee2ed90b39c40b4477352bc1 79480 insserv-dbgsym_1.24.0-1_amd64.deb e4e58a1a6a3cb6a68e205341606b1702ef10dd5bd6d43af03e123b536b4cc8f8 50572 insserv_1.24.0-1_amd64.deb Build-Origin: Debian Build-Architecture: amd64 Build-Date: Sun, 29 Oct 2023 13:16:40 + Build-Path: /build/insserv-1.24.0 Build-Tainted-By: merged-usr-via-aliased-dirs Installed-Build-Depends: autoconf (= 2.71-3), automake (= 1:1.16.5-1.3), autopoint (= 0.21-12), autotools-dev (= 20220109.1), base-files (= 13), base-passwd (= 3.6.1), bash (= 5.2.15-2+b2), bash-completion (= 1:2.11-8), binutils (= 2.40.50.20230625-1), binutils-common (= 2.40.50.20230625-1), binutils-x86-64-linux-gnu (= 2.40.50.20230625-1), bsdextrautils (= 2.38.1-5+b1), bsdutils (= 1:2.38.1-5+b1), build-essential (= 12.10), bzip2 (= 1.0.8-5+b1), coreutils (= 9.1-1), cpp (= 4:12.3.0-1), cpp-10 (= 10.4.0-9), cpp-11 (= 11.4.0-1), cpp-12 (= 12.3.0-5), cpp-6 (= 6.5.0-2), cpp-8 (= 8.4.0-4), cpp-9 (= 9.5.0-3), dash (= 0.5.12-6), debconf (= 1.5.82), debhelper (= 13.11.4), debianutils (= 5.7-0.4), dh-autoreconf (= 20), dh-strip-nondeterminism (= 1.13.1-1), diffutils (= 1:3.8-4), dpkg (= 1.21.22), dpkg-dev (= 1.21.22), dwz (= 0.15-1), file (= 1:5.44-3), findutils (= 4.9.0-4), g++ (= 4:12.3.0-1), g++-12 (= 12.3.0-5), gcc (= 4:12.3.0-1), gcc-10 (= 10.4.0-9), gcc-10-base (= 10.4.0-9), gcc-11 (= 11.4.0-1), gcc-11-base (= 11.4.0-1), gcc-12 (= 12.3.0-5), gcc-12-base (= 12.3.0-5), gcc-13-base (= 13.1.0-7), gcc-6 (= 6.5.0-2), gcc-6-base (= 6.5.0-2), gcc-7-base (= 7.4.0-14), gcc-8 (= 8.4.0-4), gcc-8-base (= 8.4.0-4), gcc-9 (= 9.5.0-3), gcc-9-base (= 9.5.0-3), gettext (= 0.21-12), gettext-base (= 0.21-12), grep (= 3.8-5), groff-base (= 1.22.4-10), gzip (= 1.12-1), hostname (= 3.23+nmu1), init-system-helpers (= 1.65.2), intltool-debian (= 0.35.0+20060710.6), libacl1 (= 2.3.1-3), libarchive-zip-perl (= 1.68-1), libasan3 (= 6.5.0-2), libasan5 (= 9.5.0-3), libasan6 (= 11.4.0-1), libasan8 (= 13.1.0-7), libatomic1 (= 13.1.0-7), libattr1 (= 1:2.5.1-4), libaudit-common (= 1:3.0.9-1), libaudit1 (= 1:3.0.9-1), libbinutils (= 2.40.50.20230625-1), libblkid1 (= 2.38.1-5+b1), libbz2-1.0 (= 1.0.8-5+b1), libc-bin (= 2.36-9), libc-dev-bin (= 2.36-9), libc6 (= 2.36-9), libc6-dev (= 2.36-9), libcap-ng0 (= 0.8.3-1+b3), libcap2 (= 1:2.66-4), libcc1-0 (= 13.1.0-7), libcilkrts5 (= 7.4.0-14), libcom-err2 (= 1.47.0-2), libcrypt-dev (= 1:4.4.35-1), libcrypt1 (= 1:4.4.35-1), libctf-nobfd0 (= 2.40.50.20230625-1), libctf0 (= 2.40.50.20230625-1), libdb5.3 (= 5.3.28+dfsg2-1), libdebconfclient0 (= 0.270), libdebhelper-perl (= 13.11.4), libdpkg-perl (= 1.21.22), libelf1 (= 0.188-2.1), libfile-find-rule-perl (= 0.34-3), libfile-stripnondeterminism-perl (= 1.13.1-1), libgcc-10-dev (= 10.4.0-9), libgcc-11-dev (= 11.4.0-1), libgcc-12-dev (= 12.3.0-5), libgcc-6-dev (= 6.5.0-2), libgcc-8-dev (= 8.4.0-4), libgcc-9-dev (= 9.5.0-3), libgcc-s1 (= 13.1.0-7), libgcrypt20 (= 1.10.2-2), libgdbm-compat4 (= 1.23-3), libgdbm6 (= 1.23-3), libgmp10 (= 2:6.2.1+dfsg1-1.1), libgomp1 (= 13.1.0-7), libgpg-error0 (= 1.46-1), libgprofng0 (= 2.40.50.20230625-1), libgssapi-krb5-2 (= 1.20.1-2), libicu72 (= 72.1-3), libisl19 (= 0.20-2), libisl22 (= 0.22.1-1), libisl23 (= 0.26-3), libitm1 (= 13.1.0-7), libjansson4 (= 2.14-2), libk5crypto3 (= 1.20.1-2), libkeyutils1 (= 1.6.3-2), libkrb5-3 (= 1.20.1-2), libkrb5support0 (= 1.20.1-2), liblsan0 (= 13.1.0-7), liblz4-1 (= 1.9.4-1), liblzma5 (= 5.4.1-0.2), libmagic-mgc (= 1:5.44-3), libmagic1 (= 1:5.44-3), libmd0 (= 1.1.0-1), libmount1 (= 2.38.1-5+b1), libmpc3 (= 1.3.1-1), libmpfr6 (= 4.2.0-1), libmpx2 (= 8.4.0-4), libnsl-dev (= 1.3.0-2), libnsl2 (= 1.3.0-2), libnumber-compare-perl (= 0.03-3), libpam-modules (= 1.5.2-6), libpam-modules-bin (= 1.5.2-6), libpam-runtime (= 1.5.2-6), libpam0g (= 1.5.2-6), libpcre2-8-0 (= 10.42-1), libperl5.36 (= 5.36.0-7), libpipeline1 (= 1.5.7-1), libquadmath0 (= 13.1.0-7), libseccomp2 (= 2.5.4-1+b3), libselinux1 (= 3.4-1+b6), libsmartcols1 (= 2.38.1-5+b1), libssl3 (= 3.0.9-1), libstdc++-12-dev (= 12.3.0-5), libstdc++6 (= 13.1.0-7), libsub-override-perl (= 0.09-4), libsystemd0 (= 253-4), libtext-glob-perl (= 0.11-3), libtinfo6 (= 6.4-4), libtirpc-common (= 1.3.3+ds-1), libtirpc-dev (= 1.3.3+ds-1), libtirpc3 (= 1.3.3+ds-1),
Bug#1053760: util-linux-extra: obsolete conffiles left behind
Sven, It was a conscious decision (on my part) not to remove the conffiles at this stage. Whilst I accept this leaves cruft on systems that don't have bin:initscripts installed, it has the benefit that user modified conffiles are preserved during the transition to initscripts, as required by the Policy. I think this cleanup can happen saftely in the Forky release cycle. For reference, the udev maintainers have recently tried this cleanup at an earlier stage and it has not been straightforward. Mark
Bug#1053760: util-linux-extra: obsolete conffiles left behind
Sven, It was a conscious decision (on my part) not to remove the conffiles at this stage. Whilst I accept this leaves cruft on systems that don't have initscripts installed, it has the benefit that user modified conffiles are preserved during the transition to bin:initscripts, as required by the Policy. I think this cleanup can happen saftely in the Forky release cycle. For reference, the udev maintainers have recently tried this cleanup at an earlier stage and it has not been straightforward. Mark
Bug#1053301: udev.postinst removes valid /etc/rc*.d/ symlinks
Control: tags -1 patch Control: affects -1 initscripts Control: severity -1 serious Justification: Breaks unrelated packages, breaks non-systemd boot Michael, Please find a patch below that addresses this issue in my test setup. I can offer to NMU if you would like? I have provided an easy means to reproduce the bug and a clear justfication for why I think this is an RC bug. If you disagree, please explain why, rather than just changing the severity. Thanks. Best wishes Mark diff --git a/debian/changelog b/debian/changelog index fe1f4bc..ec8a75a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +systemd (254.5-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * d/udev.postinst: Correct version number test for dropping +/etc/init.d/udev and only remove /etc/rc?.d/symlinks if +/etc/init.d/udev doesn't exist. (Closes: #1053301) + + -- Mark Hindley Wed, 04 Oct 2023 18:30:36 +0100 + systemd (254.5-1) unstable; urgency=medium * New upstream version 254.5 diff --git a/debian/udev.postinst b/debian/udev.postinst index 84ff782..04bafa2 100644 --- a/debian/udev.postinst +++ b/debian/udev.postinst @@ -11,7 +11,8 @@ case "$1" in # update/create hwdb before we (re)start udev update_hwdb -if dpkg --compare-versions "$2" lt-nl "254.1-4~"; then +if dpkg --compare-versions "$2" lt-nl "254.3-1~" && +[ ! -f /etc/init.d/udev ] ; then update-rc.d udev remove || true fi ;;
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
Control: tags -1 moreinfo Ian On Wed, Sep 27, 2023 at 10:33:32PM +0100, Ian Jackson wrote: > Mark Hindley writes ("Bug#1052942: insserv: FTBFS: insserv: Could not read > script nolsbheader: No such file or directory"): > > Thanks for this. However, I am currently unable to repoduce this > > failure in my customary pbuilder setup. And it doesn't appear at > > reproducible builds either[1] > > I just tried this myself with my usual sbuild setup and it succeeded > there too[1]. Thanks for your confirmation. > Lucas, I think something from your rebuild environment > (a chroot of some kind I presume) must be triggering this failure. Is > there some way we can reproduce it more precisely (eg, a buildinfo > file?) Yes, I agree a buildinfo file might give a hint. > I looked at the build log > http://qa-logs.debian.net/2023/09/25/insserv_1.24.0-1_unstable.log > and compared it to the one from my sbuild, using diff. There are a > lot of changes to the "furniture" but also there are noise changes to > the output of the insserv test suite, including ordring changes of > passing tests. This seemed surprising to me. > > Mark, is the insserv test suite supposed to produce deterministic > output ? I have never had the need to look at the testsuite since I started looking after the package. A quick look now doesn't immediately reveal something that would obviously change the order of the tests. I tried again locally with make -j8 and still could not reproduce any failure. Mark
Bug#1053301: udev.postinst removes valid /etc/rc*.d/ symlinks
Control: reopen -1 "Bill Brelsford " Control: reassign -1 udev 254.3-1 Control: severity -1 severe Justification: Breaks unrelated software; causes boot failure on some systems Dear systemd maintainers, As Bill has reported here, the new udev.postinst is breaking systems not using systemd as PID 1. On Fri, Sep 29, 2023 at 09:51:21PM -0700, Bill Brelsford wrote: > When upgrading (with aptitude), initscripts (3.08-1) is set up > before udev (254.4-1). Udev claims to remove the "obsolete > conffile /etc/init.d/udev", but it's still there. However, the > rc*.d symlinks are not -- "update-rc.d udev defaults" fixes it. It is reproducible by installing trixie udev and initscripts in a bookworm chroot: bookworm-chroot:/# dpkg --no-pager -l udev initscripts Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii initscripts3.06-4 all scripts for initializing and shutting down the system ii udev 252.12-1~deb12u1 amd64/dev/ and hotplug management daemon bookworm-chroot:/# ls -l /etc/rc?.d/*udev* lrwxrwxrwx 1 root root 14 Oct 3 08:36 /etc/rc0.d/K01udev -> ../init.d/udev lrwxrwxrwx 1 root root 14 Oct 3 08:36 /etc/rc6.d/K01udev -> ../init.d/udev lrwxrwxrwx 1 root root 14 Oct 3 08:36 /etc/rcS.d/S02udev -> ../init.d/udev bookworm-chroot:/# apt install --no-install-recommends -t trixie udev initscripts Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: libudev1 systemd systemd-dev Suggested packages: systemd-container systemd-homed systemd-userdbd systemd-boot systemd-resolved libfido2-1 libqrencode4 libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0 polkitd python3:any python3-pefile Recommended packages: default-dbus-system-bus | dbus-system-bus systemd-timesyncd | time-daemon The following NEW packages will be installed: systemd systemd-dev The following packages will be upgraded: initscripts libudev1 udev 3 upgraded, 2 newly installed, 0 to remove and 60 not upgraded. Need to get 5299 kB of archives. After this operation, 11.8 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://deb.debian.org/debian trixie/main amd64 udev amd64 254.4-1 [1756 kB] Get:2 http://deb.debian.org/debian trixie/main amd64 systemd-dev all 254.4-1 [54.7 kB] Get:3 http://deb.debian.org/debian trixie/main amd64 systemd amd64 254.4-1 [3304 kB] Get:4 http://deb.debian.org/debian trixie/main amd64 libudev1 amd64 254.4-1 [120 kB] Get:5 http://deb.debian.org/debian trixie/main amd64 initscripts all 3.08-1 [64.5 kB] Fetched 5299 kB in 1s (4686 kB/s) debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 6627 files and directories currently installed.) Preparing to unpack .../udev_254.4-1_amd64.deb ... Unpacking udev (254.4-1) over (252.12-1~deb12u1) ... Selecting previously unselected package systemd-dev. Preparing to unpack .../systemd-dev_254.4-1_all.deb ... Unpacking systemd-dev (254.4-1) ... Selecting previously unselected package systemd. Preparing to unpack .../systemd_254.4-1_amd64.deb ... Unpacking systemd (254.4-1) ... Preparing to unpack .../libudev1_254.4-1_amd64.deb ... Unpacking libudev1:amd64 (254.4-1) over (252.12-1~deb12u1) ... Setting up libudev1:amd64 (254.4-1) ... (Reading database ... 7562 files and directories currently installed.) Preparing to unpack .../initscripts_3.08-1_all.deb ... Unpacking initscripts (3.08-1) over (3.06-4) ... Setting up initscripts (3.08-1) ... Installing new version of config file /etc/init.d/brightness ... Setting up systemd-dev (254.4-1) ... Setting up systemd (254.4-1) ... Setting up udev (254.4-1) ... Removing obsolete conffile /etc/init.d/udev ... Processing triggers for libc-bin (2.36-9+deb12u1) ... bookworm-chroot:/# ls -l /etc/rc?.d/*udev* ls: cannot access '/etc/rc?.d/*udev*': No such file or directory It appears that the udev postinst is running after initscripts has been configured and removing the /etc/rc?.d/ udev symlinks. bookworm-chroot:/# dpkg-reconfigure initscripts bookworm-chroot:/# ls -l /etc/rc?.d/*udev* lrwxrwxrwx 1 root root 14 Oct 3 08:50 /etc/rc0.d/K01udev -> ../init.d/udev lrwxrwxrwx 1 root root 14 Oct 3 08:50 /etc/rc6.d/K01udev -> ../init.d/udev lrwxrwxrwx 1 root root 14 Oct 3 08:50 /etc/rcS.d/S02udev -> ../init.d/udev The relevant code in udev's postinst has: if dpkg --compare-versions "$2" lt-nl "254.1-4~"; then update-rc.d udev remove || true fi I think there are 2 issues here:- 1) update-rc.d shouldn't be called if /etc/init.d/udev exists and is not owned by bin:udev. 2) There appears to be a typo: the version of
Bug#1042082: Please take over udev SysV init script
Control: clone -1 -2 Control: retitle -2 udev.postinst removes valid /etc/rc*.d/ symlinks Bill On Fri, Sep 29, 2023 at 09:51:21PM -0700, Bill Brelsford wrote: > When upgrading (with aptitude), initscripts (3.08-1) is set up > before udev (254.4-1). Udev claims to remove the "obsolete > conffile /etc/init.d/udev", but it's still there. However, the > rc*.d symlinks are not -- "update-rc.d udev defaults" fixes it. This is a new issue. Cloning. Mark
Bug#1053092: initscripts: cannot upgrade to 3.08-1: APT dependency loop
Martin, Thanks for this. On Wed, Sep 27, 2023 at 08:22:33AM +0200, Lorenzo wrote: > Control: severity -1 whishlist > > Hi, > > On Wed, 27 Sep 2023 08:14:19 +0300 > Martin-Éric Racine wrote: > > > Kernel: Linux 6.5.0-1-686-pae (SMP w/1 CPU thread; PREEMPT) > > Kernel taint flags: TAINT_WARN > > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), > > LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > I guess this is the effect of > > https://salsa.debian.org/systemd-team/systemd/-/commit/eecd735541c9d5deb9cebd5f2512e7da8b4368a9 > > that adds a conflicts with initscripts. You can remove initscripts or > reassign to systemd as whishlist, explaining why you need both > initscripts and systemd-sysv installed. > > Regards, > Lorenzo > > > Package: initscripts > > Version: 3.07-1 > > Severity: important > > > > $ LC_ALL=C sudo apt-get --option Debug::pkgDepCache::AutoInstall=true > > install initscripts Reading package lists... Done > > Building dependency tree... Done > > Reading state information... Done > >Removing: udev:i386 as upgrade is not an option for > > initscripts:i386 (3.08-1) I am not sure there is a bug here anyway. there is an ongoing migration of /etc/init.d/udev from bin:udev to bin:initscripts. src:sysvinit 3.08-1 (which has taken over the file and breaks/replaces udev << 254.3-1 ) has migrated to testing[1], however the migration of src:systemd 254.4-1 is blocked by autopkgtest regressions[2]. Once a suitable version of src:systemd migrates to testing, I think apt will be able to resolve the dependencies. Mark [1] https://tracker.debian.org/news/1465552/sysvinit-308-1-migrated-to-testing/ [2] https://qa.debian.org/excuses.php?package=systemd
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
n-en.diff/Index Get:4 http://deb.debian.org/debian unstable/main amd64 Packages [9512 kB] Get:5 http://deb.debian.org/debian unstable/main Translation-en [7032 kB] Fetched 16.9 MB in 10s (1747 kB/s) Reading package lists... Building dependency tree... Reading state information... 176 packages can be upgraded. Run 'apt list --upgradable' to see them. I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D05apt-update finished I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D80no-man-db-rebuild starting I: Preseed man-db/auto-update to false I: user script /var/cache/pbuilder/build/cow.20068/tmp/hooks/D80no-man-db-rebuild finished I: -> Attempting to satisfy build-dependencies Note, using file '/build/insserv_1.24.0-1.dsc' to get the build dependencies Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: bash-completion debconf: delaying package configuration, since apt-utils is not installed 0 upgraded, 1 newly installed, 0 to remove and 176 not upgraded. Need to get 0 B/224 kB of archives. After this operation, 1489 kB of additional disk space will be used. Selecting previously unselected package bash-completion. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23021 files and directories currently installed.) Preparing to unpack .../bash-completion_1%3a2.11-8_all.deb ... Unpacking bash-completion (1:2.11-8) ... Setting up bash-completion (1:2.11-8) ... Processing triggers for man-db (2.11.2-2) ... Not building database; man-db/auto-update is not 'true'. Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: libfakeroot The following packages will be upgraded: fakeroot libfakeroot debconf: delaying package configuration, since apt-utils is not installed 2 upgraded, 0 newly installed, 0 to remove and 174 not upgraded. Need to get 0 B/95.0 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23787 files and directories currently installed.) Preparing to unpack .../libfakeroot_1.32.1-1_amd64.deb ... Unpacking libfakeroot:amd64 (1.32.1-1) over (1.31-1.2) ... Preparing to unpack .../fakeroot_1.32.1-1_amd64.deb ... Unpacking fakeroot (1.32.1-1) over (1.31-1.2) ... Setting up libfakeroot:amd64 (1.32.1-1) ... Setting up fakeroot (1.32.1-1) ... Processing triggers for man-db (2.11.2-2) ... Not building database; man-db/auto-update is not 'true'. Processing triggers for libc-bin (2.36-9) ... I: Copying back the cached apt archive contents I: Building the package I: Running cd /build/insserv-1.24.0/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc '--no-pre-clean' && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-genchanges -S > ../insserv_1.24.0-1_source.changes dpkg-buildpackage: info: source package insserv dpkg-buildpackage: info: source version 1.24.0-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Mark Hindley dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 debian/rules build echo -g -O2 -ffile-prefix-map=/build/insserv-1.24.0=. -fstack-protector-strong -Wformat -Werror=format-security -g -O2 -ffile-prefix-map=/build/insserv-1.24.0=. -fstack-protector-strong -Wformat -Werror=format-security dh build --with=bash-completion dh_update_autotools_config dh_autoreconf dh_auto_configure dh_auto_build make -j2 "INSTALL=install --strip-program=true" make[1]: Entering directory '/build/insserv-1.24.0' sed -r '\!@@BEGIN_SUSE@@!,\!@@(ELSE|END)_SUSE@@!d;\!@@(NOT|END)_SUSE@@!d' < insserv.8.in > insserv.8 cc -W -Wall -Wunreachable-code -g -O2 -ffile-prefix-map=/build/insserv-1.24.0=. -fstack-protector-st
Bug#1050375: Invalid command name "pg_connect"
Control: reassign -1 libpgtcl Control: retitle -1 libpgtcl not installed in default Tcl search path. On Wed, Aug 23, 2023 at 08:09:48PM +0200, Christoph Berg wrote: > Package: pfm > Version: 2.0.8-3 > Severity: grave > > pfm doesn't do anything useful here, it just produces a message popup > saying > > Connection to database foo has failed: > > invalid command name "pg_connect" Thanks. I believe this needs fixing in libpgtcl. Reassigning. Mark
Bug#1052316: udev postinst uses update-rc.d -f remove which breaks /etc.init.d/udev transition and non-systemd boot
Package: udev Version: 254.3-1 Severity: serious Justification: Breaks unrelated software, causes boot failure on some systems Dear systemd Maintainers, As reported in the follow-up to #1052116[1], udev's postinst uses update-rc.d's -f option which breaks the transition of /etc/init.d/udev to bin:initscripts and causes non-systemd systems to fail to boot. Michael, as discussed yesterday on #debian-systemd, I am very grateful for your quick commit of a fix[2]. This bug is to prevent unintended migration of the broken udev to trixie. With thanks and best wishes Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052116#17 [2] https://salsa.debian.org/systemd-team/systemd/-/commit/12e2c67612f958148f0a4ca165cfb9ca1ed9d3c3 -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1052116: initscripts: /etc/rcX.d symlinks not created
Kevin, On Wed, Sep 20, 2023 at 02:07:48AM +, Kevin Ruml wrote: >I know you sent subsequent messages about a fix, but since you asked me >to test this and it was easy enough for me to do it, I did. >Downgrading then upgrading again left the system without the symlinks. >Running "dpkg-reconfigure initscripts" did generate the symlinks. Thanks, that is really useful confirmation that we aren't missing something else. Much appreciated. Mark
Bug#1052116: initscripts: /etc/rcX.d symlinks not created
On Tue, Sep 19, 2023 at 08:36:05AM +0100, Mark Hindley wrote: > Yes. I think the real issue is the udev.postinst using update-rc.d -f remove > udev. Without the -f option, I think the symlinks would be left intact. The fix for this has been queued in src:systemd[1]. Mark [1] https://salsa.debian.org/systemd-team/systemd/-/commit/12e2c67612f958148f0a4ca165cfb9ca1ed9d3c3
Bug#1052116: initscripts: /etc/rcX.d symlinks not created
On Tue, Sep 19, 2023 at 09:33:29AM +0200, Lorenzo wrote: > One solution could be that udev does the cleanup only if initscripts > is not installed in the system; otherwise assume a take over from > initscripts package. > The removal bits in udev package could be guarded by something like > > If ! dpkg -s initscripts >/dev/null ; then > #remove udev 's sysv bits > fi Yes. I think the real issue is the udev.postinst using update-rc.d -f remove udev. Without the -f option, I think the symlinks would be left intact. Mark
Bug#1052116: initscripts: /etc/rcX.d symlinks not created
On Tue, Sep 19, 2023 at 07:29:45AM +0100, Mark Hindley wrote: > > Setting up initscripts (3.08-1) ... > > Setting up udev (254.3-1) ... > > The udev postinst, which removes the update-rc.d symlinks is run after the > initscripts postinst which has created them. Just so I can be sure that there isn't a bug in the initscripts postinst, having upgraded to initscripts 3.08-1, can you run dpkg-reconfigure initscripts and verify that the symlinks are recreated? Thanks Mark
Bug#1052116: initscripts: /etc/rcX.d symlinks not created
Kevin, Many thanks for reporting this. I think this is an ordering issue. On Mon, Sep 18, 2023 at 09:07:59PM -0500, Kevin Ruml wrote: [..] > Setting up libudev1:i386 (254.3-1) ... > Setting up sysv-rc (3.08-1) ... > Setting up initscripts (3.08-1) ... > Setting up udev (254.3-1) ... The udev postinst, which removes the update-rc.d symlinks is run after the initscripts postinst which has created them. Hmmm... Mark
Bug#1050561: libelogind-dev-doc: sd_listen_fds(3) manual damaged
Control: tags -1 upstream Control: forwarded -1 https://github.com/elogind/elogind/issues/263 On Sat, Aug 26, 2023 at 12:03:02PM +0200, наб wrote: > Package: libelogind-dev-doc > Version: 246.10-1debian1 > Severity: normal Thanks. Forwarded upstream. Mark
Bug#934463: initscripts: consider taking over hwclock policy machinery
Andreas, Thanks for your thoughts on this. On Thu, Aug 24, 2023 at 06:16:08PM +0200, Andreas Henriksson wrote: > Since initscripts will need (and has) Breaks/Replaces: util-linux-extra > the circular nature of util-linux-extra having the same makes me think > this is something which might be useful to think about a second time. > Additionally, util-linux-extra might not even be installed on users > system now that it's no longer pseudo-essential If we want to > prevent (sysvinit) users from partially upgrading util-linux-extra > and lack the hwclock machinery, then we likely also want to prevent > them from deinstalling util-linux-extra which would have the same > result. I don't think the hwclock machinery is universally required on non-systemd init systems: all of my systems are non-systemd and none have util-linux-extra installed but run one of the time-daemon providers. Bin:initscripts is installed on all non-systemd systems by being a dependency of sysvinit-core and runit-init and itself depending on sysv-rc | openrc. I see 2 scenarios we need to enforce with the dependencies:- 1) Avoid dpkg attempting installation of packages with conflicting files 2) Ensure users who might use the hwclock machinery (i.e. currently have util-linux-extra installed) continue to have it available I think 1) is covered by the Breaks/Replaces. 2) is addressed by apt's preference to upgrade rather than remove packages. Despite the circular nature of both util-linux-extra and initscripts having reciprocal breaks that you identify, it is the recommendation in the Package Transition Wiki[1]. I think we are dealing with scenario #9. With best wishes. Mark [1] https://wiki.debian.org/PackageTransition
Bug#1042082: Please take over udev SysV init script
Control: reassign -1 initscripts Michael, We have decided that initscripts from src:sysvinit is a better fit for /etc/init.d/udev. Therefore reassigning. I have prepared a branch[1]. The only outstanding item I am aware of is to add versioned Breaks/Replaces against the version of udev that no longer ships the file. In my testing of this transition, it became apparent that if udev uses either dpkg-maintscript-helper rm_conffile or dpkg remove-on-upgrade, user modifications to /etc/init.d/udev are not preserved. So, I would ask that you not do that until Forky so we can be sure that any changes to those files are correctly preserved. Can you see any other issues? Thanks and best wishes Mark [1] https://salsa.debian.org/debian/sysvinit/-/tree/wip/udev_initscript
Bug#1042082: Please take over udev SysV init script
Lorenzo, On Wed, Aug 23, 2023 at 01:46:35PM +0200, lorenzo wrote: > Subject: [PATCH 4/5] remove x mode from udev on non-linux archs > > initscripts postinst: remove x mode from udev script on non-linux > archs so that the script is skipped by update-rc.d > --- > debian/initscripts.postinst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst > index dd7c9715..202fc3fd 100755 > --- a/debian/initscripts.postinst > +++ b/debian/initscripts.postinst > @@ -26,6 +26,11 @@ INITSCRIPTS="mountkernfs.sh udev mount-configfs brightness > hostname.sh mountdevs > umountroot umountfs umountnfs.sh sendsigs killprocs single motd \ > bootlogs rc.local rmnologin" > > +if [ "$(uname -s)" != Linux ]; then > +# udev is linux-any but this package is arch:all > + chmod -x /etc/init.d/udev > +fi > + > for F in $INITSCRIPTS; do > if [ -x /etc/init.d/$F ]; then > update-rc.d $F defaults >/dev/null || exit $? > -- > 2.40.1 > This is the only substantive difference I can see between our trees. However, /etc/init.d/udev contains [ -x $DAEMON ] || exit 0 so on non-Linux archs it will do nothing. Is this postinst handling strictly necessary? I agree that bin:udev needs not to use rm_conffile/remove-on-upgrade on /etc/init.d/udev, otherwise user modifications will be lost. That would have to wait for Forky.
Bug#1042082: Please take over udev SysV init script
Lorenzo, On Wed, Aug 23, 2023 at 01:46:35PM +0200, lorenzo wrote: > I'm attaching git patches that can be 'git am' on top of the master > branch at > https://salsa.debian.org/debian/sysvinit/-/tree/master?ref_type=heads > > Since I'm on holiday and away from from my testing setup, I did no test > to ensure that this warks as intended, so consider it as experimental. > Also, the "breaks and replaces" patch need to be amended with the > version of systemd that removes the udev script, which is unknwnown to > me (I used the unreleased 254.1-3, which of course is wrong). > Anyway I think there need to be some work on udev's side to ensure that > the udev script is not removed when the initscripts package is > installed in the system. Thanks. I also have a pushed a tree[1] for review. I will compare and see if we have any substantive differences. Mark [1] https://salsa.debian.org/debian/sysvinit/-/tree/wip/udev_initscript
Bug#934463: initscripts: consider taking over hwclock policy machinery
Andreas and Chris, Thanks for your input. On Tue, Aug 22, 2023 at 12:55:41PM +0200, Andreas Henriksson wrote: > HEADS UP: One thought here is that the init script will still need the > actual hwclock binary. While util-linux-extra currently is > pseudo-essential I think zeha plans to make it a regular package at some > point in the future which probably mean you want initscripts to depend > on it (or make the scripts handle that hwclock binary is not available, > but that sounds less compelling to me). You might want to add the > dependency now so that it's not forgotten once util-linux-extra is no > longer pseudo-essential. Dependency added. > (I'd be happy if I could see the actual diff, but could not spot a > relevant branch on salsa/debian/sysvinit.) I have just pushed wip/hwclock_takeover. The diff is also attached. (I am aware that the initscripts packaging doesn't make use of many recent debhelper conveniences. However, I am reluctant to make changes to that at the same time as handling this sort of transition). > Feel free to push a branch to salsa.debian.org/debian/util-linux with > proposed changes if you do prepare them. I have pushed branch leepen/hwclock_initscripts_migration for review and comment. > > If util-linux-extra were to use it, my understanding is that rm_conffile > > only > > removes *unmodified* conffiles so user modifications should be preserved. Testing this has been contrary to my expectation so far: both rm_conffile and remove-on-upgrade only preserve user modifications to conffiles only to the extent that they are renamed with either .dpkg-bak or .dpkg-old appended. However, that doesn't facilitate those modifications being preserved in the new initscript-owned conffile. Therefore, I think any active removal of these conffiles as obsolete in util-linux-extra should wait until Forky+1, by which time we can be sure that initscripts will have inherited the conffiles. Are you OK with that? Or do either of you have a better solution? > PS. I'd be happy to discuss potential improvements that can be done, but > think the first step should only be to get the files moved over. One > step at a time. Just don't want to leave you with the impression that > I/we are just dumping all the burden on you for old sins. For example > the hwclock(5) manpage probably contains questionable information. Thanks. As you say, for the future... Best wishes Mark diff --git a/debian/control b/debian/control index e3b9c91c..fca27272 100644 --- a/debian/control +++ b/debian/control @@ -99,7 +99,10 @@ Multi-Arch: foreign Depends: sysvinit-utils (>= 3.05-1), sysv-rc | file-rc | openrc, + util-linux-extra, ${misc:Depends}, +Breaks: util-linux-extra (<< 2.39.2-1.1~) +Replaces: util-linux-extra (<< 2.39.2-1.1~) Recommends: e2fsprogs, psmisc, diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst index 32c0afb0..bf841c82 100755 --- a/debian/initscripts.postinst +++ b/debian/initscripts.postinst @@ -24,7 +24,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness hostname.sh mountdevsubfs. checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \ mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \ umountroot umountfs umountnfs.sh sendsigs killprocs single motd \ - bootlogs rc.local rmnologin" + bootlogs rc.local rmnologin hwclock.sh" for F in $INITSCRIPTS; do if [ -x /etc/init.d/$F ]; then diff --git a/debian/initscripts.postrm b/debian/initscripts.postrm index 5e232568..ac314bed 100755 --- a/debian/initscripts.postrm +++ b/debian/initscripts.postrm @@ -9,7 +9,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness hostname.sh mountdevsubfs. checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \ mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \ umountroot umountfs umountnfs.sh sendsigs killprocs single motd \ - bootlogs rc.local rmnologin" + bootlogs rc.local rmnologin hwclock.sh" case "$1" in purge) diff --git a/debian/src/initscripts/Makefile b/debian/src/initscripts/Makefile index b13eafa3..db50873c 100644 --- a/debian/src/initscripts/Makefile +++ b/debian/src/initscripts/Makefile @@ -34,6 +34,9 @@ install: $(INSTALL) -d $(DESTDIR)$(sbindir)/. $(INSTALL) sbin/fsck.nfs $(DESTDIR)$(sbindir)/fsck.nfs + $(INSTALL) -Dt $(DESTDIR)/usr/lib/udev/rules.d usr/lib/udev/rules.d/hwclock.rules + $(INSTALL) usr/lib/udev/hwclock-set $(DESTDIR)/usr/lib/udev/hwclock-set + $(INSTALL) -d $(DESTDIR)/usr/share/man/man8 $(INSTALL_DATA) man/fsck.nfs.8 \ $(DESTDIR)/usr/share/man/man8/fsck.nfs.8 diff --git a/debian/src/initscripts/etc/default/hwclock b/debian/src/initscripts/etc/default/hwclock new file mode 100644 index ..44b04312 --- /dev/null +++ b/debian/src/initscripts/etc/default/hwclock @@ -0,0 +1,2 @@ +# Settings for the hwclock init script. +# See hwclock(5) for supported settings. diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh
Bug#934463: initscripts: consider taking over hwclock policy machinery
Andreas, I have prepared the necessary updates to src:sysvinit to incorporate the hwclock machinery in initscripts. Specifically the files /etc/default/hwclock /etc/init.d/hwclock.sh /usr/share/man/man5/hwclock.5 /usr/lib/udev/hwclock-set /usr/lib/udev/rules.d/hwclock.rules Obviously we need to coordinate the transition and I will add Breaks/Replaces << the util-linux-extra version which drops the files. If util-linux-extra were to use it, my understanding is that rm_conffile only removes *unmodified* conffiles so user modifications should be preserved. But we might consider synchronised uploads to experimental to test and confirm. Best wishes Mark
Bug#1047054: sysvinit: Fails to build source after successful build
Control: tags -1 pending patch Lucas, Thanks for raising this. Fixed version is pending. Jesse, My patch for man/Makefile to fix the clean recipe is attached. You may want it, or something similar, upstream. Thanks. Mark >From 807614887ce310471b72032b4385eed9312acc23 Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Sat, 19 Aug 2023 20:09:52 +0100 Subject: [PATCH] man/Makefile: fix clean recipe (Closes: #1047054). --- man/Makefile | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/man/Makefile b/man/Makefile index 11062419..99475bd8 100644 --- a/man/Makefile +++ b/man/Makefile @@ -21,8 +21,7 @@ endif install: all clean distclean: - for man in $(MANPAGES) ; do \ - if [ -f "$$man.orig" ] ; then mv "$$man.orig" "$$man" ; fi \ - done - for lang in $(LANGUAGES) ; do rm -rf "$$lang" "$$lang.po" ; done - +ifdef PO4A + po4a $(PO4A_OPTS) --rm-translations po/po4a.cfg +endif + rm -f *.po sysvinit-man.pot -- 2.39.2
Bug#1042082: Please take over udev SysV init script
On Wed, Jul 26, 2023 at 08:22:15PM +0100, Matthew Vernon wrote: > Hi, > > On 26/07/2023 19:43, lorenzo wrote: > > > may I suggest to add this script to initscripts package(sysvinit:src) > > instead of o-s-s? > > A system without udev is not very common after all and the vast > > majority of scripts strictly needed to boot and shutdown the system > > are shipped there. > > Wearing my o-s-s maintainer hat, I have no problem with this suggest - > what do the sysvinit maintainers think? I can see some logic to this approach. I am away until next week, but can look at it then. Mark
Bug#1039907: Aw: Bug#1039907 closed by Debian FTP Masters (reply to Mark Hindley ) (Bug#1039907: fixed in apt-cacher 1.7.30)
On Thu, Jul 06, 2023 at 09:26:49AM +0200, Chris Nospam wrote: > Many thanks @Mark for the quick and effective reaction! The new version works > as desired. Thanks for the confirmation. I will do an update for -proposed-stable, hopefully this week. Mark
Bug#1039907: apt-cacher-cleanup.pl clears/removes all cached packages on trixie
Gregor, Thanks for your quick reply. On Sun, Jul 02, 2023 at 03:37:29PM +0200, gregor herrmann wrote: > Random notes: > - IO::Uncompress::AnyUncompress is in both perl-modules-5.36 and > libio-compress-perl. The system I reproduced on only has perl-modules-5.36 installed. > - From a quick look at libio-compress-perl I don't see any recent > relevant changes. > - I note that for de/compressing xz files libio-compress-lzma-perl is > needed, Can you point me to the documentation for that, please? I have looked again and still can't find it! > which is only Suggested by libio-compress-perl (and > Recommended by apt-cacher) Installing libio-compress-lzma-perl pulls in libio-compress-perl and normal apt-cacher decompression is restored. I suppose the apt-cacher Recommends will need to become a Depends. Chris, there maybe another issue with underscore encoding in filenames which I am looking at. Mark
Bug#1039907: apt-cacher-cleanup.pl clears/removes all cached packages on trixie
Control: tags -1 = confirmed [cc perl maintainer] Chris, Thanks. I have managed to reproduce this. It appears to be a regression in the IO::Uncompress::AnyUncompress module which doesn't seem to handle xz any more. At the moment I am unsure why. My minimal script to reproduce is attached. My testing shows that text and gzipped files work as expected, but not xz. Nico, Are you aware of this issue? I can't find any other reports. Am I missing something? Thanks to you both Mark #! /usr/bin/perl use warnings; use strict; use IO::Uncompress::AnyUncompress; die "No file specified\n" unless @ARGV; my $raw = IO::Uncompress::AnyUncompress->new($ARGV[0]) or die $!; while (<$raw>) { print substr($_, 0, 20), "\n"; exit(); }
Bug#932047: lightdm: greeter session support for elogind
Yves-Alexis, On Sat, Oct 22, 2022 at 01:59:33PM +0200, Yves-Alexis Perez wrote: > But if it seems that there is no breakage (and hopefully no bad side effects > we don't see yet) I guess we'll be able to update the pam configuration to > uses includes as well at some point. A gentle reminder this is still unresolved. Early in the Trixie cycle seems a good time to implement it and allow maximum time for testing and resolution of any outstanding issues. Many thanks. Mark
Bug#1039907: apt-cacher-cleanup.pl clears/removes all cached packages on trixie
Control: tags -1 moreinfo On Thu, Jun 29, 2023 at 01:35:28PM +0200, Chris Nospam wrote: > Package: apt-cacher > Version: 1.7.29 > > As far as I can see, calling /usr/share/apt-cacher/apt-cacher-cleanup.pl > (e.g. after apt-get dist-upgrade which stores some packages to the cache) > under debian testing/trixie seems to remove ALL package files in the cache > /var/cache/apt-cacher/packages/ftp.xx.debian.org_debian, instead of only > removing superseeded packages which are not in the index any more. There have not been any recent changes, so unless the underlying perl behaviour has changed, I don't have an immediate explanation. > > I did not change my config (= nearly default), which used to operate on > bookworm. Nevertheless, after bookworm got stable (and I stayed on testing), I > manually cleared the cache by replacing /var/cache/apt-cacher with a vanilla > version like it once was created by apt-get install apt-cacher . Can you clarify exactly what you did here? Was that before or after the dist-upgrade? Mark
Bug#1039301: openrc: ships sysv-init script without systemd unit
Control: tags -1 invalid Luca, On Sun, Jun 25, 2023 at 11:26:01PM +0100, bl...@debian.org wrote: > Package: openrc > Severity: important > User: bl...@debian.org > Usertags: missing-systemd-service I am afraid I can see no possible use case where anybody would run openrc under systemd. Do you have one? Mark
Bug#1038789: Enable capabilities feature
[Cc dpkg maintainers] Dennis, Many thanks for this suggestion. I appreciate the advantages of capabilities support. However, the Debian packaging of openrc specifically excludes the openrc version of start-stop-daemon[1] meaning systems continue to use src:dpkg's start-stop-daemon. As far as I can tell that decision was taken because the 2 versions have slightly different options and syntax. It is difficult to be sure that using the version from openrc would not cause problems with some initscripts. Openrc also has optional capabilities support in supervise-daemon which might be an advantage to users, but isn't used by default in Debian. It might be worth exploring adding capabilities support to src:dpkg start-stop-daemon. Maybe the src:openrc code would be a starting point. I haven't looked how much the two codebases have diverged. Guillem, What do you think? Best wishes Mark [1] https://salsa.debian.org/debian/openrc/-/blob/debian/debian/rules#L21
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Daniel, Many thanks. On Sun, Jun 18, 2023 at 07:48:03AM +0200, Daniel Baumann wrote: > Assuming there are no problems of having mdadm initscripts in > orphan-sysvinit-scripts, I think this is the best way forward. I would still disagree with that. However, even if that were the path taken, it doesn't restore the mdadm cron snippets. This isn't just about the initscripts, it is support for non-systemd systems in a more general sense. Best wishes Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Michael, On Sat, Jun 17, 2023 at 07:17:40PM +0300, Michael Tokarev wrote: > You're still not getting the point. Which is the lack of real infrastructure > within other init systems, which needs real work. Which, apparently, > neither you nor other complainers are willing to do. I am not complaining. I am asking gently for the reinstatement of the recently removed non-systemd initscripts. Together with an offer to provide continued and on-going support for them. However imperfect those scripts may have been, they worked, were used and were useful and would continue to be so. With best wishes Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Michael, On Sat, Jun 17, 2023 at 08:07:52AM +0300, Michael Tokarev wrote: > I wonder do we want no mdadm in debian at all or working mdadm with systemd? > From the two alternatives I definitely prefer the working one.. That isn't the choice on offer. The choice is mdadm in Debian which is only usable with systemd or mdadm in Debian which is usable with systemd, openrc, runit and sysvinit. Best wishes Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Daniel, Many thanks for your reply. On Tue, Jun 13, 2023 at 03:32:23PM +0200, Daniel Baumann wrote: > > It would be a great help to users of non-systemd inits if you could restore > > them. > > thanks you for your report. > > Personally I'm using systemd, but in general I fully agree that as long > as it's no "burden" to keep the sysvinit scripts around, I'd keep them. > > For mdadm specifically, using sysvinit scripts has been the source of a > bunch of bugs as some things are not properly supportable when it comes > to events/race-condition handling when detecting raid devices in early boot. Could you be a little more specific as to what insurmountable issues still persist? > Most other distributions as well as upstream don't support sysvinit > anymore in mdadm. I have spent some time looking through the source and upstream documentation. I can't find any mention that upstream supports only systemd. Can you point me to it? > I can see at least three disadvantages for keeping > sysvinit scripts in mdadm around: > > * I would need to support them in Debian for a type of system I > don't use anywhere anymore since several Debian releases. > Personally, I'd rather spend time on, to me, more appealing things. > > * Keeping sysvinit support for mdadm in Debian de-facto makes me > upstream for these scripts, which doesn't seem right given that > I don't use it myself. I don't think I was asking you to do either of these. I was merely asking for reinstatement of the existing scripts (which work) and accept and merge reasonable and tested patches in the future. That seems a pretty small burden. > * Keeping sysvinit support would "falsly advertise" that it's actually > maintained and cared for, which isn't the case and I'd expect that > a lot of bugs don't get spottet in time for a next Debian release. I am sure people who use mdadm with non-systemd init *do* care about it and will be happy to identify and correct any issues. > A solution could be for those that like to keep using sysvinit, to > submit the scripts for inclusion in the orphan-sysvinit-scripts package > and maintain it there. Notwithstanding Matthew's great work in orphan-sysvinit-scripts, this is a suboptimal solution. * The approach has inherent problems that are well documented[1] * If there *are* issues with mdadm running without systemd as PID1, this approach wouldn't solve or avoid them I hope you will reconsider. With thanks and best wishes Mark [1] https://salsa.debian.org/matthew/orphan-sysvinit-scripts/-/blob/master/README.org
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Sean, On Tue, Jun 13, 2023 at 05:15:15PM +0100, Sean Whitton wrote: > > In principle and just looking at the dependencies this seems a viable > > solution. It is very similar to the way we handle the logind and > > default-logind virtual packages. > > Thank you for reviewing. Do you have a rough idea of how long it would > be until you could confirm that this is viable, and implement it in sid? There is a new upstream version of elogind[1] that is already packaged in Devuan[2] although that uncovered up an upstream issue that I am waiting to be resolved[3]. So, maybe by the end of this month? However, that is only considering whether the packaging and dependencies can be made to work (like Simon McVittie, I think they probably can). I remain much less convinced that there is a consensus for requiring packages to use tmpfiles.d(5) for /var, /tmp and maybe /etc. The recent thread on debian-devel demonstrated a range of opinion. Thorsten and Bill have just raised valid points about chroots. So, whilst I am happy to test the dependency changes in elogind, enshrining this as a 'should' in the Policy now seems, at least, premature. Reading the proposed text as somebody who is particularly interested in non-systemd systems, I am struck by the inconsistency between Init systems other than ``systemd`` should allow providing the same functionality as appropriate for each system, for example managing the directories from the init script shipped by the package. and the fact that we no longer expect packages to include init scripts alongside their systemd units and even accept their removal, even if other interested people offer to maintain them and provide tested patches. With best wishes Mark [1] https://qa.debian.org/cgi-bin/watch?pkg=elogind [2] https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package=elogind=252.9-1~rc1 [3] https://github.com/elogind/elogind/issues/258
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Simon, Thanks for your care and insight with this and apologies for the delay in replying (mails to elog...@packages.debian.org have been held up on a mailserver). On Tue, Jun 06, 2023 at 11:58:07AM +0100, Simon McVittie wrote: > Exactly. My hope is that if we had: > > Package: systemd > Architecture: linux-any > Provides: default-systemd-tmpfiles, systemd-tmpfiles > Conflicts: systemd-tmpfiles > Replaces: systemd-tmpfiles > > Package: systemd-standalone-tmpfiles > Architecture: linux-any > Provides: systemd-tmpfiles > Conflicts: systemd-tmpfiles > Replaces: systemd-tmpfiles > > Package: elogind > Depends: systemd-standalone-tmpfiles# or Recommends? In principle and just looking at the dependencies this seems a viable solution. It is very similar to the way we handle the logind and default-logind virtual packages. Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Source: mdadm Version: 4.2+20230227-1 Severity: normal Dear Daniel, SysV initscripts and cron jobs have recently been removed from mdadm. It would be a great help to users of non-systemd inits if you could restore them. Service files and initscripts can happily coexist and systemd will use the available service files in preference. Installing recent mdadm on a non-systemd system can render the system unbootable. Thanks for you consideration. Mark -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1034833: sysv init script missing in tomcat10 package
Control: affects -1 tomcat10 Emmanuel, Thanks for this. On Wed, Apr 26, 2023 at 08:54:14AM +0200, Emmanuel Bourg wrote: > Thank you for offering your help. The sysvinit script for Tomcat > is now maintained in the orphan-sysvinit-scripts source package. Whilst this is the current situation for tomcat9 (although not without some outstanding issues[1]), I would like to encourage you to reconsider this for tomcat10. Maintaining initscripts in their parent package remains the best option. Notwithstanding Matthew's considerable efforts, putting them in orphan-sysvinit-scripts has a number of difficulties that are outlined in the orphan-sysvinit-scripts source README[2]. Including the supplied script with Andreas' offer of ongoing testing and support within tomcat10 would - provide the smoothest experience users of all init systems - be of no detriment to users of the default init system - place no additional burden on you as maintainer Thanks again for your further consideration. Mark [1] https://bugs.debian.org/925473 [2] https://salsa.debian.org/matthew/orphan-sysvinit-scripts/-/blob/master/README.org
Bug#1034069: /var/log/boot~ is never created
Ingo, On Thu, Apr 13, 2023 at 06:04:04PM +0200, Ingo Brückl wrote: > On Wed, 12 Apr 2023 09:58:27 +0100 Mark Hindley wrote: > > > + savelog -q -p -n -c 5 /var/log/boot > > What about: > > [ -e /etc/logrotate.d/boot ] || savelog -q -p -n -c 5 /var/log/boot I am not convinced that logrotate is a better tool here. It is designed for the routine rotation of logs. /var/log/boot is written at the end of the boot process and then is unchanged until the next boot. Savelog makes more sense to me for that use. Or am I missing your point? Thanks Mark
Bug#1034069: /var/log/boot~ is never created
Control: tags -1 patch Bjarni, On Mon, Apr 10, 2023 at 08:38:34PM +0100, Mark Hindley wrote: > Yes, I think this code might be cruft from before the change to bootlog using > /run/bootlog. > > We may still need to implement savelog rotation for /run/bootlog -> > /var/log/boot though. I will test that. I have confirmed that boot logging works with the correct initscripts installed. The code you quoted is obsolete handling of /var/log/boot~ which predates the switch to /run/bootlog. The only thing that appears missing is rotation of /var/log/boot*. I proposed the following patch to address these issues. Mark commit 2443d3ad1c977a2e7948ba1884b8a099411a1b95 Author: Mark Hindley Date: Wed Apr 12 09:48:11 2023 +0100 Remove obsolete handling of /var/log/boot~ and restore rotation of /var/log/boot. diff --git a/debian/src/bootlogd/etc/init.d/bootlogd b/debian/src/bootlogd/etc/init.d/bootlogd index 5e810e90..0e8a734b 100644 --- a/debian/src/bootlogd/etc/init.d/bootlogd +++ b/debian/src/bootlogd/etc/init.d/bootlogd @@ -68,22 +68,10 @@ case "$ACTION" in [ "$VERBOSE" != no ] && log_end_msg $ES if [ -r "$TMPLOG" ] then + savelog -q -p -n -c 5 /var/log/boot cat "$TMPLOG" >> /var/log/boot rm -f "$TMPLOG" fi - if [ -f /var/log/boot ] && [ -f /var/log/boot~ ] - then - [ "$VERBOSE" = no ] || log_action_begin_msg "Moving boot log file" - # bootlogd writes to boot, making backup at boot~ - cd /var/log && { - chgrp adm boot || : - savelog -q -p -c 5 boot && - mv boot.0 boot && - mv boot~ boot.0 - } - ES=$? - [ "$VERBOSE" = no ] || log_action_end_msg $ES - fi ;; restart|force-reload) "$0" stop
Bug#1034069: /var/log/boot~ is never created
Bjarni, Thanks for this On Fri, Apr 07, 2023 at 09:52:17PM +, Bjarni Ingi Gislason wrote: > Package: bootlogd > Version: 3.06-2 > Severity: important > > Dear Maintainer, > >* What led up to the situation? > > /var/log/boot* was not updated after 28th September 2021. > > File is used in /etc/init.d/bootlogd. > > The conditional code > > if [ -f /var/log/boot ] && [ -f /var/log/boot~ ] > then > [ "$VERBOSE" = no ] || log_action_begin_msg "Moving boot log > file" > # bootlogd writes to boot, making backup at boot~ > cd /var/log && { > chgrp adm boot || : > savelog -q -p -c 5 boot && > mv boot.0 boot && > mv boot~ boot.0 > } > ES=$? > [ "$VERBOSE" = no ] || log_action_end_msg $ES > fi > > is therefore never used. Yes, I think this code might be cruft from before the change to bootlog using /run/bootlog. We may still need to implement savelog rotation for /run/bootlog -> /var/log/boot though. I will test that. > -- System Information: > Debian Release: 12.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.20-1 (SMP w/2 CPU threads; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), > LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages bootlogd depends on: > ii libc6 2.36-8 > ii sysvinit-utils 3.06-2 > > bootlogd recommends no packages. > > bootlogd suggests no packages. > > -- Configuration Files: > /etc/init.d/bootlogd changed [not included] > /etc/init.d/stop-bootlogd [Errno 2] No such file or directory: > '/etc/init.d/stop-bootlogd' > /etc/init.d/stop-bootlogd-single [Errno 2] No such file or directory: > '/etc/init.d/stop-bootlogd-single' However, AFAICS these scripts are still required. Can you reinstate them and you should have boot logging to /var/log/boot at least. Mark
Bug#1033956: Support for zcfan
Control: affects -1 zcfan Klaus, On Tue, Apr 04, 2023 at 11:27:58PM +0100, Klaus Ethgen wrote: > Package: orphan-sysvinit-scripts > Version: 0.14 > Severity: normal > > I was thinking to set this as wishlist but as the main functionality is > to support broken packages I set the severity to normal. > > The zcfan daemon comes with only a systemd startup file which makes it > unusable with sysv init. Thanks for this. It appears that zcfan has never had an initscript. I think it would be best first to provide your initscript to the zcfan maintainer and ask for it to be included in the package. Mark
Bug#1033876: unblock: sysvinit/3.06-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sysvi...@packages.debian.org Control: affects -1 + src:sysvinit Release Team, Please consider unblocking package sysvinit The version in sid fixes a regression recently reported in #1033311 (pidof not matching pathnames which are symlinks) and also has a new debconf translation. [ Reason ] - cherry pick upstream patches to fix a regression caused by incorrect memory initialisation (#1033311) - New debconf Romanian translation (#1033723) [ Impact ] Regression in #1033311 would not be fixed and Romanian debconf translations would not be available. [ Tests ] Reporter of #1033311 has tested the fix and confirmed resolution[1]. [ Risks ] Although sysvinit-utils is Essential, I consider the risk is low and the benefit of fixing #1033311 is significant. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiffs against the package in testing [ Other info ] The fix for #1033311 was uploaded in 3.06-3 and has already been in unstable for 5 days. unblock sysvinit/3.06-4 Thanks Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033311#149 [The following lists of changes regard files as different if they have different names, permissions or owners.] Files in second .changes but not in first - -rw-r--r-- root/root /usr/lib/debug/.build-id/7d/b2c2611f9e478474cf82dfeab6aa760f65a8be.debug Files in first .changes but not in second - -rw-r--r-- root/root /usr/lib/debug/.build-id/f7/c7a26070fae0ea19e066675c08fa7e3bf05585.debug Control files of package bootlogd: lines which differ (wdiff format) Version: [-3.06-2-] {+3.06-4+} Control files of package bootlogd-dbgsym: lines which differ (wdiff format) --- Depends: bootlogd (= [-3.06-2)-] {+3.06-4)+} Version: [-3.06-2-] {+3.06-4+} Control files of package initscripts: lines which differ (wdiff format) --- Version: [-3.06-2-] {+3.06-4+} Control files of package sysv-rc: lines which differ (wdiff format) --- Version: [-3.06-2-] {+3.06-4+} Control files of package sysvinit-core: lines which differ (wdiff format) - Installed-Size: [-342-] {+343+} Version: [-3.06-2-] {+3.06-4+} Control files of package sysvinit-core-dbgsym: lines which differ (wdiff format) Depends: sysvinit-core (= [-3.06-2)-] {+3.06-4)+} Version: [-3.06-2-] {+3.06-4+} Control files of package sysvinit-utils: lines which differ (wdiff format) -- Version: [-3.06-2-] {+3.06-4+} Control files of package sysvinit-utils-dbgsym: lines which differ (wdiff format) - Build-Ids: {+7db2c2611f9e478474cf82dfeab6aa760f65a8be+} f7694b57b3d2e7921327b4d215648310a9c63829 [-f7c7a26070fae0ea19e066675c08fa7e3bf05585-] Depends: sysvinit-utils (= [-3.06-2)-] {+3.06-4)+} Installed-Size: [-52-] {+53+} Version: [-3.06-2-] {+3.06-4+} diff -Nru sysvinit-3.06/debian/changelog sysvinit-3.06/debian/changelog --- sysvinit-3.06/debian/changelog 2022-12-18 17:00:20.0 + +++ sysvinit-3.06/debian/changelog 2023-04-03 07:25:22.0 +0100 @@ -1,3 +1,19 @@ +sysvinit (3.06-4) unstable; urgency=medium + + * Add Romanian debconf translations with thanks to Remus-Gabriel Chelu +. (Closes: #1033723) + + -- Mark Hindley Mon, 03 Apr 2023 07:25:22 +0100 + +sysvinit (3.06-3) unstable; urgency=medium + + * Cherry pick hunk from upstream to fix regression in pidof not matching +symlinks. (Closes: #1033311) + * Cherry pick upstream patch to fix memory initialisation in pidof. +(Closes: #1033311) + + -- Mark Hindley Thu, 30 Mar 2023 13:59:53 +0100 + sysvinit (3.06-2) unstable; urgency=medium * Upload to unstable. diff -Nru sysvinit-3.06/debian/patches/0001-Fix-pidof-not-following-symlinks-regression.patch sysvinit-3.06/debian/patches/0001-Fix-pidof-not-following-symlinks-regression.patch --- sysvinit-3.06/debian/patches/0001-Fix-pidof-not-following-symlinks-regression.patch 1970-01-01 01:00:00.0 +0100 +++ sysvinit-3.06/debian/patches/0001-Fix-pidof-not-following-symlinks-regression.patch 2023-04-03 07:25:22.0 +0100 @@ -0,0 +1,27 @@ +From 93da64d13380b29fd330608493615f8877525494 Mon Sep 17 00:00:00 2001 +From: Jesse +Date: Wed, 29 Mar 2023 10:34:45 -0300 +Subject: [PATCH] Accepted patch from Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Jesse, With 93da64d13380b29fd330608493615f8877525494, I am not sure the change you have upstream in b70b2776eda9237e987b6d9e1185eb626eb75e2f is required. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Control: tags -1 pending On Thu, Mar 30, 2023 at 08:19:57AM +0200, Markus Fischer wrote: > Nice find! And yes, I can confirm that it works for me too. Would be great > to see these fixes make it into bookworm. Thanks, I plan to upload this later today. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
This single hunk on top of 3.06-2 fixes pidof following multiple symlinks for me when invoked as pidof $(which vi) Markus, can you confirm that works for you? Since it is a regression since bullseye, it seems a suitable targeted fix to attempt for bookworm. Thanks to everybody. Mark >From 93da64d13380b29fd330608493615f8877525494 Mon Sep 17 00:00:00 2001 From: Jesse Date: Wed, 29 Mar 2023 10:34:45 -0300 Subject: [PATCH] Accepted patch from Mark Hindle which avoids clearing realpath information in pidof when trying to find matching executables. --- src/killall5.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/killall5.c b/src/killall5.c index 9ab0782a..6f7528ad 100644 --- a/src/killall5.c +++ b/src/killall5.c @@ -740,8 +740,8 @@ PIDQ_HEAD *pidof(char *prog) return NULL; /* Try to stat the executable. */ + memset(real_path, 0, sizeof(real_path)); if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) { - memset(_path[0], 0, sizeof(real_path)); dostat++; } -- 2.39.2
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
On Wed, Mar 29, 2023 at 08:37:00AM -0300, Jesse Smith wrote: > > Given subsequent discussion, could we instead use canonicalize_file_name > > or realpath here instead? That would give us the "correct" path without > > pidof having to think hard about symlinks et al. > > I'm open to the possibility. I'm curious as to what you see as the pros > vs cons of changing the approach used by pidof? Markus' orginal report suggested this was a regression since Bullseye sysvinit-utils | 2.96-7+deb11u1 | stable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x rather than a proposal to change behaviour. I think I have found the offending commit: 0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which wipes the canonical resolved path. I suggest this fix as a starting point. Mark >From 346cc4a8a91f908c8a57a16fb041c44809517183 Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Wed, 29 Mar 2023 13:57:24 +0100 Subject: [PATCH] Fix following of executable symlinks. Fixes regression introduced in 0b695c7e0b1cac60ed77c56f224e296f023b652e --- src/killall5.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/killall5.c b/src/killall5.c index b0728fab..787c4226 100644 --- a/src/killall5.c +++ b/src/killall5.c @@ -739,10 +739,8 @@ PIDQ_HEAD *pidof(char *prog) return NULL; /* Try to stat the executable. */ - if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) { - memset(_path[0], 0, sizeof(real_path)); + if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) dostat++; - } /* Get basename of program. */ if ((s = strrchr(prog, '/')) == NULL) -- 2.39.2
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote: > > $ ls -l $(which vi) > > lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> > > /etc/alternatives/vi > > $ ls -l /etc/alternatives/vi > > lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> > > /usr/bin/vim.tiny > > $ ls -l /usr/bin/vim.tiny > > -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny > > > Okay, yes, this makes sense. The symbolic links are making multiple > jumps so it won't work. This is expected behaviour because there is no > executable running called /usr/bin/vi or /etc/alternatives/vi. Running > "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to > /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't > follow aliases or symbolic links with multiple hops and different names. As Thorsten pointed out, multiple layers of symlinks is used in several places in Debian, not least the alternatives system. Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical executable path? Alternatively, if you really want to keep the behaviour change then pidof.8 needs updating to reflect the new behaviour. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Control: tags -1 upstream Jesse, Thanks for your quick work on this. On Wed, Mar 22, 2023 at 12:40:43PM -0300, Jesse Smith wrote: > This has been fixed upstream for the upcoming sysvinit 3.07. Would be > great to get some people testing it before we do an official reelase of > the 3.07 branch. > > The updated pidof will now return an PID matches for a corresponding > executable or symbolic link. In other words, if /tmp/sleep is a symbolic > link to /usr/bin/sleep, then it doesn't matter which path name we use, > pidof will recognize both names go to the same real program and print > its PID. I have just done a local build of 3.06 with a cherry pick of just this hunk of b70b2776 diff --git a/src/killall5.c b/src/killall5.c index 992ce3e1..75750d32 100644 --- a/src/killall5.c +++ b/src/killall5.c @@ -763,6 +763,11 @@ PIDQ_HEAD *pidof(char *prog) add_pid_to_q(q, p); foundone++; } +else if ( (p->argv0) && (! strcmp(p->argv0, prog) ) ) +{ +add_pid_to_q(q, p); +foundone++; +} } } -- 2.39.2 The patched version still fails to find a running vi process when run as pidof $(which vi) Is that because there are 2 layers of symlinks? /usr/bin/vi -> /etc/alternatives/vi -> /usr/bin/vim.basic Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Markus, Thanks for this. On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: > Package: sysvinit-utils > Version: 3.06-2 > Severity: normal > X-Debbugs-Cc: none > > Dear Maintainer, > > Passing the full path of a binary to the pidof command does not always > return a pid although the process is running and the man page of the > pidof command explicitly notes that it can be used that way. > > This might be related to the fact that all programs with which I tested > this and which show this unexpected behaviour were symlinks (i.e., > "which " returned a symlink). Yes, I just tried with vim.basic which is not a symlink on my system and both pidof vim.basic pidof $(which vim.basic) work as expected. > However, on Debian Bullseye the > behaviour is as I expected it. So this appears to be a change in behaviour. I suspect this is an inadvertent side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. Jesse, or was it intentional? Thanks Mark
Bug#1032379: bug#746: Killed when starting modale dialog like pinentry
On Wed, Mar 08, 2023 at 11:26:37AM +0100, Klaus Ethgen wrote: > > Maybe you can add this information to #1032379 and reassign? > > I can prove it. If I revert the last update of libx11-6, libx11-data and > libx11-xcb1, everything works correct again. Good work! Thanks. Mark
Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
Simon, Thanks. On Mon, Mar 06, 2023 at 03:25:18PM +, Simon McVittie wrote: > What I absolutely don't want is to make the change, and then 2 years > later get hate mail from someone telling me that I've broken their > system by making dbus-launch prevent /home from being unmounted and > "why can't you just" add an option to use daemon(3). I think that is a very good point. KDE is the only area where I have heard of this causing problems and I am not aware of any other reports that seem to have the same underlying cause. I am not convinced there *is* a consensus for change and the risk of changing the default for all users of legacy DBus activation seems high. Martin, I still think this is for KDE to address if it is important to them. I don't think I would push to change the behaviour of DBus in either Debian or Devuan at the moment. Best wishes Mark
Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
Control: forwarded -1 https://bugs.debian.org/1032368 Martin, Thanks for this. On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote: > Package: dbus-x11 > Version: 1.14.6-1devuan1 > Severity: normal > X-Debbugs-Cc: mar...@lichtvoll.de > > Dear Maintainer, > > I also reported this to Debian as Simon McVittie's is, of course, correct that src:dbus being forked in Devuan means this should be dealt with in Devuan. Notwithstanding that, I am very grateful for his thorough, considered and illuminating reply. The same behaviour is evident in a non-systemd Debian installation. Like Simon, I have no experience of KDE or krunner. I also agree that legacy DBus activation appears to be working here as intended and documented, with no guarantee on the cwd given. My gut reaction is that this issue is should really be resolved elsewhere. If it is crucial that krunner uses a particular working directory, then it needs to chdir() explicitly itself. I also quite understand his concern that changing the behaviour of DBus may have unintended consequences and I am certain that changing the behaviour of DBus during the freeze will not happen. I suppose early in the next cycle is possible. Simon, might the implications of that be reviewed again upstream? I found an upstream issue with patch to implement such behaviour that has not been merged[1]. Thanks Mark [1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214
Bug#1028664: colord: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test --timeout-multiplier 3 returned exit code 1
Control: reassign -1 liblcms2-2 2.14-1 Control: affects -1 colord I hit this FTBFS today. The gdb backtrace of the failing test is Thread 1 "colord-test-pri" received signal SIGSEGV, Segmentation fault. 0x77bd359a in cmsMLUtranslationsCodes () from /usr/lib/x86_64-linux-gnu/liblcms2.so.2 (gdb) bt #0 0x77bd359a in cmsMLUtranslationsCodes () at /usr/lib/x86_64-linux-gnu/liblcms2.so.2 #1 0x77f9c598 in cd_icc_to_string (icc=icc@entry=0x5559e2c0) at ../lib/colord/cd-icc.c:435 #2 0x55566c4e in colord_icc_func () at ../lib/colord/cd-test-private.c:1529 #3 0x77c8764e in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x77c873b5 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x77c87b52 in g_test_run_suite () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x77c87bbd in g_test_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0xb428 in main (argc=, argv=) at ../lib/colord/cd-test-private.c:2400 (gdb) I suppose this has been caused by the upload of version 2.14-1 of liblcms2-2, but I don't immediately see the change there that has caused it. Reassigning. Mark
Bug#1028555: apt-cacher: hardcodes list of supported architectures
Antonio, Thanks for this. On Thu, Jan 12, 2023 at 02:03:59PM -0300, Antonio Terceiro wrote: > Package: apt-cacher > Version: 1.7.28.1 > Severity: normal > Tags: patch > > Dear Maintainer, > > I was creating a cross build environment for riscv64, and my downloads > failed because apt-cacher did not recognize it. I then discovered that > apt-cacher has a hardcoded list of supported architectures. > > The attached patch reads the list of most common supported architectures > from dpkg directly, so that you don't need to add architectures by hand > every time one comes around. Yes, I have tried this approach in the past but rejected it. My concern was that it includes many theoretically possible, but practically not available architectures. Maybe that is overly cautious. Mark
Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs
On Mon, Jan 09, 2023 at 05:44:44PM +0100, Thorsten Glaser wrote: > On Mon, 9 Jan 2023, Mark Hindley wrote: > > >Yes, although I think the default fstab has pass=1 for root. > > Nope. The default fstab is precisely this: > > >> # UNCONFIGURED FSTAB FOR BASE SYSTEM Yes, That is the debootstrap one. However on a new installation, partconf then fills in the entries for the newly partitioned system[1] Mark [1] https://sources.debian.org/src/partconf/1.52/mkfstab.c/#L300
Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs
Thorsten, Thanks for this. On Mon, Jan 09, 2023 at 02:55:59PM +0100, Thorsten Glaser wrote: > On Mon, 9 Jan 2023, Mark Hindley wrote: > > >> fsck is util-linux, not e2fsprogs. > > > >Yes, but fsck.ext4 is e2fsprogs and that is what is missing in #1028181. > > But that’s ⓐ the user’s problem and ⓑ not necessarily an error > as there exist filesystems for which no fsck binary exists. > > (If the user has set pass to ≠0 in fstab(5) it’s their own fault > of course.) Yes, although I think the default fstab has pass=1 for root. In #1028181, Holger says > Nowadays, checking ext4 filesystems is optional and systemd skips doing it in > the absence of e2fsprogs. If that is true (and I have no particular reason to doubt him) maybe the default fstab should be changed now the default fs is ext4. But it doesn't look like something to insert special handling for in initscripts. Mark
Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs
On Mon, Jan 09, 2023 at 12:57:53AM +0100, Thorsten Glaser wrote: > On Mon, 9 Jan 2023, Lorenzo Puliti wrote: > > >This package "only" recommands e2fsprogs, so I think it should just > > fsck is util-linux, not e2fsprogs. Yes, but fsck.ext4 is e2fsprogs and that is what is missing in #1028181. A clean way of handling missing filesystem-specific fsck isn't immediately apparent to me. fsck doesn't distinguish a missing filesystem-specific checker from other operational errors. Mark
Bug#1027945: sysvinit: [INTL:pt] Portuguese translation of MANPAGE
Control: tags -1 upstream Américo, On Wed, Jan 04, 2023 at 10:16:31PM +, Américo Monteiro wrote: > Package: sysvinit > Version: 3.04-1 > Tags: l10n, patch- > Severity: wishlist > > Updated Portuguese translation for sysvinit's manpage > Translator: Américo Monteiro > Feel free to use it. > > This translation was already send by me in bug 1019168 > that was closed but my work was not added to the package > Please include my translation Thanks for pointing this out and please accept my apologies. It was included upstream, but then seems to have got lost again prior to the current release. Jesse, I think it was added as man/pt.po and then removed again in 2354f1f73566544741a6a2594411a070e0898bfb. Could you add it back as man/po/pt.po again upstream? Thanks Mark
Bug#1025131: apt-cacher-cleanup does not work
Control: tags -1 pending Robert, Many thanks for correcting my typo and testing. Uploading later today. Mark
Bug#1025131: apt-cacher-cleanup does not work
Control: tags -1 patch Robert, Many thanks for pointing this out. Does the attached patch help? Thanks for testing. Mark >From cc36b2f690d694ad0cfe1b1c0ca5df7ead3e57ca Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Wed, 30 Nov 2022 11:30:21 + Subject: [PATCH] Add encoded underscores to *_files_regexp. Test fix for #1025131. --- lib/apt-cacher.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/apt-cacher.pl b/lib/apt-cacher.pl index 712d0bc..dad985a 100755 --- a/lib/apt-cacher.pl +++ b/lib/apt-cacher.pl @@ -132,7 +132,7 @@ sub read_config { qw(vmlinuz linux initrd\.gz - (?:%VALID_PACKAGE_NAME%_%VALID_VERSION%[_\.])?changelog + (?:%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%[_\.])?changelog NEWS\.Debian %VALID_UBUNTU_RELEASE_NAMES%\.tar\.gz(?:\.gpg)? (?:by-hash/(?i:MD5SUM/[0-9a-f]{32}|SHA1/[0-9a-f]{40}|SHA256/[0-9a-f]{64})) @@ -141,7 +141,7 @@ sub read_config { ) ) . ')$', package_files_regexp => '(?:' . join('|', - qw((?:^|/)%VALID_PACKAGE_NAME%_%VALID_VERSION%(?:_%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz) + qw((?:^|/)%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%(?:_|%5f)%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz) \.rpm index\.db-.+\.gz \.jigdo -- 2.35.1
Bug#932047: lightdm: greeter session support for elogind
Sam, Thanks for this, very helpful. I have again tested both approaches and they both work and I can find no breakage. On Tue, Oct 11, 2022 at 03:30:12PM -0600, Sam Hartman wrote: > I think we want something there that allows people to get third-party > packages into the pam config. > If common-session isn't going to be good enough, then I guess we'd need > to create something on the PAM side. > But let's explore whether common-session is good enough, because it does > look like other display managers have similar architecture and manage to > use common-session. Testing with @include common-session: test@debian-sid:~$ ps -Alf|grep lightdm 4 S root 23261 1 0 80 0 - 58787 - 11:04 ?00:00:00 /usr/sbin/lightdm 4 S root 23266 23261 2 80 0 - 80210 - 11:04 tty7 00:00:25 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch 4 S root 23327 23261 0 80 0 - 40649 - 11:05 ?00:00:01 lightdm --session-child 15 26 0 S test 23435 23432 0 80 0 - 1627 - 11:18 pts/100:00:00 grep lightdm > Here are my thoughts on testing common-session in the greeter config: > > * Take a look at how things appear in logind--does the greeter appear as > a session? If so does anything break because of that? (Withd Gnome, > the greeter does not appear to appear in loginctl list-sessions) Neither for lightdm-greeter: test@debian-sid:~$ loginctl list-sessions SESSION UID USER SEAT TTY 1 1000 test seat0 tty1 7 1000 test seat0 2 sessions listed. > * What selinux context do things appear in. This only matters if > selinux is already in your testing structure I am not sure I have quite understood this, which testing structure are you referring to here? SElinux is not in /etc/pam.d/lightddm-greeter, only /etc/pam.d/lightdm and /etc/pam.d/lightdm-autologin. > * Does the structure of keyrings look like you expect. > > * Do you end up with a systemd for the greeter user (assuming you are > using systemd). If so, do you want one? No test@debian-sid:~$ ps -Alf | grep systemd 4 S root 1 0 0 80 0 - 42151 - 09:19 ?00:01:04 /lib/systemd/systemd --system --deserialize 37 4 S message+ 342 1 0 80 0 - 2309 - 09:19 ?00:00:09 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only 4 S root 345 1 0 80 0 - 3598 - 09:19 ?00:00:05 /lib/systemd/systemd-logind 4 S test 437 1 0 80 0 - 3906 - 09:30 ?00:00:08 /lib/systemd/systemd --user 4 S root6919 1 0 80 0 - 12319 - 09:43 ?00:00:16 /lib/systemd/systemd-journald 4 S systemd+ 11560 1 0 80 0 - 22504 - 10:05 ?00:00:02 /lib/systemd/systemd-timesyncd 4 S root 11591 1 0 80 0 - 6236 - 10:05 ?00:00:06 /lib/systemd/systemd-udevd 0 S test 23149 437 0 80 0 - 2278 - 10:54 ?00:00:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only 0 S test 23439 23432 0 80 0 - 1627 - 11:18 pts/100:00:00 grep systemd > My suspicion is that since this appears to be working for other display > managers, it's all fine. It seems that way to me as well. > But those are the areas where trouble is most likely to show up. Thanks Best wishes Mark
Bug#1021819: sysvinit: Please include German man page translation
Helge, On Sat, Oct 15, 2022 at 01:54:50PM +0200, Helge Kreutzmann wrote: > Source: sysvinit > Version: 3.05-6 > Severity: wishlist > Tags: l10n > > Hello, > due to some problems with using git, the German man page translation > was not present, when 3.05 was released. This has been fixed by > upstream commit bd17b7d538393bae2126fbb0fd94bf07024850b6 on > 2022-08-27. Thanks for this. I was aware of the issue and was waiting for the new upstream release. > Pulling it in simply means copying ./man/po/de.po into man/po and > rebuilding your package. There are a few other issues related to dpkg-divert to address in the maintscripts. I have commits ready to test when 3.06 is released upstream. Best wishes Mark
Bug#932047: lightdm: greeter session support for elogind
Yves-Alexis, On Sun, Oct 09, 2022 at 01:46:56PM +0200, Yves-Alexis Perez wrote: > for some reason it seems I never actually replied to this bug, sorry. No worries. > I might have replied on different bugs, but I'm not really keen on modifying > pam files, especially for specific / non-default stuff. Yes, I remember that from our previous discussions. > Do you know what are the opinion of PAM people and systemd-logind people on > that? Added to CC: Dear Steve and Sam as PAM maintainers, I am wanting to add libpam-elogind support to lightdm-greeter. Currently /etc/pam.d/lightdm-greeter hooks logind directly with session optional pam_systemd.so I have proposed two patches: either to add session optional pam_elogind.so or replace both with @include common-session Yves-Alexis is understandably cautious about changing the PAM configuration. Do you have any thoughts, advice or comments on which might be the most appropriate? Thanks > It might be nice to have them chime in. Also not sure how this thing is > handled on other DM, any idea? A quick look shows most use '@include common-session'. AFAICS that is the case for gdm3: /etc/pam.d/gdm-password sddm: /etc/pam.d/sddm-greeter xdm: /etc/pam.d/xdm slim: /etc/pam.d/slim (although it doesn't use logind interfaces) AFAICS lxdm doesn't use logind at all. HTH. Best wishes Mark
Bug#932047: lightdm: greeter session support for elogind
Hi Yves-Alexis, With another user bumping into this issue, I am keen to have it resolved in bookworm. I think adding session optional pam_elogind.so to /etc/pam.d/lighdm-greeter is the best and correct fix. I know you have been reluctant in the past, but would you consider it again. Alternatively, I am happy to offer an NMU? Best wishes and thanks. Mark
Bug#1019168: sysvinit: [INTL:pt] Portuguese translation of MANPAGE
Control: tags -1 upstream Américo, On Sun, Sep 04, 2022 at 10:33:07PM +0100, Américo Monteiro wrote: > Package: sysvinit > Version: 3.04-1 > Tags: l10n, patch- > Severity: wishlist Thanks very much for this. Forwarded upstream for inclusion. Mark
Bug#1019661: Breaks monin and maybe other packages
Klaus, On Tue, Sep 13, 2022 at 12:16:33PM +0100, Klaus Ethgen wrote: > Package: lsb-base > Version: 11.3 > Severity: critical > > The new package breaks monin as it does not provide > /lib/lsb/init-functions anymore. This file has been moved to sysvinit-utils. Which version of that do you have installed? Mark
Bug#1019529: sysv-rc: tries to install lsb-base, but svsinit-utils replaces files
Samuel, On Sun, Sep 11, 2022 at 11:05:07AM +0200, Samuel Thibault wrote: > Package: sysv-rc > Version: 3.05-1 > Severity: important > Tags: patch Thanks very much for this. The patch seems fine to me as far as it goes. However your clear analysis suggests to me that any debootstrap that includes a package with an lsb-base dependency is also broken. I will do some testing. Mark
Bug#1019480: initscripts: wrong filename test (/etc/rc.local.shutdown) in init.d/rc.local
Patrice, Thanks for spotting this typo. I will upload a fixed version later today. Mark
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
Andreas, On Tue Aug 30 23:05:59 2022 Andreas Beckmann wrote: > Followup-For: Bug #1009915 > Control: found -1 3.05-1 > > Hi, > > there seems to be one manpage (in bootlogd) missing conflict handling: > > /usr/share/man/fr/man8/bootlogd.8.gz Thanks. I was under the impression that manpages-i10n had changed to systemd versions (which doesn't have bootlogd.8) but apparently not. I think we should continue to use the manpages-i10n version and not have any more dpkg diversions than are absolutely necessary. I am away for a week, but will resolve this once I am back. Mark