Hello, new status update.
On Wed, 01 Jul 2026 15:56:15 +0200 Johannes Schauer Marin Rodrigues <[email protected]> wrote: > Quoting Mark Hindley (2026-06-29 17:16:45) > > On Wed, Jun 10, 2026 at 04:10:57PM +0200, Johannes Schauer Marin Rodrigues > > wrote: > > > I sent a ping to > > > https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/33 > > > > > > > Depending on the response, and our analysis of it, we could change our > > > > mind > > > > about our package split; ask for mediation; ask the TC; or decide we > > > > don't > > > > want to pick a fight and do a suboptimal thing. > > > > > > Lets wait maybe a week for a reply to my ping. > > > > I see there has been no response. Next steps? Do you want to send the formal > > summary that Ian suggested? Or move straight to NMU? Or something else? > > I filed #1141215. Feel free to move the relevant bits of this discussion from > this bug to there. Two weeks after filing that bug, Mark pinged the bug with more practical examples for where the change would help making maintainer life easier. Two weeks after that mail, I sent another mail announcing an NMU of init-system-helpers with maximum delay of 15 days. Another two weeks later (August 11) the NMU got through without having been cancelled. Three days after that, since still nothing had happened, I wrote to the merge request that I will be pressing the merge button to make sure that the changes which now got uploaded to unstable as part of my NMU are not forgotten in the next maintainer upload. I also thought this was okay because init-system-helpers is in the Debian group on salsa. Unfortunately, I missed a reply by Luca Boccassi and when I read it, the merge button was already pressed. The same day, bug #1144359 got filed. On systems booting with sysvinit, my change triggered the message "Use of uninitialized value in string eq" when running update-rc.d. I filed MR 35 with a fix a day after that. The message is harmless insofar the actual behaviour is still correct, even on systems booting with sysvinit. I didn't NMU the fix because the bug is merely cosmetic. It's now again two weeks later and no other bug related to my NMU got filed against init-system-helpers. The next step is to file a bug against systemd-sysv and request it drops its conflict with insserv. To back up my request with data I created [1]. The script processes all packages shipping files in /etc/init.d/ and installs them one-by-one into a fresh chroot created with mmdebstrap in two different scenarios. In one of them, /usr/bin/insserv is present in $PATH. The resulting tarballs are then compared and the expectation is, that the system after package installation are equal independent on whether /usr/bin/insserv was present or not. I'm not really sure what problem I should be looking out for. The biggest problem is that some maintainer scripts write unreproducible data into /etc which makes comparison difficult. I also need a stronger computer because salsaci is only able to process 128 packages within the allowed 4 hours of runtime, so it only gets until console-setup-linux. [1] https://salsa.debian.org/josch/insserv-systemd-coinstall/-/blob/main/run.sh I'd also appreciate help with reviewing drafts of my bug report against systemd-sysv. If you'd like me to send you my drafts, please reply privately. Thanks! cheers, josch
signature.asc
Description: signature
