Bug#1061493: consolekit: install PAM module and udev files into /usr

2024-03-14 Thread Mark Hindley
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

2024-03-13 Thread Mark Hindley
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]

2024-03-13 Thread Mark Hindley
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

2024-03-04 Thread Mark Hindley
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

2024-02-08 Thread Mark Hindley
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

2024-02-06 Thread Mark Hindley
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

2024-02-06 Thread Mark Hindley
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

2024-01-25 Thread Mark Hindley
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

2024-01-22 Thread Mark Hindley
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

2024-01-22 Thread Mark Hindley
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'

2023-12-06 Thread Mark Hindley
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'

2023-12-06 Thread Mark Hindley
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'

2023-12-06 Thread Mark Hindley
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'

2023-12-06 Thread Mark Hindley
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'

2023-12-06 Thread Mark Hindley
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

2023-12-05 Thread Mark Hindley
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

2023-12-03 Thread Mark Hindley
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

2023-11-30 Thread Mark Hindley
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

2023-11-22 Thread Mark Hindley
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

2023-11-20 Thread Mark Hindley
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

2023-11-20 Thread Mark Hindley
Control: tags -1 pending

Thanks.

Queued for the next upload.

Mark



Bug#1056049: consolekit2: Not buildable on hurd-i386

2023-11-16 Thread Mark Hindley
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

2023-11-15 Thread Mark Hindley
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

2023-11-13 Thread Mark Hindley
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

2023-11-08 Thread Mark Hindley
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.

2023-11-07 Thread Mark Hindley
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

2023-11-07 Thread Mark Hindley
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

2023-10-31 Thread Mark Hindley
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

2023-10-29 Thread Mark Hindley
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

2023-10-11 Thread Mark Hindley
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

2023-10-11 Thread Mark Hindley
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

2023-10-04 Thread Mark Hindley
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

2023-10-04 Thread Mark Hindley
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

2023-10-03 Thread Mark Hindley
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

2023-10-01 Thread Mark Hindley
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

2023-09-27 Thread Mark Hindley
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

2023-09-26 Thread Mark Hindley
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"

2023-09-20 Thread Mark Hindley
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

2023-09-20 Thread Mark Hindley
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

2023-09-20 Thread Mark Hindley
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

2023-09-19 Thread Mark Hindley
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

2023-09-19 Thread Mark Hindley
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

2023-09-19 Thread Mark Hindley
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

2023-09-19 Thread Mark Hindley
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

2023-09-13 Thread Mark Hindley
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

2023-09-11 Thread Mark Hindley
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

2023-09-03 Thread Mark Hindley
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

2023-08-23 Thread Mark Hindley
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

2023-08-23 Thread Mark Hindley
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

2023-08-22 Thread Mark Hindley
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

2023-08-22 Thread Mark Hindley
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

2023-08-19 Thread Mark Hindley
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

2023-07-27 Thread Mark Hindley
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)

2023-07-07 Thread Mark Hindley
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

2023-07-02 Thread Mark Hindley
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

2023-07-02 Thread Mark Hindley
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

2023-07-01 Thread Mark Hindley
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

2023-06-30 Thread Mark Hindley
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

2023-06-26 Thread Mark Hindley
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

