Bug#1072375: sysvinit: please implement restarting init using triggers
Control: tags -1 patch
Aurelien,
Thanks for this.
I have a proposed patch for this (see attached). I have also taken the
opportunity to rework and cleanup the sysvinit-core postinst.
Any comments are welcome.
On Sat, Jun 01, 2024 at 11:38:04PM +0200, Aurelien Jarno wrote:
> At some point this will allow us to drop the corresponding part
> of the libc6 postinst.
Until that happens, does that mean that sysvinit will be restarted twice, once
by
libc6 postinst and once by the libc-upgrade trigger?
Best wishes
Mark
diff --git a/debian/sysvinit-core.postinst b/debian/sysvinit-core.postinst
index f6d00490..21c565b7 100755
--- a/debian/sysvinit-core.postinst
+++ b/debian/sysvinit-core.postinst
@@ -1,44 +1,12 @@
#! /bin/sh
#
-# sysvinit postinst
+# sysvinit-core postinst
#
set -e
-# Restart init, and migrate to /run/initctl if needed.
+# Restart init.
do_restart() {
- INITCTL=/run/initctl
- case "$(uname -s)" in
- *FreeBSD)
- OLDINITCTL=/etc/.initctl
- ;;
- *)
- OLDINITCTL=/dev/initctl
- ;;
- esac
-
- # PID of init; may not always be 1 but this code isn't run in
- # these cases (Hurd). Use for sending signals and checking if
- # init is running.
- PID=1
-
- # Create /run/initctl if not present, and also create compatibility
- # symlinks
- if [ ! -p "$INITCTL" ]
- then
- # Create new control channel
- echo "sysvinit: creating $INITCTL"
- rm -f $INITCTL
- mkfifo -m 600 $INITCTL
-fi
-
- # Replace old control channel with symlink
- ln -s "$INITCTL" "$OLDINITCTL.new"
- mv "$OLDINITCTL.new" "$OLDINITCTL"
-
- # Reopen control channel (uses new channel).
- kill -s USR1 "$PID"
-
# Tell init to re-exec itself. We loop on failure to reduce
# the chance of a race before the new control channel is
# opened.
@@ -59,57 +27,47 @@ do_restart() {
fi
fi
done
-
- # Remove old pipe if present. No longer in use after re-exec.
- if [ -p "$OLDINITCTL" ]
- then
- rm -f "$OLDINITCTL"
- fi
}
+umask 022
+
case "$1" in
- configure)
- oldver=$2
+configure)
+ if [ -z "$2" ]; then
+ # New installation
+ skip_restart=1
+ fi
+
+ rm -f "$DPKG_ROOT/etc/ioctl.save"
+
+ if [ ! -f "$DPKG_ROOT/etc/inittab" ]; then
+ cp -p "$DPKG_ROOT/usr/share/sysvinit/inittab" "$DPKG_ROOT/etc/inittab"
+ fi
;;
- abort-upgrade|abort-remove|abort-deconfigure)
+triggered)
+ # Restart, if possible
+ ;;
+abort-upgrade|abort-remove|abort-deconfigure)
exit 0
;;
+*)
+echo "postinst called with unknown argument \`$1'" >&2
+exit 1
+ ;;
esac
-umask 022
-
-rm -f "$DPKG_ROOT/etc/ioctl.save"
-
-if [ ! -f "$DPKG_ROOT/etc/inittab" ]
+if ischroot --default-true ||
+ [ -n "${DPKG_ROOT:-}" ] ||
+ [ -d "$DPKG_ROOT/run/systemd/system" ] ||
+ [ "$(uname -s)" = "GNU" ]
then
- cp -p "$DPKG_ROOT/usr/share/sysvinit/inittab" "$DPKG_ROOT/etc/inittab"
-fi
-
-restart=yes
-
-if [ -z "${oldver}" ]; then
-restart=no
-fi
-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
+skip_restart=1
fi
-if [ "$restart" = "yes" ]; then
- do_restart
+if [ "$skip_restart" ]; then
+echo "Not restarting sysvinit"
else
- echo "Not restarting sysvinit"
+do_restart
fi
#DEBHELPER#
diff --git a/debian/sysvinit-core.triggers b/debian/sysvinit-core.triggers
new file mode 100644
index ..ac00c071
--- /dev/null
+++ b/debian/sysvinit-core.triggers
@@ -0,0 +1 @@
+interest-noawait libc-upgrade
Bug#1072817: bookworm-pu: package openrc/0.45.2-2+deb12u1
Control: tags -1 - moreinfo
Adam,
On Sat, Jun 08, 2024 at 12:35:21PM +0100, Adam D. Barratt wrote:
> While you have attached a debdiff, it's of the binary packages. Please
> provide a source debdiff, i.e. between the current and proposed DSCs.
Apologies, attached.
Thanks.
Mark
diff -Nru openrc-0.45.2/debian/changelog openrc-0.45.2/debian/changelog
--- openrc-0.45.2/debian/changelog 2022-08-02 11:46:15.0 +0100
+++ openrc-0.45.2/debian/changelog 2024-05-02 10:04:20.0 +0100
@@ -1,3 +1,10 @@
+openrc (0.45.2-2+deb12u1) bookworm; urgency=medium
+
+ * d/openrc.postinst: ignore non-executable scripts in /etc/init.d
+(Closes: #1070167)
+
+ -- Mark Hindley Thu, 02 May 2024 10:04:20 +0100
+
openrc (0.45.2-2) unstable; urgency=medium
* Fix FTBFS on Hurd: explicitly set pam option and don't require kvm.
diff -Nru openrc-0.45.2/debian/gbp.conf openrc-0.45.2/debian/gbp.conf
--- openrc-0.45.2/debian/gbp.conf 2022-08-02 11:46:15.0 +0100
+++ openrc-0.45.2/debian/gbp.conf 2024-05-02 10:04:20.0 +0100
@@ -1,6 +1,6 @@
[DEFAULT]
upstream-branch = master
-debian-branch = debian
+debian-branch = bookworm
upstream-tag = %(version)s
compression = xz
pristine-tar = False
diff -Nru openrc-0.45.2/debian/openrc.postinst
openrc-0.45.2/debian/openrc.postinst
--- openrc-0.45.2/debian/openrc.postinst2022-08-02 11:46:15.0
+0100
+++ openrc-0.45.2/debian/openrc.postinst2024-05-02 10:04:20.0
+0100
@@ -25,7 +25,7 @@
rclink=/etc/rc${rl}.d/${f}
initsh=$(readlink -f ${rclink})
svc=$(basename ${initsh})
- if [ -f ${initsh} ]; then
+ if [ -x ${initsh} ]; then
case ${rl} in
1) orl="recovery" ;;
2) orl="default" ;;
@@ -33,8 +33,12 @@
esac
rc-update add ${svc} ${orl}
else
+ if [ -f ${initsh} ]; then
+ echo "*** WARNING: skipping non-executable
$initsh"
+ else
echo "*** WARNING: dangling link $rclink"
echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs
${svc}"
+ fi
fi
done
done
Bug#1072817: bookworm-pu: package openrc/0.45.2-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ope...@packages.debian.org
Control: affects -1 + src:openrc
Dear Release Team,
Please unblock openrc in bookworm-pu. Version 0.45.2-2+deb12u1 includes a
backported fix for #1070167 which prevents openrc's postinst choking on
non-executable scripts in /etc/init.d. These now arise routinely: since
debhelper 13.10 the dh_installinit fragments clear the executable bit on package
removal. The relevant debhelper changelog entries are
* dh_installinit: Remove executable bit of init scripts on
package removal (via preinst). Related to #1021027.
* dh_installsystemd: Stop masking system units on package
removal. This is no longer necessary with the init scripts
getting their exec bit cleared on package removal.
(Closes: #1021027)
The openrc fix has been in unstable and testing for over a month with no
regressions reported.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
Thanks
Mark
File lists identical (after any substitutions)
Control files of package libeinfo-dev: lines which differ (wdiff format)
Depends: libeinfo1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package libeinfo1: lines which differ (wdiff format)
-
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package libeinfo1-dbgsym: lines which differ (wdiff format)
Depends: libeinfo1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package librc-dev: lines which differ (wdiff format)
-
Depends: librc1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package librc1: lines which differ (wdiff format)
--
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package librc1-dbgsym: lines which differ (wdiff format)
-
Depends: librc1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package openrc: lines which differ (wdiff format)
--
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Control files of package openrc-dbgsym: lines which differ (wdiff format)
-
Depends: openrc (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}
Bug#1072580: Please provide v256
Control: tags -1 moreinfo Matthias, Thanks for this. On Tue, Jun 04, 2024 at 07:01:24PM +0200, Matthias Geiger wrote: > Package: elogind > Severity: wishlist > X-Debbugs-Cc: werdah...@riseup.net > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > please provide elogind 256 That doesn't exist upstream[1] > as systemd is already at that version in unstable. This causes a mismatch > which blocks me at the moment from setting up my machine with openrc. Can you be more specific? In Debian, there is no longer a connection between systemd and elogind versions. What are you trying to do and how does it fail? Thanks Mark [1] https://github.com/elogind/elogind
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: severity -1 normal On Fri, May 17, 2024 at 08:58:34AM +0100, Mark Hindley wrote: > On Wed, May 08, 2024 at 01:09:59PM +0100, Mark Hindley wrote: > > Michael and Steve, > > > > I would appreciate some help here. > > Bump to reset autoremove timer. Still no response. Downgrading severity to avoid the autoremove dance again. Mark
Bug#1072011: bootlogd: typo in /etc/init.d/bootlogd on trixie/testing
Control: tags -1 pending On Mon, May 27, 2024 at 03:57:46PM +0200, Jin-Woo wrote: > Package: bootlogd > Version: 3.09-1 > Severity: normal > X-Debbugs-Cc: saesor...@420blaze.it > > /etc/init.d/bootlogd contains a check for whether the system boots with > systemd: > > if [ -d /run/system/system ]; then > > this should probably spell: > > if [ -d /run/systemd/system ]; then Thanks -- well spotted! I have queued this for the next upload. Mark
Bug#1071964: Elogind defaults to s2idle
Control: forwarded -1 https://github.com/elogind/elogind/issues/285 Control: tags -1 upstream On Sun, May 26, 2024 at 05:14:55PM +0200, Juliusz Chroboczek wrote: > Filed upstream at https://github.com/elogind/elogind/issues/285. Thanks. I think that is the right place to discuss this further. You would need to present a persuasive argument for Debian to deviate from the upstream default. FTR, the change in behaviour is documented with a workaround in debian/NEWS[1] Mark [1] https://git.devuan.org/devuan/elogind/src/branch/debian/debian/NEWS
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
On Wed, May 08, 2024 at 01:09:59PM +0100, Mark Hindley wrote: > Michael and Steve, > > I would appreciate some help here. Bump to reset autoremove timer. Mark
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: tags -1 moreinfo Michael and Steve, I would appreciate some help here. On Tue, Mar 05, 2024 at 07:33:40AM +, Mark Hindley wrote: > Control: severity -1 normal > > On Tue, Feb 06, 2024 at 05:43:41PM +0000, 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 am still not convinced that consolekit2 requires this. As identified above, it looks to me that the abi-compliance-checker tool failed and that failure flagged consolekit2 as requiring t64 migration. I may be looking for the wrong thing (in which case, please tell me the correct thing to look for), but there are no references to time_t in either library and the output from: $ git -C /home/mark/src/devuan/consolekit2/ grep time_t libconsolekit/ libck-connector/ is empty. The only references to time_t are in src/ck-tty-idle-monitor.c (used in /usr/sbin/console-kit-daemon) and tools/ck-history.c (/usr/bin/ck-history). $ git -C /home/mark/src/devuan/consolekit2/ grep time_t src/ck-tty-idle-monitor.c:time_t now; src/ck-tty-idle-monitor.c:time_t idletime; src/ck-tty-idle-monitor.c:time_t last_access; tools/ck-history.c:time_t secs; tools/ck-history.c:time_t added_t, removed_t; tools/ck-history.c:time_t oldest_e; tools/ck-history.c:time_t oldest_e; I am reluctant to implement this change unnecessarily. I would appreciate you expertise and guidance. Many thanks Mark
Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."
Lorenzo, Thanks for the reminder. On Fri, May 03, 2024 at 03:10:57PM +0200, Lorenzo wrote: > Is this is a duplicate of #950986? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950986 > I bet the patch there would fix this bug too Embarrassingly, that is my patch which I clearly have no recollection of! :-| Now I look, we have been shipping a variation on it in Devuan since 2020[1]. Mark [1] https://git.devuan.org/devuan/cgroupfs-mount/commit/ff91abfaf3a5c5633744ea552084125ec6c68ce5
Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."
Axel, On Fri, May 03, 2024 at 01:05:15PM +0200, Axel Beckert wrote: > P.S.: Given that Christian's NMU doesn't even touch the maintainer > scripts, I suspect that this issue is also present in version 1.4. I > though didn't notice it before then, so it might be related to recent > elogind changes, hence Cc'ing the Debian Init System Diversity Team, > too. Since this is the first cgroupfs-mount update since 2017 (which predates elogind's arrival in Debian) I suspect it has always been there, just uncovered by the cgroupfs-mount NMU. My gut reaction is that cgroupfs-mount shouldn't be unmounting and remounting cgroups on upgrade and it needs some dh_installinit magic in d/rules. Mark
Bug#1070167: openrc: postinst fails with not executable script in /etc/init.d/
Lorenzo, I think this issue is sufficiently significant to fix in bookworm. I'll wait until the fix is well tested first. Mark
Bug#1070167: openrc: postinst fails with not executable script in /etc/init.d/
On Wed, May 01, 2024 at 07:10:29PM +0200, Lorenzo wrote:
> > Thanks. Does the attached patch help?
>
> yes, it seems it works
Good.
As small refinement to avoid emitting inappropriate dangling symlink warnings.
Mark
>From 07d2dd72221e961637ea7a9cd2143b6c8a411373 Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 1 May 2024 18:33:39 +0100
Subject: [PATCH] Don't emit dangling symlink warning for non-executable
scripts.
---
debian/openrc.postinst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/openrc.postinst b/debian/openrc.postinst
index 3b62f026..e53be30c 100644
--- a/debian/openrc.postinst
+++ b/debian/openrc.postinst
@@ -37,8 +37,8 @@ if [ "${1}" = "configure" ] ; then
echo "*** WARNING: skipping non-executable $rclink"
else
echo "*** WARNING: dangling link $rclink"
+ echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
fi
- echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
fi
done
done
--
2.39.2
Bug#1070167: openrc: postinst fails with not executable script in /etc/init.d/
Control: tags -1 patch
Lorenzo,
On Wed, May 01, 2024 at 10:59:36AM +0200, Lorenzo Puliti wrote:
> Package: openrc
> Version: 0.45.2-2
> Severity: normal
> X-Debbugs-Cc: plore...@disroot.org
>
> Hi,
>
> it appears that, at least under certain conditions, openrc postinstall
> script fails if a sysvinit script in /etc/init.d/ is not executable.
>
> Note that recently debhelper started to chmod -x initscripts when a package is
> removed but not purged, so openrc should deal whit non executebles files under
> /etc/init.d/
Thanks. Does the attached patch help?
Mark
>From 7d20e19bf392869853fb7df884030c669d7ff641 Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 1 May 2024 11:16:44 +0100
Subject: [PATCH] d/openrc.postinst: ignore non-executable scripts in
/etc/init.d
Closes: #1070167
---
debian/openrc.postinst | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/debian/openrc.postinst b/debian/openrc.postinst
index 6e5cd7ae..3b62f026 100644
--- a/debian/openrc.postinst
+++ b/debian/openrc.postinst
@@ -25,7 +25,7 @@ if [ "${1}" = "configure" ] ; then
rclink=/etc/rc${rl}.d/${f}
initsh=$(readlink -f ${rclink})
svc=$(basename ${initsh})
- if [ -f ${initsh} ]; then
+ if [ -x ${initsh} ]; then
case ${rl} in
1) orl="recovery" ;;
2) orl="default" ;;
@@ -33,8 +33,12 @@ if [ "${1}" = "configure" ] ; then
esac
rc-update add ${svc} ${orl}
else
+ if [ -f ${initsh} ]; then
+echo "*** WARNING: skipping non-executable $rclink"
+ else
echo "*** WARNING: dangling link $rclink"
-echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
+ fi
+ echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs ${svc}"
fi
done
done
--
2.39.2
Bug#1070032: elogind: add NEWS for 255.4.1, suspend now default to s2idle instead of s2ram
On Mon, Apr 29, 2024 at 01:11:11AM +0200, Lorenzo Puliti wrote: > I think this change is worth a NEWS entry, with an example > that explains how to revert to the previous default. Sounds a good idea. Thanks. I'll queue your suggestion for the next upload. Best wishes, Mark
Bug#1069787: debootstrap: autopkgtest fails since t64 migration
Actually, the situation has deteriorated further. In addition to gnupg, the systemd pre-depends on libssl3 is no longer satisfiable: dpkg: regarding .../systemd_255.4-1_amd64.deb containing systemd, pre-dependency problem: systemd pre-depends on libssl3 (>= 3.0.0) libssl3 is not installed. $ rmadison -s trixie libssl3 libssl3t64 libssl3t64 | 3.2.1-3 | testing| amd64, arm64, armel, armhf, i386, mips64el, ppc64el, s390x libssl3| 3.1.5-1 | testing| armel, armhf Mark
Bug#1069787: debootstrap: autopkgtest fails since t64 migration
Package: debootstrap
Version: 1.0.134
Severity: important
Tags: patch
Dear Maintainer,
The debian/tests/debian-testing autopkgtest has been broken on 64bit archs by
the t64 transition in trixie. Specifically the test includes gnupg as an
additional package. Gnupg depends on gpg-agent which depends on
libnpth0. However, in trixie, libnpth0 is now provided by libnpth0t64 which
debootstrap doesn't handle.
I suggest changing the test to include gpgv which avoids the t64 transition
whilst providing similar functional coverage.
Patch attached.
Mark
-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-19-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)
Versions of packages debootstrap depends on:
ii wget 1.21.3-1+b2
Versions of packages debootstrap recommends:
ii arch-test 0.21-1
ii gnupg 2.2.40-1.1
ii mount 2.38.1-5+deb12u1
Versions of packages debootstrap suggests:
ii debian-archive-keyring 2023.3+deb12u1
pn squid-deb-proxy-client
pn ubuntu-archive-keyring
-- no debconf information
>From 1a79250dc45375032f4758204ec3234fd4ed006a Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 24 Apr 2024 10:01:53 +0100
Subject: [PATCH] d/t/debian-testing: change from gnupg to gpgv; debootstrap
with gnupg is broken by libnpth0t64 Provides libnpth0.
---
debian/tests/debian-testing | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/tests/debian-testing b/debian/tests/debian-testing
index 7c3e323..89a04fe 100755
--- a/debian/tests/debian-testing
+++ b/debian/tests/debian-testing
@@ -340,7 +340,7 @@ my $testing = $distro_info->testing;
# Should specify multiple components for checking (see Bug#898738)
if (!verbose_run([length($ENV{DEBOOTSTRAP_SCRIPT}) ? $ENV{DEBOOTSTRAP_SCRIPT}
: 'debootstrap',
-'--include=debootstrap,debian-archive-keyring,gnupg,hello,systemd',
+'--include=debootstrap,debian-archive-keyring,gpgv,hello,systemd',
'--variant=minbase',
'--components=main,contrib,non-free',
$testing, 'chroot.d', $mirror], '>&2')) {
--
2.39.2
Bug#1069182: Reassign lvm2
Control: reassign -1 lvm2 On Thu, Apr 18, 2024 at 02:24:06PM +0500, Alex Volkov wrote: > On четверг, 18 апреля 2024 г. 11:38:18 +05 Mark Hindley wrote: > > > udevadm: info --cleanup-db > > "db_persist=" -> "db_persist" > > require explicit "db_persist" to exclude device info from --db-cleanup > > Wow. I knew there's something in this transition to --db-cleanup. > > > Does this mean that dm mapper should set db_persist in the initramfs? > > More like it's actually needs to be set by the corresponding udev rule in lvm2 > package (which does all that device-mapper devices detection). I tried adding > the corresponding OPTIONS+="db_persist" line into 55-dm.rules file and it > worked as intended. I will report the bug to lvm2. I think we can just reassign this one. Dear lvm2 maintainers, We have been investigating why devices discovered by the initramfs were being cleaned by /etc/init.d/udev. The udev initscript runs udevadm info --cleanup-db. It appears to be the responsibility of devices that should not be cleaned to set db_persist in their setup rule. There appears to be a recent upstream lvm2 commit to address this[1]. Thanks Mark [1] https://gitlab.com/lvmteam/lvm2/-/commit/eb4f744820832aff3d6da1bba14f12e91a5b3535
Bug#1069182: More background
> Does this mean that dm mapper should set db_persist in the initramfs? Or the initramfs generator. AFAICS dracut already does this[1], but I don't immediately see an equivalent for initramfs-tools. Are you using initramfs-tools? Does switching to dracut improve the situation? Mark [1] https://codesearch.debian.net/search?q=db_persist+package%3A%5CQdracut%5CE
Bug#1069182: More background
Alex, Thanks for your continued research into this. The upstream 168 changelog is informative (edited for relevant parts): Summary of changes from v167 to v168 Kay Sievers (35): udevadm: info --cleanup-db "db_persist=" -> "db_persist" require explicit "db_persist" to exclude device info from --db-cleanup It is somewaht opaque, but the relevant commits appear to be in the current systemd git[1]. Does this mean that dm mapper should set db_persist in the initramfs? Mark [1] https://github.com/search?q=repo%3Asystemd%2Fsystemd+db_persist=commits
Bug#1069182: initscripts: udev initscript SHOULD NOT clear the udev database at startup
Boian, On Wed, Apr 17, 2024 at 02:53:08PM +0100, Mark Hindley wrote: > On Wed, Apr 17, 2024 at 05:25:08PM +0500, Alex Volkov wrote: > > Now, /etc/init.d/udev for some reason does this in its start clause: > > > > === > >135 # clean up parts of the database created by the initramfs udev > >136 udevadm info --cleanup-db > > === I notice Devuan's eudev initscript contains the same[1], presumably with the same origin. Do you have any thoughts on its purpose or necessity? Thanks Mark [1] https://git.devuan.org/devuan/eudev/src/branch/suites/unstable/debian/eudev.init#L160
Bug#1069182: initscripts: udev initscript SHOULD NOT clear the udev database at startup
Control: tags -1 moreinfo help Alex, Many thanks for this and your detailed analysis. On Wed, Apr 17, 2024 at 05:25:08PM +0500, Alex Volkov wrote: > Now, /etc/init.d/udev for some reason does this in its start clause: > > === >135 # clean up parts of the database created by the initramfs udev >136 udevadm info --cleanup-db > === [...] > Note that systemd-based systems are not affected, as they seemingly don't > relate to the initrd scripts for starting udev. I suspect the original reason for this will be hard to track down. Git blaming d/udev.init from systemd 254.1-3 shows those lines as being merged in 2013 from udev 175-7[1]. > If there is a valid reason for cleaning the database, the issue needs to be > researched further, of course. Quite. Dear systemd maintainers, Do you have any insight into why clearing the initramfs udev db might have been or might still be required? Or any unanticipated effects of not doing so? Thanks Mark [1] https://salsa.debian.org/systemd-team/systemd/-/commit/b56f8637a1e03ac6a45af7820287159df9b506b9
Bug#1069177: sysvinit-utils: wording mistake in description
Control: tags -1 pending Maytham, On Wed, Apr 17, 2024 at 02:33:29PM +0300, Maytham Alsudany wrote: > Package: sysvinit-utils > Version: 3.08-7 > Severity: minor > > Found this while translating; do you mean "formerly"? Yes, of course. Thanks for pointing it out. Queued for the next upload. Mark
Bug#1068245: ITP: iwgtk -- lightweight graphical frontend to iwd
Package: wnpp Severity: wishlist Owner: Mark Hindley X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: iwgtk Version : 0.9 Upstream Contact: Jesse Lentz * URL : https://github.com/J-Lentz/iwgtk * License : GPL3+ Programming Lang: C Description : Lightweight graphical frontend to iwd iwgtk is a lightweight gtk4 frontend to iwd which provides similar functionality to that of iwctl. Features include viewing and connecting to available networks, managing known networks, provisioning new networks via WPS or Wi-Fi Easy Connect and an indicator (tray) icon displaying connection status and signal strength. Mark
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
