On Mon, 15 Oct 2018, Jonathan Dowland wrote: > [ re-adding TG who requested CCs in an earlier message, but has not > set Mail-Followup-To:. You've probably missed half the conversation, > Thorsten… ]
Thanks… will follow up on those I read up on in the web interface (why is there no NNTP interface like in GMane, where I could retrieve individual messages by Message-ID to easier reply to?) below. I think we can drop d-backports now, though? > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? As a derivative I’m not sure, but I’d rather not, as a general case, unless there’s one or more of theirs who’s willing to cooperate and able to keep quality. Devuan is… questionable, when one’s used to all of Debian. > distribution, I imagine their lives would become much harder if we did > drop sysvinit; they would have to pay the cost of maintaining the Several people have said they believe that to be the end of Devuan, and I concur, from what I’ve read. > sysvinit package themselves (which is what I am proposing they do now) > *as well* as a rapidly growing delta of sysvinit-support/initscripts in Indeed. > lots of other packages, as they steadily rotted in Debian. This takes distributed manpower. Maintainers do not use all packages. Bugs are spotted by people actually using them (though, if they can be reproduced easily, can then be tackled by others). My uses are probably not very normal, though… Adam Borowski wrote: >On Mon, Oct 15, 2018 at 08:46:31AM +0200, Laurent Bigonville wrote: >> Thorsten Glaser wrote: >> > On Sun, 14 Oct 2018, Andreas Henriksson wrote: >> > >> > > Please note that sysvinit dependencies still have open RC bugs which >> > > noone is caring for. >> > >> > Oof. How do I find them out? The BTS shows no RC bugs, not even >> > ones tagged as affects src:sysvinit, and the QA page >> > https://packages.qa.debian.org/s/sysvinit.html also doesn’t. >> insserv Hmm. This does not answer the question, while it does point out one package. I’d rather sysvinit not depend on insserv, it used to work fine without that kind of added complexity, and AIUI, it was only used for parallel boots (I have /etc/init.d/.legacy-bootordering on all systems so I don’t use that anyway), and boot speed fetishists have largely migrated to systemd (which *does* boot up rather fast, even if its shutdown procedures are…). Does anyone know any offhand reason to not drop the insserv integration? >> has 3 RC bugs (6 if you count duplicates) last upload is from 2016 >> by Martin (who is/was systemd maintainer) and is RFA since around that time >> as well. > >These RC bugs are on an experimental abandoned version; the one meant for >buster is ok. Can you please RM the experimental version and close those bugs, if that version is abandoned, since you seem to know more about this? What does “meant for buster is ok” mean? It’s a bug that needs action in sid? Matthew Vernon wrote: >I'm aware of some work ongoing at the moment to try and improve matters >(currently looking at elongind, for example). If anyone's got some What’s elongind? elogind? Never heard of it… >interest/effort in getting sysvinit (and related bits) in a better state >for buster, do drop me a line. I’ve volunteered to help out earlier in the thread, within constraints (but rather that than to see things go and break). Thanks, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general