2023-06-21 Thread Mark Hindley
[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

2023-06-18 Thread Mark Hindley
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

2023-06-17 Thread Mark Hindley
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

2023-06-17 Thread Mark Hindley
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

2023-06-16 Thread Mark Hindley


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

2023-06-13 Thread Mark Hindley
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

2023-06-13 Thread Mark Hindley
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

2023-06-13 Thread Mark Hindley
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

2023-04-26 Thread Mark Hindley
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

2023-04-13 Thread Mark Hindley
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

2023-04-12 Thread Mark Hindley
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

2023-04-10 Thread Mark Hindley
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

2023-04-05 Thread Mark Hindley
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

2023-04-03 Thread Mark Hindley
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

2023-03-30 Thread Mark Hindley
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

2023-03-30 Thread Mark Hindley
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

2023-03-29 Thread Mark Hindley
This single hunk on top of 3.06-2 fixes pidof following multiple symlinks for me
when invoked as 

 pidof $(which vi)

Markus, can you confirm that works for you?

Since it is a regression since bullseye, it seems a suitable targeted fix to
attempt for bookworm.

Thanks to everybody.

Mark
>From 93da64d13380b29fd330608493615f8877525494 Mon Sep 17 00:00:00 2001
From: Jesse 
Date: Wed, 29 Mar 2023 10:34:45 -0300
Subject: [PATCH] Accepted patch from Mark Hindle which avoids clearing
 realpath information in pidof when trying to find matching executables.

---
 src/killall5.c | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/killall5.c b/src/killall5.c
index 9ab0782a..6f7528ad 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -740,8 +740,8 @@ PIDQ_HEAD *pidof(char *prog)
 		return NULL;
 
 	/* Try to stat the executable. */
+	memset(real_path, 0, sizeof(real_path));
 	if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) {
-		memset(_path[0], 0, sizeof(real_path));
 		dostat++;
 	}
 
-- 
2.39.2



Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

2023-03-29 Thread Mark Hindley
On Wed, Mar 29, 2023 at 08:37:00AM -0300, Jesse Smith wrote:
> > Given subsequent discussion, could we instead use canonicalize_file_name
> > or realpath here instead? That would give us the "correct" path without
> > pidof having to think hard about symlinks et al.
> 
> I'm open to the possibility. I'm curious as to what you see as the pros
> vs cons of changing the approach used by pidof?

Markus' orginal report suggested this was a regression since Bullseye

 sysvinit-utils | 2.96-7+deb11u1 | stable | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

rather than a proposal to change behaviour.

I think I have found the offending commit:
0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which 
wipes
the canonical resolved path.

I suggest this fix as a starting point.

Mark

>From 346cc4a8a91f908c8a57a16fb041c44809517183 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Wed, 29 Mar 2023 13:57:24 +0100
Subject: [PATCH] Fix following of executable symlinks.

Fixes regression introduced in 0b695c7e0b1cac60ed77c56f224e296f023b652e
---
 src/killall5.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/killall5.c b/src/killall5.c
index b0728fab..787c4226 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -739,10 +739,8 @@ PIDQ_HEAD *pidof(char *prog)
 		return NULL;
 
 	/* Try to stat the executable. */
-	if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) {
-		memset(_path[0], 0, sizeof(real_path));
+	if ( (prog[0] == '/') && ( realpath(prog, real_path) ) )
 		dostat++;
-	}
 
 	/* Get basename of program. */
 	if ((s = strrchr(prog, '/')) == NULL)
-- 
2.39.2



Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

2023-03-28 Thread Mark Hindley
On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote:
> > $ ls -l $(which vi)
> > lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi ->
> > /etc/alternatives/vi
> > $ ls -l /etc/alternatives/vi
> > lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi ->
> > /usr/bin/vim.tiny
> > $ ls -l /usr/bin/vim.tiny
> > -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny
> 
> 
> Okay, yes, this makes sense. The symbolic links are making multiple
> jumps so it won't work. This is expected behaviour because there is no
> executable running called /usr/bin/vi or /etc/alternatives/vi. Running
> "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to
> /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't
> follow aliases or symbolic links with multiple hops and different names.

As Thorsten pointed out, multiple layers of symlinks is used in several places
in Debian, not least the alternatives system.

Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical
executable path?

Alternatively, if you really want to keep the behaviour change then pidof.8
needs updating to reflect the new behaviour.

Mark



Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

2023-03-22 Thread Mark Hindley
Control: tags -1 upstream

Jesse,

Thanks for your quick work on this.

On Wed, Mar 22, 2023 at 12:40:43PM -0300, Jesse Smith wrote:
> This has been fixed upstream for the upcoming sysvinit 3.07. Would be
> great to get some people testing it before we do an official reelase of
> the 3.07 branch.
> 
> The updated pidof will now return an PID matches for a corresponding
> executable or symbolic link. In other words, if /tmp/sleep is a symbolic
> link to /usr/bin/sleep, then it doesn't matter which path name we use,
> pidof will recognize both names go to the same real program and print
> its PID.

I have just done a local build of 3.06 with a cherry pick of just this hunk of
b70b2776

diff --git a/src/killall5.c b/src/killall5.c
index 992ce3e1..75750d32 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -763,6 +763,11 @@ PIDQ_HEAD *pidof(char *prog)
add_pid_to_q(q, p);
foundone++;
}
+else if ( (p->argv0) && (! strcmp(p->argv0, prog) ) )
+{
+add_pid_to_q(q, p);
+foundone++;
+}
}
}
 
-- 
2.39.2

The patched version still fails to find a running vi process when run as

 pidof $(which vi)

Is that because there are 2 layers of symlinks?

 /usr/bin/vi ->  /etc/alternatives/vi ->  /usr/bin/vim.basic

Mark



Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

2023-03-22 Thread Mark Hindley
Markus,

Thanks for this.

On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
> Package: sysvinit-utils
> Version: 3.06-2
> Severity: normal
> X-Debbugs-Cc: none
> 
> Dear Maintainer,
> 
> Passing the full path of a binary to the pidof command does not always
> return a pid although the process is running and the man page of the
> pidof command explicitly notes that it can be used that way.
> 
> This might be related to the fact that all programs with which I tested
> this and which show this unexpected behaviour were symlinks (i.e.,
> "which " returned a symlink).

Yes, I just tried with vim.basic which is not a symlink on my system and both

 pidof vim.basic
 pidof $(which vim.basic)

work as expected.

> However, on Debian Bullseye the
> behaviour is as I expected it.

So this appears to be a change in behaviour. I suspect this is an inadvertent
side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e.

Jesse, or was it intentional?

Thanks

Mark



Bug#1032379: bug#746: Killed when starting modale dialog like pinentry

2023-03-08 Thread Mark Hindley
On Wed, Mar 08, 2023 at 11:26:37AM +0100, Klaus Ethgen wrote:
> > Maybe you can add this information to #1032379 and reassign?
> 
> I can prove it. If I revert the last update of libx11-6, libx11-data and
> libx11-xcb1, everything works correct again.

Good work! Thanks.

Mark



Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

2023-03-06 Thread Mark Hindley
Simon,

Thanks.

On Mon, Mar 06, 2023 at 03:25:18PM +, Simon McVittie wrote:
> What I absolutely don't want is to make the change, and then 2 years
> later get hate mail from someone telling me that I've broken their
> system by making dbus-launch prevent /home from being unmounted and
> "why can't you just" add an option to use daemon(3).

I think that is a very good point.

KDE is the only area where I have heard of this causing problems and I am not
aware of any other reports that seem to have the same underlying cause. I am not
convinced there *is* a consensus for change and the risk of changing the default
for all users of legacy DBus activation seems high.

Martin, I still think this is for KDE to address if it is important to them. I
don't think I would push to change the behaviour of DBus in either Debian or
Devuan at the moment.

Best wishes

Mark



Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

2023-03-06 Thread Mark Hindley
Control: forwarded -1  https://bugs.debian.org/1032368

Martin,

Thanks for this.

On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote:
> Package: dbus-x11
> Version: 1.14.6-1devuan1
> Severity: normal
> X-Debbugs-Cc: mar...@lichtvoll.de
> 
> Dear Maintainer,
> 
> I also reported this to Debian as

Simon McVittie's is, of course, correct that src:dbus being forked in Devuan
means this should be dealt with in Devuan. Notwithstanding that, I am very
grateful for his thorough, considered and illuminating reply. The same behaviour
is evident in a non-systemd Debian installation.

Like Simon, I have no experience of KDE or krunner. I also agree that legacy
DBus activation appears to be working here as intended and documented, with no
guarantee on the cwd given.

My gut reaction is that this issue is should really be resolved elsewhere. If
it is crucial that krunner uses a particular working directory, then it needs to
chdir() explicitly itself.

I also quite understand his concern that changing the behaviour of DBus may have
unintended consequences and I am certain that changing the behaviour of DBus
during the freeze will not happen. I suppose early in the next cycle is
possible. Simon, might the implications of that be reviewed again upstream? I
found an upstream issue with patch to implement such behaviour that has not been
merged[1].

Thanks

Mark

[1]  https://gitlab.freedesktop.org/dbus/dbus/-/issues/214



Bug#1028664: colord: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test --timeout-multiplier 3 returned exit code 1

2023-02-09 Thread Mark Hindley
Control: reassign -1 liblcms2-2 2.14-1
Control: affects -1 colord

I hit this FTBFS today.

The gdb backtrace of the failing test is

Thread 1 "colord-test-pri" received signal SIGSEGV, Segmentation fault.
0x77bd359a in cmsMLUtranslationsCodes () from 
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
(gdb) bt
#0  0x77bd359a in cmsMLUtranslationsCodes () at 
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
#1  0x77f9c598 in cd_icc_to_string (icc=icc@entry=0x5559e2c0) at 
../lib/colord/cd-icc.c:435
#2  0x55566c4e in colord_icc_func () at 
../lib/colord/cd-test-private.c:1529
#3  0x77c8764e in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77c873b5 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x77c87b52 in g_test_run_suite () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x77c87bbd in g_test_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0xb428 in main (argc=, argv=) at 
../lib/colord/cd-test-private.c:2400
(gdb)

I suppose this has been caused by the upload of version 2.14-1 of liblcms2-2,
but I don't immediately see the change there that has caused it.

Reassigning.

Mark



Bug#1028555: apt-cacher: hardcodes list of supported architectures

2023-01-12 Thread Mark Hindley
Antonio,

Thanks for this.

On Thu, Jan 12, 2023 at 02:03:59PM -0300, Antonio Terceiro wrote:
> Package: apt-cacher
> Version: 1.7.28.1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> I was creating a cross build environment for riscv64, and my downloads
> failed because apt-cacher did not recognize it. I then discovered that
> apt-cacher has a hardcoded list of supported architectures.
> 
> The attached patch reads the list of most common supported architectures
> from dpkg directly, so that you don't need to add architectures by hand
> every time one comes around.

Yes, I have tried this approach in the past but rejected it. My concern was that
it includes many theoretically possible, but practically not available
architectures.

Maybe that is overly cautious.

Mark



Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs

2023-01-09 Thread Mark Hindley
On Mon, Jan 09, 2023 at 05:44:44PM +0100, Thorsten Glaser wrote:
> On Mon, 9 Jan 2023, Mark Hindley wrote:
> 
> >Yes, although I think the default fstab has pass=1 for root.
> 
> Nope. The default fstab is precisely this:
> 
> >> # UNCONFIGURED FSTAB FOR BASE SYSTEM

Yes, That is the debootstrap one. However on a new installation, partconf then
fills in the entries for the newly partitioned system[1]

Mark

[1]  https://sources.debian.org/src/partconf/1.52/mkfstab.c/#L300



Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs

2023-01-09 Thread Mark Hindley
Thorsten,

Thanks for this.

On Mon, Jan 09, 2023 at 02:55:59PM +0100, Thorsten Glaser wrote:
> On Mon, 9 Jan 2023, Mark Hindley wrote:
> 
> >> fsck is util-linux, not e2fsprogs.
> >
> >Yes, but fsck.ext4 is e2fsprogs and that is what is missing in #1028181.
> 
> But that’s ⓐ the user’s problem and ⓑ not necessarily an error
> as there exist filesystems for which no fsck binary exists.
> 
> (If the user has set pass to ≠0 in fstab(5) it’s their own fault
> of course.)

Yes, although I think the default fstab has pass=1 for root.

In #1028181, Holger says

> Nowadays, checking ext4 filesystems is optional and systemd skips doing it in
> the absence of e2fsprogs.

If that is true (and I have no particular reason to doubt him) maybe the default
fstab should be changed now the default fs is ext4. But it doesn't look like
something to insert special handling for in initscripts.

Mark



Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs

2023-01-09 Thread Mark Hindley
On Mon, Jan 09, 2023 at 12:57:53AM +0100, Thorsten Glaser wrote:
> On Mon, 9 Jan 2023, Lorenzo Puliti wrote:
> 
> >This package "only" recommands e2fsprogs, so I think it should just
> 
> fsck is util-linux, not e2fsprogs.

Yes, but fsck.ext4 is e2fsprogs and that is what is missing in #1028181.

A clean way of handling missing filesystem-specific fsck isn't immediately
apparent to me. fsck doesn't distinguish a missing filesystem-specific checker
from other operational errors.

Mark



Bug#1027945: sysvinit: [INTL:pt] Portuguese translation of MANPAGE

2023-01-05 Thread Mark Hindley
Control: tags -1 upstream

Américo,

On Wed, Jan 04, 2023 at 10:16:31PM +, Américo Monteiro wrote:
> Package: sysvinit
> Version: 3.04-1
> Tags: l10n, patch-
> Severity: wishlist
> 
> Updated Portuguese translation for  sysvinit's manpage
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> This translation was already send by me in bug 1019168 
> that was closed but my work was not added to the package
> Please include my translation

Thanks for pointing this out and please accept my apologies. It was included
upstream, but then seems to have got lost again prior to the current release.

Jesse,

I think it was added as man/pt.po and then removed again in
2354f1f73566544741a6a2594411a070e0898bfb.  Could you add it back as man/po/pt.po
again upstream?

Thanks

Mark



Bug#1025131: apt-cacher-cleanup does not work

2022-12-01 Thread Mark Hindley
Control: tags -1 pending

Robert,

Many thanks for correcting my typo and testing.

Uploading later today.

Mark



Bug#1025131: apt-cacher-cleanup does not work

2022-11-30 Thread Mark Hindley
Control: tags -1 patch

Robert,

Many thanks for pointing this out.

Does the attached patch help?

Thanks for testing.

Mark
>From cc36b2f690d694ad0cfe1b1c0ca5df7ead3e57ca Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Wed, 30 Nov 2022 11:30:21 +
Subject: [PATCH] Add encoded underscores to *_files_regexp. Test fix for
 #1025131.

---
 lib/apt-cacher.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/apt-cacher.pl b/lib/apt-cacher.pl
index 712d0bc..dad985a 100755
--- a/lib/apt-cacher.pl
+++ b/lib/apt-cacher.pl
@@ -132,7 +132,7 @@ sub read_config {
 			  qw(vmlinuz
 			 linux
 			 initrd\.gz
-			 (?:%VALID_PACKAGE_NAME%_%VALID_VERSION%[_\.])?changelog
+			 (?:%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%[_\.])?changelog
 			 NEWS\.Debian
 			 %VALID_UBUNTU_RELEASE_NAMES%\.tar\.gz(?:\.gpg)?
 			 (?:by-hash/(?i:MD5SUM/[0-9a-f]{32}|SHA1/[0-9a-f]{40}|SHA256/[0-9a-f]{64}))
@@ -141,7 +141,7 @@ sub read_config {
 			   )
 			   ) . ')$',
 		  package_files_regexp => '(?:' . join('|',
-		   qw((?:^|/)%VALID_PACKAGE_NAME%_%VALID_VERSION%(?:_%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz)
+		   qw((?:^|/)%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%(?:_|%5f)%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz)
 			  \.rpm
 			  index\.db-.+\.gz
 			  \.jigdo
-- 
2.35.1



Bug#932047: lightdm: greeter session support for elogind

2022-10-16 Thread Mark Hindley
Sam,

Thanks for this, very helpful.

I have again tested both approaches and they both work and I can find no
breakage.

On Tue, Oct 11, 2022 at 03:30:12PM -0600, Sam Hartman wrote:
> I think we want something there that allows people to get third-party
> packages into the pam config.
> If common-session isn't going to be good enough, then I guess we'd need
> to create something on the PAM side.
> But let's explore whether common-session is good enough, because it does
> look like other display managers have similar architecture and manage to
> use common-session.

Testing with @include common-session:

test@debian-sid:~$ ps -Alf|grep lightdm
4 S root   23261   1  0  80   0 - 58787 -  11:04 ?00:00:00 
/usr/sbin/lightdm
4 S root   23266   23261  2  80   0 - 80210 -  11:04 tty7 00:00:25 
/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp 
vt7 -novtswitch
4 S root   23327   23261  0  80   0 - 40649 -  11:05 ?00:00:01 
lightdm --session-child 15 26
0 S test   23435   23432  0  80   0 -  1627 -  11:18 pts/100:00:00 
grep lightdm

> Here are my thoughts on testing common-session in the greeter config:
> 
> * Take a look at how things appear in logind--does the greeter appear as
>   a session?  If so does anything break because of that?  (Withd Gnome,
>   the greeter does not appear to appear in loginctl list-sessions)

Neither for lightdm-greeter:

test@debian-sid:~$ loginctl list-sessions
SESSION  UID USER SEAT  TTY 
  1 1000 test seat0 tty1
  7 1000 test seat0 

2 sessions listed.

> * What selinux context do things appear in.  This only matters if
>   selinux is already in your testing structure

I am not sure I have quite understood this, which testing structure are you
referring to here? SElinux is not in /etc/pam.d/lightddm-greeter, only
/etc/pam.d/lightdm and /etc/pam.d/lightdm-autologin.

> * Does the structure  of keyrings look like you expect.
> 
> * Do you end up with a systemd for the greeter user (assuming you are
> using systemd).  If so, do you want one?

No

test@debian-sid:~$ ps -Alf | grep systemd
4 S root   1   0  0  80   0 - 42151 -  09:19 ?00:01:04 
/lib/systemd/systemd --system --deserialize 37
4 S message+ 342   1  0  80   0 -  2309 -  09:19 ?00:00:09 
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only
4 S root 345   1  0  80   0 -  3598 -  09:19 ?00:00:05 
/lib/systemd/systemd-logind
4 S test 437   1  0  80   0 -  3906 -  09:30 ?00:00:08 
/lib/systemd/systemd --user
4 S root6919   1  0  80   0 - 12319 -  09:43 ?00:00:16 
/lib/systemd/systemd-journald
4 S systemd+   11560   1  0  80   0 - 22504 -  10:05 ?00:00:02 
/lib/systemd/systemd-timesyncd
4 S root   11591   1  0  80   0 -  6236 -  10:05 ?00:00:06 
/lib/systemd/systemd-udevd
0 S test   23149 437  0  80   0 -  2278 -  10:54 ?00:00:00 
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only
0 S test   23439   23432  0  80   0 -  1627 -  11:18 pts/100:00:00 
grep systemd

> My suspicion is that since this appears to be working for other display
> managers, it's all fine.

It seems that way to me as well.

> But those are the areas where trouble is most likely to show up.

Thanks

Best wishes

Mark



Bug#1021819: sysvinit: Please include German man page translation

2022-10-15 Thread Mark Hindley
Helge,


On Sat, Oct 15, 2022 at 01:54:50PM +0200, Helge Kreutzmann wrote:
> Source: sysvinit
> Version: 3.05-6
> Severity: wishlist
> Tags: l10n
> 
> Hello,
> due to some problems with using git, the German man page translation
> was not present, when 3.05 was released. This has been fixed by
> upstream commit bd17b7d538393bae2126fbb0fd94bf07024850b6 on
> 2022-08-27.

Thanks for this. I was aware of the issue and was waiting for the new upstream
release.

> Pulling it in simply means copying ./man/po/de.po into man/po and
> rebuilding your package.

There are a few other issues related to dpkg-divert to address in the
maintscripts. I have commits ready to test when 3.06 is released upstream.

Best wishes

Mark



Bug#932047: lightdm: greeter session support for elogind

2022-10-09 Thread Mark Hindley
Yves-Alexis,

On Sun, Oct 09, 2022 at 01:46:56PM +0200, Yves-Alexis Perez wrote:
> for some reason it seems I never actually replied to this bug, sorry.

No worries.

> I might have replied on different bugs, but I'm not really keen on modifying
> pam files, especially for specific / non-default stuff.

Yes, I remember that from our previous discussions.

> Do you know what are the opinion of PAM people and systemd-logind people on
> that?

Added to CC:

Dear Steve and Sam as PAM maintainers,

I am wanting to add libpam-elogind support to lightdm-greeter. Currently
/etc/pam.d/lightdm-greeter hooks logind directly with

  session   optional pam_systemd.so

I have proposed two patches: either to add

 session   optional pam_elogind.so

or replace both with

 @include common-session

Yves-Alexis is understandably cautious about changing the PAM configuration.  Do
you have any thoughts, advice or comments on which might be the most 
appropriate?

Thanks

> It might be nice to have them chime in. Also not sure how this thing is
> handled on other DM, any idea?

A quick look shows most use '@include common-session'. AFAICS that is the case 
for

 gdm3: /etc/pam.d/gdm-password 
 sddm: /etc/pam.d/sddm-greeter
 xdm: /etc/pam.d/xdm
 slim: /etc/pam.d/slim (although it doesn't use logind interfaces)

AFAICS lxdm doesn't use logind at all.

HTH.

Best wishes

Mark



Bug#932047: lightdm: greeter session support for elogind

2022-10-09 Thread Mark Hindley
Hi Yves-Alexis,

With another user bumping into this issue, I am keen to have it resolved in
bookworm.

I think adding

 session   optional pam_elogind.so

to /etc/pam.d/lighdm-greeter is the best and correct fix.

I know you have been reluctant in the past, but would you consider it again.

Alternatively, I am happy to offer an NMU?

Best wishes and thanks.

Mark



Bug#1019168: sysvinit: [INTL:pt] Portuguese translation of MANPAGE

2022-09-14 Thread Mark Hindley
Control: tags -1 upstream

Américo,

On Sun, Sep 04, 2022 at 10:33:07PM +0100, Américo Monteiro wrote:
> Package: sysvinit
> Version: 3.04-1
> Tags: l10n, patch-
> Severity: wishlist

Thanks very much for this.

Forwarded upstream for inclusion.

Mark



Bug#1019661: Breaks monin and maybe other packages

2022-09-13 Thread Mark Hindley
Klaus,

On Tue, Sep 13, 2022 at 12:16:33PM +0100, Klaus Ethgen wrote:
> Package: lsb-base
> Version: 11.3
> Severity: critical
> 
> The new package breaks monin as it does not provide
> /lib/lsb/init-functions anymore.

This file has been moved to sysvinit-utils. Which version of that do you have
installed?

Mark



Bug#1019529: sysv-rc: tries to install lsb-base, but svsinit-utils replaces files

2022-09-11 Thread Mark Hindley
Samuel,

On Sun, Sep 11, 2022 at 11:05:07AM +0200, Samuel Thibault wrote:
> Package: sysv-rc
> Version: 3.05-1
> Severity: important
> Tags: patch

Thanks very much for this.

The patch seems fine to me as far as it goes. However your clear analysis
suggests to me that any debootstrap that includes a package with an lsb-base
dependency is also broken.

I will do some testing.

Mark



Bug#1019480: initscripts: wrong filename test (/etc/rc.local.shutdown) in init.d/rc.local

2022-09-10 Thread Mark Hindley
Patrice,

Thanks for spotting this typo.

I will upload a fixed version later today.

Mark



Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

2022-08-31 Thread Mark Hindley
Andreas,

On Tue Aug 30 23:05:59 2022 Andreas Beckmann  wrote:
> Followup-For: Bug #1009915
> Control: found -1 3.05-1
> 
> Hi,
> 
> there seems to be one manpage (in bootlogd) missing conflict handling:
> 
> /usr/share/man/fr/man8/bootlogd.8.gz

Thanks. I was under the impression that manpages-i10n had changed to systemd 
versions (which doesn't have bootlogd.8) but apparently not. I think  we should 
continue to use the manpages-i10n version and not have any more dpkg diversions 
than are absolutely necessary. 

I am away for a week, but will resolve this once I am back.

Mark



  1   2   3   4   5   6   7   8   >