Re: Debian Buster release to partially drop non-systemd support

[Wouter Verhelst]

On Wed, Oct 24, 2018 at 11:30:17AM +0200, Marc Haber wrote:
> On Tue, 23 Oct 2018 16:43:07 +0200, Wouter Verhelst
>  wrote:
> >This has been discussed before and rejected. It makes no sense.
> 
>  technically, but a lot of sense if it helps silencing another
> instance of an "exchange standard arguments" discussion about systemd.

If we start using political arguments to make technical decisions, then
that's the end for me.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Debian Buster release to partially drop non-systemd support

[Marc Haber]

On Tue, 23 Oct 2018 16:43:07 +0200, Wouter Verhelst
 wrote:
>This has been discussed before and rejected. It makes no sense.

... technically, but a lot of sense if it helps silencing another
instance of an "exchange standard arguments" discussion about systemd.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Debian Buster release to partially drop non-systemd support

[Wouter Verhelst]

On Sat, Oct 20, 2018 at 08:22:35AM +0800, Paul Wise wrote:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
> 
> > As long as people choose to strip of dependencies to libsystemd from
> > packages like util-linux, avoiding a fork would not work with how Debian
> > and Debian based distributions are built.
> 
> It might be feasible to introduce nosystemd build profiles to Debian
> source packages

This has been discussed before and rejected. It makes no sense.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Debian Buster release to partially drop non-systemd support

[Thomas Goirand]

On 10/19/18 12:25 PM, Bastian Blank wrote:
> On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
>> So Devuan almost doubles the percentage of sysvinit-core  installations.
> 
> Devuan is _not_ Debian.  They forked it

They *claimed* it was a fork, though in reality Devuan is just yet
another Debian derivative. Let's please not use their wrong wording.

Thomas Goirand (zigo)

Re: Debian Buster release to partially drop non-systemd support

[Ian Jackson]

Ivan Shmakov writes ("Re: Debian Buster release to partially drop non-systemd 
support "):
>  Ian Jackson  writes:
>  > Please come to debian-init-divers...@chiark.greenend.org.uk.
> 
>   Do you plan to also make that list accessible via NNTP (perhaps
>   via either Gmane or the bofh.it gateway operated Marco d’Itri)?
> 
>   TIA.

I have my own mail-to-news gateway on chiark, so no, but I don't think
there is anything stopping anyone setting up either or both of those
gateways ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian Buster release to partially drop non-systemd support

[Ivan Shmakov]

> Ian Jackson  writes:
> KatolaZ writes:

 >> The problem that spurred this thread is that sysvinit needs a
 >> maintainer.  That’s why some of us are here: our intention is to
 >> help with maintaining sysvinit in Debian if possible, since we will
 >> keep maintaining it in Devuan nevertheless.

 > Thank you.  That would be awesome.

Indeed; I’m going to seize this opportunity to express my
gratitude to those who now volunteer to take care of sysvinit
and related packages in Debian!  And I’m looking forward to
contribute to the effort myself.

[…]

 > Please come to debian-init-divers...@chiark.greenend.org.uk.

Do you plan to also make that list accessible via NNTP (perhaps
via either Gmane or the bofh.it gateway operated Marco d’Itri)?

TIA.

[…]

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: Debian Buster release to partially drop non-systemd support

[Marco d'Itri]

On Oct 20, Paul Wise  wrote:

> It might be feasible to introduce nosystemd build profiles to Debian
> source packages and then create a shed/bikeshed/PPA (once that
> infrastructure exists) that contains rebuilds using that build
> profile. That would allow Devuan's libsystemd stripping to be
> completely merged into Debian source packages and infrastructure. I
No need to introduce build profiles: if somebody cares enough they can 
spend one hour to revive my libsystemd-dummy package, which I wrote 
because I did not want to use conditional build dependencies for the 
hurd/kfreebsd ports in my own packages.
It allows to rebuild any package with no source changes at all and 
remove the libsystemd dependency.
As usual, there is a lot of talking and not much code.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Andrey Rahmatullin]

On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> > Should Debian also support "noalsa", "noavahi", "nocups",
> > "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
> 
> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all
> similar in scope to systemd? If not, then this question is a strawman.
Scope? Maybe not. Hate? Some of them yes, surely.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Bastian Blank]

On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> Ansgar Burchardt  writes:
> > Should Debian also support "noalsa", "noavahi", "nocups",
> > "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all
> similar in scope to systemd? If not, then this question is a strawman.

Yes, they all completely took over their field and have a lot of haters.

Bastian

-- 
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3

Re: Debian Buster release to partially drop non-systemd support

[Arne Babenhauserheide]

Ansgar Burchardt  writes:
> Should Debian also support "noalsa", "noavahi", "nocups",
> "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",

Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all
similar in scope to systemd? If not, then this question is a strawman.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Narcis Garcia]

Does "Debian uses Systemd by default" mean "Debian is married with
Systemd forever"?

Should Debian exclude other desktop environments but Gnome, because
Gnome shell is the default one? Then drop Qt and Wx compatibility?




__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: Re: Debian Buster release to partially drop non-systemd support

[Laurent Bigonville]

Bastian Blank wrote:


On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> So Devuan almost doubles the percentage of sysvinit-core  installations.

Devuan is _not_ Debian.  They forked it, with the full knowledge that
they might have to do all the work to support their choices.  They had
the chance to not do that, contribute the proper changes back to support
their use case.  They we might have had a proper maintained sysvinit.

But instead they flip tables by even seeing systemd units or libsystemd,
which by definition does nothing in this context.  If someone comes up
with a usable systemd service to init script converter, I don't think
Debian would opt against using it to provide a service for our users.
What would they do?


Yeah well, looking at the following message, some people think that an 
init script converter is "madness":


https://lists.dyne.org/lurker/message/20181020.015531.8bef4b71.en.html

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

Paul Wise writes:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
>> As long as people choose to strip of dependencies to libsystemd from
>> packages like util-linux, avoiding a fork would not work with how Debian
>> and Debian based distributions are built.
>
> It might be feasible to introduce nosystemd build profiles to Debian
> source packages and then create a shed/bikeshed/PPA (once that
> infrastructure exists) that contains rebuilds using that build
> profile.

Why should Debian spend resources on implementing and maintaining the
changes needed for the "systemd is cancer" trip of the Devuan lead
developers?

Should Debian also support "noalsa", "noavahi", "nocups",
"nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
... profiles because there are people who do not like these projects and
would like to not see them used?

Or an "ubuntu" build profile so Ubuntu can merge all their changes
(branding, Ubuntu-specific choices, integration, ...) and would no
longer have to rebase them?

If one really cares about which shared libraries one wants to use, this
is *much* easier in source-based distributions such as Gentoo which
already have implemented this (USE flags).

See https://www.gentoo.org/support/use-flags/ for more build profiles ;-)

(The nosystemd build profile was already suggested in the past.)

> That would allow Devuan's libsystemd stripping to be
> completely merged into Debian source packages and infrastructure. I
> guess Devuan have other changes that might be easier or harder to
> merge too though.

And if we also build packages for them, they wouldn't even have to fix
their package-building infrastructure which seems to no longer work for
some time already now ;-) (A datapoint for how much interest in working
on stuff there is?)

But why spend work on implementing and, more importantly, maintaining
all of this for a derivative distribution which already had 498 active
developers(!) back in 2015 according to a presentation by Devuan
developer Alberto Zuin and Devuan founder Jaromil, and which represents
an exodus for half of the active Debian user base (according to a Devuan
lead developer in a publication in 2018)?  They certainly should have
enough resources.

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Paul Wise]

On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:

> As long as people choose to strip of dependencies to libsystemd from
> packages like util-linux, avoiding a fork would not work with how Debian
> and Debian based distributions are built.

It might be feasible to introduce nosystemd build profiles to Debian
source packages and then create a shed/bikeshed/PPA (once that
infrastructure exists) that contains rebuilds using that build
profile. That would allow Devuan's libsystemd stripping to be
completely merged into Debian source packages and infrastructure. I
guess Devuan have other changes that might be easier or harder to
merge too though.

https://wiki.debian.org/BuildProfileSpec

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Buster release to partially drop non-systemd support

[Alessandro Vesely]

On Wed 17/Oct/2018 23:06:24 +0200 Russ Allbery wrote:

>> You say "more than adequate". I don't particularly see it as providing a
>> solid system as you don't get restart on failure. Now I can see how
>> people say that this is not a problem as daemons should not crash in the
>> first place. Maybe I just value reliability of service more highly than
>> being woken up at night being told that my service is unreliable.

> My point is that sysvinit is a non-default configuration and it's
> reasonable to expect that it may be missing some features or robustness.
> If you have the time and resources to put into equaling the robustness
> that you would get under systemd, that's great, but sysvinit is much more
> of a fire-and-forget system and is known to in general not have that
> robustness property.  sysvinit users who care will run something like
> monit that watches health externally and takes appropriate action.

Given the flavor of sysvinit —an easily customizable boot process— a missing
init script may be better than a "wrong" one.  An init script can be a
no-brainer blueprint using Petter's init-d-script.  A missing init script,
which forces each user to write their own ones, would spare the hassle to check
if there's any real improvement on each package upgrade.

So here's a real advantage of systemd.  Since users who prefer spoon-feeding
use the latter, sysvinit can afford to let its users install a daemon and take
the time to grasp how it works, e.g. reading the man page /before/ running it.


Best
Ale
-- 

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Bastian Blank - 19.10.18, 12:25:
> On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> > So Devuan almost doubles the percentage of sysvinit-core 
> > installations.
> Devuan is _not_ Debian.  They forked it, with the full knowledge that
> they might have to do all the work to support their choices.  They had
> the chance to not do that, contribute the proper changes back to
> support their use case.  They we might have had a proper maintained
> sysvinit.
> 
> But instead they flip tables by even seeing systemd units or
> libsystemd, which by definition does nothing in this context.  If
> someone comes up with a usable systemd service to init script
> converter, I don't think Debian would opt against using it to provide
> a service for our users. What would they do?

As long as people choose to strip of dependencies to libsystemd from 
packages like util-linux, avoiding a fork would not work with how Debian 
and Debian based distributions are built. Devuan developers chose to do 
that and its perfectly their choice doing so. I am not at all interested 
to discuss that choice here, so in case you insist on recycling a 
discussion from the past… I let go on replying to you any further.

I also do not think that back then just shortly after all the hurting 
each other during the fierce discussion about Systemd introduction in 
Debian a cooperation would have worked out nicely. Now I see an 
opportunity for such a cooperation and Devuan developers like KatolaZ 
have offered it.

Debian has hundreds of derived distributions which co-exist peacefully 
with Debian. If for the time being Devuan is one of them, I see no issue 
what-so-ever with it.

Apart from letting go off the past, apart from letting go off old 
hurting, apart from accepting that different people decide differently 
on libsystemd and other init system related topics and from accepting 
that no one is right or wrong on this there is really nothing to see 
here.

Again: The past *is* in the past. It is not now. It is over, it is gone. 
It is just a memory. It does not exist in itself. The more you insist on 
recreating it again, the most you insist to continue to suffer. Which is 
perfectly your choice.

It is my choice to do something different instead.

-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Holger Levsen - 19.10.18, 12:02:
> On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> > A minority? Yes. But a sizable one.
> 
> It doesn't matter how many people use it, if noone is willing to
> maintain it. *If* people are maintaining it, it also doesnt matter
> how many people are using it :)
> 
> *Someone* needs to do the work. We are all volunteers. Be the change
> you want to see in the world.

Thanks. Doing just that already in a way I currently can.

People are already working on it. They do not discuss this on this list, 
but on the debian-init-diversity list that has been announced in this 
thread.

I am not helping as a developer at the moment, but I helped quite a bit 
with bringing people together and collecting information as I navigate 
in both communities (Debian and Devuan). KatolaZ already works on 
examing the current status and coming up with a plan, including updating 
to latest upstream release of sysvinit. Also there is coordination work 
on elogind. It is already packaged in Devuan, but there has been work 
for having it packaged in Debian as well.

Obviously there won't be new package releases tomorrow. So it is good to 
allow it to take some time, also for involved Debian and Devuan 
developers to learn to know and trust each other and agree on a work 
flow.

Hopefully this is the start of a long-overdue healing process.

What happens if we stop the flame war, if we stop hurting each other and 
start accepting that many use Systemd, some use something different and 
the world is big enough for both groups? And what happens when it is not 
even about which is right and which is wrong, what happens by just 
accepting that both are *different*?

Also to me sysvinit is not an end in itself, even tough it has some 
priority right now to get the package maintained again. I quite like 
runit for example.

-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Bastian Blank]

On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> So Devuan almost doubles the percentage of sysvinit-core  installations.

Devuan is _not_ Debian.  They forked it, with the full knowledge that
they might have to do all the work to support their choices.  They had
the chance to not do that, contribute the proper changes back to support
their use case.  They we might have had a proper maintained sysvinit.

But instead they flip tables by even seeing systemd units or libsystemd,
which by definition does nothing in this context.  If someone comes up
with a usable systemd service to init script converter, I don't think
Debian would opt against using it to provide a service for our users.
What would they do?

> A minority? Yes. But a sizable one.

In Debian it's a 1.5% minority.  It does not yet reach the point at
which for example the whole web oekosystem forcefully cuts support.  But
support is questionable.

Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Fri, 2018-10-19 at 11:35 +0200, Martin Steigerwald wrote:
> Martin Steigerwald - 19.10.18, 10:57:
> > That written, I estimate or guess that the people preferring to use
> > another initialization system than the initialization system in
> > Systemd are in the minority. Yet, this minority might be larger
> > than
> > you think. Especially as popularity contest does not count the ones
> > who switched over to Devuan:
> […]
> 
> Okay, let's add some numbers:
> 
> Debian and all the other Debian derived distributions:
> - 3109 (=1,55%) installations of sysvinit-core
> - 2031 (=1,01%) installations of runit -68 runit-systemd -6 of runit-
> sysv (counted above already)
> - 110 (=0,05) installations of openrc, but it works on top of
> sysvinit
> - https://qa.debian.org/popcon.php?package=sysvinit (and so on)

I think you forgot Ubuntu as a Debian-derived distribution...  If you
already include extra data, one shouldn't neglect that one.

> Devuan:
> - 2578 installations of sysvinit-core (and I just added two more by 
> installing popularity-contest on my Devuan based server VMs)
> - 27 installations of runit
> - 141 installations of openrc, installations of openrc, but it works
> on 
> top of sysvinit
> - http://popcon.devuan.org/tmp-www/by_inst.html
> 
> So Devuan almost doubles the percentage of sysvinit-
> core  installations.

And Ubuntu probably reduces it again by more than that.

Statistics are fun :-)

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Holger Levsen]

On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> A minority? Yes. But a sizable one.
 
It doesn't matter how many people use it, if noone is willing to maintain
it. *If* people are maintaining it, it also doesnt matter how many people
are using it :)

*Someone* needs to do the work. We are all volunteers. Be the change you
want to see in the world. 


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Martin Steigerwald - 19.10.18, 10:57:
> That written, I estimate or guess that the people preferring to use
> another initialization system than the initialization system in
> Systemd are in the minority. Yet, this minority might be larger than
> you think. Especially as popularity contest does not count the ones
> who switched over to Devuan:
[…]

Okay, let's add some numbers:

Debian and all the other Debian derived distributions:
- 3109 (=1,55%) installations of sysvinit-core
- 2031 (=1,01%) installations of runit -68 runit-systemd -6 of runit-
sysv (counted above already)
- 110 (=0,05) installations of openrc, but it works on top of sysvinit
- https://qa.debian.org/popcon.php?package=sysvinit (and so on)

Devuan:
- 2578 installations of sysvinit-core (and I just added two more by 
installing popularity-contest on my Devuan based server VMs)
- 27 installations of runit
- 141 installations of openrc, installations of openrc, but it works on 
top of sysvinit
- http://popcon.devuan.org/tmp-www/by_inst.html

So Devuan almost doubles the percentage of sysvinit-core  installations.

A minority? Yes. But a sizable one.

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

El 19/10/18 a les 09:37, Philipp Kern ha escrit:
> On 2018-10-19 08:39, Narcis Garcia wrote:
>> El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
>>> For my packages I can state that I do not have a single machine which is
>>> not using systemd - and to be honest - I won't waste my time in
>>> writing/debugging initscripts.
>> Most of people want to use a GNU operating system.
>> You particularly seem to only need a Systemd operating system.
> 
> So what you want is https://www.gnu.org/software/shepherd/?
> 
> Kind regards
> Philipp Kern
> 

What I want is not necessarily GNU Paint, Gnumeric or Gnuzilla.
What I want is a GNU operating system, and this can be as GNU+Linux,
GNU+Hurd or any other but, for example, Android that is not a GNU
operating system.
And Systemd is moving operating systems far from GNU while it's
deploying more and more of the OS functions.

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

dropping debian-hurd

Bernd Zeimetz - 18.10.18, 22:07:
> - the typical package maintainer won't test initscripts

I am not typical then.

> After using a lot of systemd now I will never go back to init scripts.
> Systemd comes with a steep learning curve, but one you've stated
> using its features you'll never go back.

Obviously I am not the "you" you mean here. I learned quite a lot about 
Systemd as I integrated it in my Linux training slides. I even like 
quite some of the features.

Still two of my server VMs are running Devuan already – one with 
sysvinit and another one with OpenRC – and I am pondering to switch over 
this laptop too. And the one running Debian also runs sysvinit.

I think it is helpful to mainly speak of oneself here instead of 
claiming what (apparent) others may like or do.


That written, I estimate or guess that the people preferring to use 
another initialization system than the initialization system in Systemd 
are in the minority. Yet, this minority might be larger than you think. 
Especially as popularity contest does not count the ones who switched 
over to Devuan:

% apt show popularity-contest
[…]
Description: Vote for your favourite packages automatically
 The popularity-contest package sets up a cron job that will
 periodically anonymously submit to the Devuan developers
 statistics about the most used packages on this system.
[…]

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Svante Signell]

On Fri, 2018-10-19 at 09:37 +0200, Philipp Kern wrote:
> On 2018-10-19 08:39, Narcis Garcia wrote:
> > El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
> > > For my packages I can state that I do not have a single machine
> > > which is not using systemd - and to be honest - I won't waste my
> > > time in writing/debugging initscripts.
> > 
> > Most of people want to use a GNU operating system.
> > You particularly seem to only need a Systemd operating system.
> 
> So what you want is https://www.gnu.org/software/shepherd/?

Yes please, is it packaged for Debian already? As Debian is/was the
Universal Operating System?

GNU shepherd or OpenRC (Was: Debian Buster release to partially drop non-systemd support)

[Ondřej Surý]

That’s interesting though - could we use GNU shepherd to:

a) support kFreeBSD?
b) automatically translate systemd units to sheep(?) (limited subset might work)

The other alternative is OpenRC - here’s the same question - could we have 
systemd units as authoritative definition and have OpenRC translate services, 
tmpfiles and perhaps even systemd users to its native format?

Ondrej
--
Ondřej Surý 

> On 19 Oct 2018, at 09:37, Philipp Kern  wrote:
> 
> So what you want is https://www.gnu.org/software/shepherd/?

Re: Debian Buster release to partially drop non-systemd support

[Philipp Kern]

On 2018-10-19 08:39, Narcis Garcia wrote:

El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
For my packages I can state that I do not have a single machine which 
is

not using systemd - and to be honest - I won't waste my time in
writing/debugging initscripts.

Most of people want to use a GNU operating system.
You particularly seem to only need a Systemd operating system.


So what you want is https://www.gnu.org/software/shepherd/?

Kind regards
Philipp Kern

Re: Debian Buster release to partially drop non-systemd support

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
> For my packages I can state that I do not have a single machine which is
> not using systemd - and to be honest - I won't waste my time in
> writing/debugging initscripts.

Most of people want to use a GNU operating system.
You particularly seem to only need a Systemd operating system.

Re: Debian Buster release to partially drop non-systemd support

[Bernd Zeimetz]

On 10/13/18 12:58 PM, Holger Levsen wrote:
> On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
>>> Has policy changed regarding support for multiple inits, or is it just that
>>> no one is maintaining the shim and sysvinit-core?
>>
>> The latter.  systemd-shim has been orphaned for over 2 years, and has
>> RC bugs.   sysvinit currently has two maintainers, but they've only
>> ever made one upload (over a year ago).
> 
> It seems that these facts are either largely ignored or unknown and I
> wonder if some noise should be made so that interested people can pick
> up the work now and not only complain later.


I don't think that is only the smaller issue we are facing here. The
bigger "problems" for those who do not like systemd will be:

- the typical package maintainer won't test initscripts
- more and more upstreams are shipping systemd services only and skip
init script creation.

For my packages I can state that I do not have a single machine which is
not using systemd - and to be honest - I won't waste my time in
writing/debugging initscripts. If there is one, I'll review it if it
looks sane and then maybe ship it. And I'm saying "maybe" here, as for
new packages, I will NOT shit it as active init script because I will
only put stuff in my packages I have tested well enough.

After using a lot of systemd now I will never go back to init scripts.
Systemd comes with a steep learning curve, but one you've stated using
its features you'll never go back.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: Debian Buster release to partially drop non-systemd support

[Felipe Sateler]

On Thu, 18 Oct 2018 06:58:14 +0100, Jonathan Dowland wrote:

> On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote:
>>MAILTO was the main thing that I remember missing in terms of pure
>>functionality.
> 
> This is not a complete substitute for all uses of MAILTO, but I found
> the following useful so I share it in case you weren't aware of it.
> 
> Define a service specifically designed for sending status emails:
> 
> status-email-user@.service:
>> [Service]
>> Type=oneshot
>> ExecStart=-/usr/local/bin/systemd-email %i 
>> User=nobody
>> Group=systemd-journal

`nobody` is not a particularly good user to use for this. Should you have 
any non-mappable uids (like user namespaces or some nfs configurations), 
they will appear owned by `nobody`. You should probably use instead:

DynamicUser=yes
SupplementaryGroups=systemd-journal


-- 
Saludos

Re: OpenRC is there (was: Debian Buster release to partially drop non-systemd support)

[Thomas Goirand]

On 10/13/18 12:58 PM, Holger Levsen wrote:
> On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
>>> Has policy changed regarding support for multiple inits, or is it just that
>>> no one is maintaining the shim and sysvinit-core?
>>
>> The latter.  systemd-shim has been orphaned for over 2 years, and has
>> RC bugs.   sysvinit currently has two maintainers, but they've only
>> ever made one upload (over a year ago).
> 
> It seems that these facts are either largely ignored or unknown and I
> wonder if some noise should be made so that interested people can pick
> up the work now and not only complain later.

Please also consider that OpenRC is in Debian, and well maintained.
OpenRC is a very good alternative to sysv-rc, and it supports old-style
sysv-rc init scripts (with LSB headers).

Cheers,

Thomas Goirand (zigo)

Re: Debian Buster release to partially drop non-systemd support

[Kamil Jońca]

Jonathan Dowland  writes:

> On Thu, Oct 18, 2018 at 09:09:38AM +0100, Jonathan Dowland wrote:
>>Thanks for passing that along: I'm using it with Exim and haven't
>>noticed this particular problem, but it's useful to know it could
>>happen.
>
> Ah, because I have User=nobody, and so the systemd sub-process can't
> reap the privileged exim4 sub-process.
This is irrelevant.
Only processes spawned from "--user"  units are safe.
Processes spawned from system units are killed regardless of 'User="
stanza. (I observed this on units with "User=news")
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Every creature has within him the wild, uncontrollable urge to punt.
-- Snoopy

Re: Debian Buster release to partially drop non-systemd support

[Kamil Jońca]

Adam Borowski  writes:

[..]
>
> Ouch.  This is downright terrifying.  It should be quite obvious why things
> other than exim can break when called from there.
>
> And there's no good way for a random tool you may use to know it might get
> suddenly SIGKILLed out of the blue.

The only workaround I found is to put in such 'oneshot' units

KillMode=none

just in case ...

I filled bug against systemd
https://github.com/systemd/systemd/issues/10299 but I do not know if I
am right.

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
I cannot believe that God plays dice with the cosmos.
-- Albert Einstein, on the randomness of quantum mechanics

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Thu, Oct 18, 2018 at 09:09:38AM +0100, Jonathan Dowland wrote:

Thanks for passing that along: I'm using it with Exim and haven't
noticed this particular problem, but it's useful to know it could
happen.


Ah, because I have User=nobody, and so the systemd sub-process can't
reap the privileged exim4 sub-process.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Thu, Oct 18, 2018 at 08:46:10AM +0200, Kamil Jońca wrote:
> > Put an OnFailure= line in systemd units that you want to mail you if
> > they go wrong
> >
> >> [Unit]
> >> OnFailure=status-email-user@%n.service
> 
> But this not play well with exim4.
> See:
> https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html
> (and thread as a whole)

Ouch.  This is downright terrifying.  It should be quite obvious why things
other than exim can break when called from there.

And there's no good way for a random tool you may use to know it might get
suddenly SIGKILLed out of the blue.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Thu, Oct 18, 2018 at 08:46:10AM +0200, Kamil Jońca wrote:

But this not play well with exim4.
See:
https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html
(and thread as a whole)


Thanks for passing that along: I'm using it with Exim and haven't
noticed this particular problem, but it's useful to know it could
happen.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Kamil Jońca]

Jonathan Dowland  writes:

> On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote:
>>MAILTO was the main thing that I remember missing in terms of pure
>>functionality.
>
> This is not a complete substitute for all uses of MAILTO, but I found
> the following useful so I share it in case you weren't aware of it.
>
> Define a service specifically designed for sending status emails:
>
> status-email-user@.service:
>> [Service]
>> Type=oneshot
>> ExecStart=-/usr/local/bin/systemd-email %i
>> User=nobody
>> Group=systemd-journal
>
> (I also switch on a little status LED I have with another ExecStart
> line)
>
> /usr/local/bin/systemd-email:
>> systemctl status --full "$1" | mail -s "unit $1 failed" root
>
> Put an OnFailure= line in systemd units that you want to mail you if
> they go wrong
>
>> [Unit]
>> OnFailure=status-email-user@%n.service

But this not play well with exim4.
See:
https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html
(and thread as a whole)
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Disks travel in packs.

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote:

MAILTO was the main thing that I remember missing in terms of pure
functionality.


This is not a complete substitute for all uses of MAILTO, but I found
the following useful so I share it in case you weren't aware of it.

Define a service specifically designed for sending status emails:

status-email-user@.service:

[Service]
Type=oneshot
ExecStart=-/usr/local/bin/systemd-email %i
User=nobody
Group=systemd-journal


(I also switch on a little status LED I have with another ExecStart
line)

/usr/local/bin/systemd-email:

systemctl status --full "$1" | mail -s "unit $1 failed" root


Put an OnFailure= line in systemd units that you want to mail you if
they go wrong


[Unit]
OnFailure=status-email-user@%n.service


I think I probably got this from the Arch wiki and it suffers many of
the problems you outlined in your follow-on paragraph (needing a
separate unit, to the timer, an external shell script, etc.)

Since I switched to this, I've made the scripts I run on timers much
more verbose in the non-failure case, because I know I am not going
to generate mail. And this has turned out to be a good habit, because
I have a lot of useful information in my journal.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Russ Allbery]

Paul Wise  writes:
> On Thu, Oct 18, 2018 at 5:24 AM Russ Allbery wrote:

>> Timer units are also a more complicated problem since they're not a
>> superset of cron behavior.  They do some things better than cron jobs;
>> they do other things much *worse* than cron jobs.  I have cron jobs
>> that I wanted to convert to timer units and discovered I couldn't
>> because timers simply wouldn't work for what I was trying to do.

> Could you give some examples of the issues you discovered with systemd
> timers?

> BTW, we have in systemd-cron a tool for generating systemd units from
> crontab/etc.

MAILTO was the main thing that I remember missing in terms of pure
functionality.

The other problem I can recall wasn't functionality, but was ease of use:
a timer unit can only trigger a service unit, and service units aren't
suitable for doing arbitrary shell scripting.  Here, this wasn't for
packaging but was instead as a local system administrator.  I have a lot
of cases where I drop a simple 20-line shell script into /etc/cron.daily
that has some logic intermixed with variables that list things like, say,
directories to back up to another host.  I looked at replacing that with a
timer unit, just as an experiment, but I would have had to write the timer
unit to control the timing, a separate exec unit that specifies what
command to run, and then put the shell script into yet a third file (with
no particularly obvious location for the local system administrator).
Since I don't like using /usr/local/bin for such things, I'd probably end
up extracting configuration from the script, sticking the script in a
local Debian package, and installing the configuration separately.  I now
have four different files just to replace a single file dropped into a
directory.

Admittedly, this was to replace something run from cron.daily, and maybe
the solution there (if one is considering a system that doesn't need a
separate cron daemon, which in theory should be possible if one wanted to
do it although not necessary of course) would be to have a single timer
unit that uses run-parts the way that cron runs cron.daily.  Timer units
were a closer match for cron.d, although I'm still missing MAILTO.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian Buster release to partially drop non-systemd support

[Paul Wise]

On Thu, Oct 18, 2018 at 5:24 AM Russ Allbery wrote:

> Timer units are also a more complicated problem since they're not a
> superset of cron behavior.  They do some things better than cron jobs;
> they do other things much *worse* than cron jobs.  I have cron jobs that I
> wanted to convert to timer units and discovered I couldn't because timers
> simply wouldn't work for what I was trying to do.

Could you give some examples of the issues you discovered with systemd timers?

BTW, we have in systemd-cron a tool for generating systemd units from
crontab/etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Buster release to partially drop non-systemd support

[Russ Allbery]

Philipp Kern  writes:
> On 17.10.2018 06:52, Russ Allbery wrote:

>> I think a package of a daemon that does not inherently require any
>> systemd-specific features and would work straightforwardly with
>> sysvinit, but has only a systemd unit file and no init script, is not
>> only buggy but RC-buggy.  That's what Policy currently says.

> And it would not be buggy if it does not ship any init integration or
> relies on a non-init service supervision system like runit. (The crux
> being that systemd is not modular to be run that way and not portable.)

No, I think that's also buggy.  If it's a daemon that should be started at
boot and it doesn't include init integration, I think that's an obvious
bug.  It's very hard to write a Policy rule that says this, since it's
more of a common sense sort of bug.

> You say "more than adequate". I don't particularly see it as providing a
> solid system as you don't get restart on failure. Now I can see how
> people say that this is not a problem as daemons should not crash in the
> first place. Maybe I just value reliability of service more highly than
> being woken up at night being told that my service is unreliable.

My point is that sysvinit is a non-default configuration and it's
reasonable to expect that it may be missing some features or robustness.
If you have the time and resources to put into equaling the robustness
that you would get under systemd, that's great, but sysvinit is much more
of a fire-and-forget system and is known to in general not have that
robustness property.  sysvinit users who care will run something like
monit that watches health externally and takes appropriate action.

I think every packager owes it to the social fabric of the project to make
the effort to provide a basic init script, in the same way that we do
basic porting to other architectures and investigate build failures.
There is some point, which is subjective, beyond which I think it's
reasonable to ask someone who cares about sysvinit to do more complicated
work, but I think a basic init script tested under systemd's init support
is a reasonable request.

My personal concern is more about the social community of the project than
about the technical details.  I consider providing an init script even if
I don't personally use sysvinit to be extending the hand of community and
solidarity to other Debian community members who use it.  To say to them
that their concerns have been heard and supported, even if I don't agree
with their concerns.  Personally, I find that extremely important, a
principle that's as important as the technical quality bar we try to reach
in our packages.

> Is a possible answer here to ship an init script and then provide
> additional supervision options using override files - to enhance
> whatever is provided by the sysv generator?

I personally would tend to maintain separate init and systemd unit files
and only lightly test the init script unless I knew there was something
tricky going on, but this answer varies based on the complexity of the
daemon.

> This statement also does not address a daemon that only runs through
> socket activation - passing an fd to the daemon. But I don't have any
> example handy and this might be a strawman argument. Except that I could
> see that for simplicity newer daemons might be written in this way as it
> does cut a significant amount of socket handling code.

Yes, at the point where we have an upstream daemon that was written
explicitly for use with systemd in that fashion, I think that turns into a
different sort of question.  This is now more akin to porting, and that's
a different bar.  I don't think we can place hard requirements on what a
maintainer chooses to do here, other than asking for them to take patches
from porters if those are offered.

> To some degree I regret that we cannot provide a fully integrated
> distribution by mandating that the core layers (be it kernels or init
> systems) can be switched out. systemd still supports init scripts but on
> the other side there's pretty much complete stagnation with the onus on
> the systemd maintainers to keep things working. There could as well have
> been an effort to support a subset of the unit language for sysvinit.

I do completely agree with the general thrust of this thread: sysvinit
needs an active maintenance team, and without that work, it will
eventually die.  There's a limit to how much people who don't use it
should feel obligated to keep it working.  Hopefully those who do use it
will be able to find the resources to support and improve it (and indeed
being able to support the unit *syntax* would be a huge step towards
making sysvinit support in Debian more robust).

> I suppose one answer would be a cron generator. Given that policy
> specifies naming schemes for /etc/cron.{hourly,daily,weekly,monthly,d},
> there could probably be a mapping from filename to timer. But the cron
> language itself does not contain identifiers, so there's 

Re: Debian Buster release to partially drop non-systemd support

[Philipp Kern]

On 17.10.2018 06:52, Russ Allbery wrote:
> I think a package of a daemon that does not inherently require any
> systemd-specific features and would work straightforwardly with sysvinit,
> but has only a systemd unit file and no init script, is not only buggy but
> RC-buggy.  That's what Policy currently says.

And it would not be buggy if it does not ship any init integration or
relies on a non-init service supervision system like runit. (The crux
being that systemd is not modular to be run that way and not portable.)

> It is quite easy to write a sysvinit init script for most daemons that
> will basically work.  I don't think the maintainer is obligated to do much
> more than that (for instance, I don't think you need to try to duplicate
> systemd hardening configuration or other features that are quite
> challenging to do under sysvinit without more tool support, although some
> of that may be coming in start-stop-daemon).
> 
> I don't think it's reasonable to expect every Debian maintainer to have a
> system booted into sysvinit to test the init script, since that can be
> quite an undertaking if one isn't using sysvinit normally, but thankfully
> you don't need to do that to test the init script.  Just delete the unit
> file and then test the init script with systemd.  For nearly all daemons
> that don't involve tight system integration, this will be more than
> adequate.

You say "more than adequate". I don't particularly see it as providing a
solid system as you don't get restart on failure. Now I can see how
people say that this is not a problem as daemons should not crash in the
first place. Maybe I just value reliability of service more highly than
being woken up at night being told that my service is unreliable.

Is a possible answer here to ship an init script and then provide
additional supervision options using override files - to enhance
whatever is provided by the sysv generator?

This statement also does not address a daemon that only runs through
socket activation - passing an fd to the daemon. But I don't have any
example handy and this might be a strawman argument. Except that I could
see that for simplicity newer daemons might be written in this way as it
does cut a significant amount of socket handling code.

To some degree I regret that we cannot provide a fully integrated
distribution by mandating that the core layers (be it kernels or init
systems) can be switched out. systemd still supports init scripts but on
the other side there's pretty much complete stagnation with the onus on
the systemd maintainers to keep things working. There could as well have
been an effort to support a subset of the unit language for sysvinit.

That said, I'm grateful for Petter pointing out /lib/init/init-d-script
and I need to investigate that as an alternative to write a full blown
shell script with logic that needs to be updated everywhere when there
are changes.

> If you want to do more than the minimum and try to replicate more unit
> file features in the init script, that's great, but I think it's also
> reasonable to not do so and wait for sysvinit users to file bugs.  But I
> do think it's a key and important part of our general project-wide
> compromise that maintainers of packages that include daemons continue to
> do the reasonable minimum to keep those daemons basically working with
> other init systems, until such time as the project as a whole decides that
> sysvinit support should not be maintained.

I guess this thread will show if people other than the systemd folks
actually step up to maintain this support. But I'm more worried about
the externalized cost to the maintainers to contribute work to keep this
working if the user base is minimal. That said, I guess 1.55% of the
popcon base having sysvinit-core installed aka 3k users is way more than
some of the ports have. (Although I actually see the Linux ones as less
of a burden than switching out and supporting multiple core components.)

>> It'd need to run much more often (every 15 minutes). So cron.daily
>> wouldn't fit. For the sake of the argument it'd need to be a shell
>> script that checks multiple conditions (see [1]). And we currently don't
>> have timer/cron deduplication, unfortunately. That means it'd also need
>> to disable itself on systemd systems (but of course cron would still
>> invoke the script periodically). Similarly - as a more general remark -
>> having it as a cronjob doesn't let you monitor it in quite the same way.
> 
> I think we should solve the problem of timer/cron de-duplication before
> opening the door to timer units.  I agree that timer units would be a very
> valuable addition to a lot of packages, but timer/cron de-duplication
> feels like an entirely tractable problem that's useful to resolve in its
> own right.  Maybe we can just do that?

I suppose one answer would be a cron generator. Given that policy
specifies naming schemes for /etc/cron.{hourly,daily,weekly,monthly,d},
there could 

Re: Debian Buster release to partially drop non-systemd support

[Russ Allbery]

Philipp Kern  writes:

> I don't understand. If I submit a merge request to the maintainer, it's
> on me to test what I submit actually works. So if I add stuff for a
> completely different init system I have to test it. The question is: Is
> the package buggy if it does not contain an init script but a systemd
> unit and it seems to be the case. Note that there are a *lot* of useful
> options in a systemd unit that would need emulation to make properly
> work with sysvinit.

I think a package of a daemon that does not inherently require any
systemd-specific features and would work straightforwardly with sysvinit,
but has only a systemd unit file and no init script, is not only buggy but
RC-buggy.  That's what Policy currently says.

It is quite easy to write a sysvinit init script for most daemons that
will basically work.  I don't think the maintainer is obligated to do much
more than that (for instance, I don't think you need to try to duplicate
systemd hardening configuration or other features that are quite
challenging to do under sysvinit without more tool support, although some
of that may be coming in start-stop-daemon).

I don't think it's reasonable to expect every Debian maintainer to have a
system booted into sysvinit to test the init script, since that can be
quite an undertaking if one isn't using sysvinit normally, but thankfully
you don't need to do that to test the init script.  Just delete the unit
file and then test the init script with systemd.  For nearly all daemons
that don't involve tight system integration, this will be more than
adequate.

If you want to do more than the minimum and try to replicate more unit
file features in the init script, that's great, but I think it's also
reasonable to not do so and wait for sysvinit users to file bugs.  But I
do think it's a key and important part of our general project-wide
compromise that maintainers of packages that include daemons continue to
do the reasonable minimum to keep those daemons basically working with
other init systems, until such time as the project as a whole decides that
sysvinit support should not be maintained.

> It'd need to run much more often (every 15 minutes). So cron.daily
> wouldn't fit. For the sake of the argument it'd need to be a shell
> script that checks multiple conditions (see [1]). And we currently don't
> have timer/cron deduplication, unfortunately. That means it'd also need
> to disable itself on systemd systems (but of course cron would still
> invoke the script periodically). Similarly - as a more general remark -
> having it as a cronjob doesn't let you monitor it in quite the same way.

I think we should solve the problem of timer/cron de-duplication before
opening the door to timer units.  I agree that timer units would be a very
valuable addition to a lot of packages, but timer/cron de-duplication
feels like an entirely tractable problem that's useful to resolve in its
own right.  Maybe we can just do that?

-- 
Russ Allbery (r...@debian.org)   

Re: Debian Buster release to partially drop non-systemd support

[Benda Xu]

Hi Petter,
(Dropping backports)

Petter Reinholdtsen  writes:

>> 1. systemd-shim is not necessary, even for DEs (except GNOME3).
>> 2. sysvinit-core is very stable and do not need new uploads.
>
> Thank you for expressing so well the cause of the fate for sysvinit in
> Debian.  It seem clear its proponents believe everything is OK and no
> effort is needed to save sysvinit.  If this continues, sysvinit in
> Debian will continue to rot and end up being removed.
>
> I know from maintaining the sysvinit set of packages that it require
> work to maintain them.  There are hundreds of open bugs against the
> sysvinit packages in Debian already.

Thank you for all your work on sysvinit, especially insserv.

Please note that I said only *sysvinit-core* the pid 1 ELF is stable.
No worries, we will not let it be and disappear by itself.

My plan is to do something to please those who want to kill sysvinit by
keeping it in a "healthy" state, althrough only cosmetic changes are
needed.

Cheers,
Benda

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Michael Biebl - 16.10.18, 22:08:
> Am 16.10.18 um 21:36 schrieb Adam Borowski:
> > Systemd's algorithm for btrfs RAID is:
> So your complaint is specific to btrfs RAID which afaik is still
> considered unstable?

Certain BTRFS RAID like RAID 1 and RAID 10 levels are considered stable 
by upstream developers since quite a while:

https://btrfs.wiki.kernel.org/index.php/Status

I am using BTRFS RAID 1 without any major issues since years on this 
ThinkPad T520 (together with a work-around for initramfs¹).


[1] Bug: hack for installing with btrfs raid1
Subject of my post: still not booting from BTRFS RAID 1 on two LVs out 
of the box
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686130#33

(I know that the initramfs issue is not Systemd related.)

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Tue, Oct 16, 2018 at 10:08:59PM +0200, Michael Biebl wrote:
> Am 16.10.18 um 21:36 schrieb Adam Borowski:
> > Systemd's algorithm for btrfs RAID is:
> 
> So your complaint is specific to btrfs RAID which afaik is still
> considered unstable?

Care to specify what's unstable with btrfs RAID?  Any non-experimental level
(experimental include 5/6, 3-way mirroring, etc) has no known stability
issues; what's left are missing optimizations or features that'd be nice to
have.

But Ian is right -- this has turned into advocacy again; I'd be happy to
discuss filesystem issues with you privately or on linux-btrfs if you wish.

My point earlier in this subthread was that mounting RAIDs doesn't fit well
within systemd's event scheme and would require at least some rethinking --
even using static ordering would work better.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Michael Biebl]

Am 16.10.18 um 22:24 schrieb Ian Jackson:
> Is this advocacy subthread really useful ?  If we have bugs to report
> in systemd stuff we should report them in the BTS, not debate them on
> debian-devel.
> 
> Adam Borowski writes ("Re: Debian Buster release to partially drop 
> non-systemd support"):
>> On Tue, Oct 16, 2018 at 08:38:06PM +0200, Bastian Blank wrote:
>>> But in the case of degraded RAID the system _is_ already broken.  How
>>> does a non-event-driven solution work for it?
>>
>> 1. MD timeouts then proceeds
>> 2. btrfs stops unless -odegraded is given
> 
> But, I did want to provide a data point here.

So much for advocacy...


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Debian Buster release to partially drop non-systemd support

[Ian Jackson]

Is this advocacy subthread really useful ?  If we have bugs to report
in systemd stuff we should report them in the BTS, not debate them on
debian-devel.

Adam Borowski writes ("Re: Debian Buster release to partially drop non-systemd 
support"):
> On Tue, Oct 16, 2018 at 08:38:06PM +0200, Bastian Blank wrote:
> > But in the case of degraded RAID the system _is_ already broken.  How
> > does a non-event-driven solution work for it?
> 
> 1. MD timeouts then proceeds
> 2. btrfs stops unless -odegraded is given

But, I did want to provide a data point here.

chiark runs sysvinit and recently had a disk failure.  This all worked
as I expected (apart from that I encountered a bug in mdadm related to
the write-mostly flag).  I deliberately pass --no-degraded but I have
no doubt that if I hadn't it would have just booted with the remaining
working disk.

Ian.

Re: Debian Buster release to partially drop non-systemd support

[Michael Biebl]

Am 16.10.18 um 21:36 schrieb Adam Borowski:
> Systemd's algorithm for btrfs RAID is:

So your complaint is specific to btrfs RAID which afaik is still
considered unstable?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Tue, Oct 16, 2018 at 08:38:06PM +0200, Bastian Blank wrote:
> On Tue, Oct 16, 2018 at 07:20:24PM +0200, Adam Borowski wrote:
> > On Tue, Oct 16, 2018 at 05:54:34PM +0200, Petter Reinholdtsen wrote:
> > > Absolutely.  And the sysvinit boot system have lots of unsolved problems
> > > we never got around to figuring out, related to disk and other device
> > > setup.  The main cause is the fact that the linux kernel is no longer
> > > predicatble and sequencial, but asynchonous.  No amount of wishful
> > > thinking is going to bring is back to a world where static sequencing of
> > > boot events is going to handle all the interdependencies.
> > Systemd fails to solve them as well -- while introducing a lot of unsolved
> > problems on its own, such as degraded RAID problems (no, it's not possible
> > do to that in an event-driven way, you need a static sequence in at least
> > some cases).
> 
> But in the case of degraded RAID the system _is_ already broken.  How
> does a non-event-driven solution work for it?

1. MD timeouts then proceeds
2. btrfs stops unless -odegraded is given

Neither works if systemd is managing mounting, both work with mountall.

As I don't use systemd my data about MD+systemd might be stale, but judging
from a recent flamewar on linux-btrfs, this is still fundamentally broken
on systemd.

Systemd's algorithm for btrfs RAID is:
* take the device named in fstab (one of RAID parts)
* wait for it, query for fsid and number of devices it knows about
* endlessly wait until that number of devices with the given fsid pop up
* if the filesystem gets mounted by the user anyway, unmount it (?!?)

That's neither required nor sufficient to successfully mount.  In slightly
convoluted (but not entirely unrealistic) scenarios the mount might even
succeed non-degraded!  (The first device might have a stale idea about the
filesystem's layout, that's ok.)  In general, there's no way to know if a
mount will succeed other than to actually try it (and at most back off at
the last moment).  You need to read the chunk tree to know if you have
enough data to proceed: a non-degraded mount needs all replicas of every
block group, a degraded mount needs enough to recover the data -- which is
not the same as "X devices are present".

Thus, instead of trying to be smarter than the kernel, it's better to
request the mount and let the kernel do the job.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Bastian Blank]

On Tue, Oct 16, 2018 at 07:20:24PM +0200, Adam Borowski wrote:
> On Tue, Oct 16, 2018 at 05:54:34PM +0200, Petter Reinholdtsen wrote:
> > Absolutely.  And the sysvinit boot system have lots of unsolved problems
> > we never got around to figuring out, related to disk and other device
> > setup.  The main cause is the fact that the linux kernel is no longer
> > predicatble and sequencial, but asynchonous.  No amount of wishful
> > thinking is going to bring is back to a world where static sequencing of
> > boot events is going to handle all the interdependencies.
> Systemd fails to solve them as well -- while introducing a lot of unsolved
> problems on its own, such as degraded RAID problems (no, it's not possible
> do to that in an event-driven way, you need a static sequence in at least
> some cases).

But in the case of degraded RAID the system _is_ already broken.  How
does a non-event-driven solution work for it?

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Tue, Oct 16, 2018 at 05:54:34PM +0200, Petter Reinholdtsen wrote:
> > SysV init leaves all the really hard problems to these, as it cannot
> > really do much by itself. That's a fact that people that keep yelling
> > "but SysV init was so easy!" keep finessing..
> 
> Absolutely.  And the sysvinit boot system have lots of unsolved problems
> we never got around to figuring out, related to disk and other device
> setup.  The main cause is the fact that the linux kernel is no longer
> predicatble and sequencial, but asynchonous.  No amount of wishful
> thinking is going to bring is back to a world where static sequencing of
> boot events is going to handle all the interdependencies.

Systemd fails to solve them as well -- while introducing a lot of unsolved
problems on its own, such as degraded RAID problems (no, it's not possible
do to that in an event-driven way, you need a static sequence in at least
some cases).

But one thing we can agree on: the situation both approaches try to deal
with is a mess.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote:
> The question is: Is 
> the package buggy if it does not contain an init script but a systemd 
> unit and it seems to be the case. Note that there are a *lot* of useful 
> options in a systemd unit that would need emulation to make properly 
> work with sysvinit.

Shipping a systemd unit without a corresponding init script with the
same name is forbidden by policy:

| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and equivalent functionality to any
| init-specific job
+---[ Debian Policy, section 9.11 ]

In practice this is ignored.

Note that this also forbids, for example, ssh.socket/ssh@.service or
tor@.service which all don't have a corresponding init script of the
same name.  Also cases where the init script starts multiple services,
but there are individual units for each service in systemd is
forbidden.

I think this requirement isn't a good idea these days for various
reasons and will file a bug asking to drop it.

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Petter Reinholdtsen]

[Martin Pitt]
> It's not only that. The sysvinit package *itself* doesn't actually do
> much really. That's not to downplay your past involvement there of
> course (e. g.  developing insserv alone was a huge task), but the
> *real* maintenance is in all the packages that *ship* SysV init
> scripts.

Sure.  But for the common case, it do not need to be much, when using
the /lib/init/init-d-script mechanism.  Of the around 1000 packages with
init.d scripts when I kept track of such things, around 900 did not need
much logic at all to start its daemon.  And as I wrote five years
ago[1], the init.d script often do not have to be longer than this:

#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  rsyslog
# Required-Start:$remote_fs $time
# Required-Stop: umountnfs $time
# X-Stop-After:  sendsigs
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: enhanced syslogd
# Description:   Rsyslog is an enhanced multi-threaded syslogd.
#It is quite compatible to stock sysklogd and can be 
#used as a drop-in replacement.
### END INIT INFO
DESC="enhanced syslogd"
DAEMON=/usr/sbin/rsyslogd

[1] http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
 >

> SysV init leaves all the really hard problems to these, as it cannot
> really do much by itself. That's a fact that people that keep yelling
> "but SysV init was so easy!" keep finessing..

Absolutely.  And the sysvinit boot system have lots of unsolved problems
we never got around to figuring out, related to disk and other device
setup.  The main cause is the fact that the linux kernel is no longer
predicatble and sequencial, but asynchonous.  No amount of wishful
thinking is going to bring is back to a world where static sequencing of
boot events is going to handle all the interdependencies.

To bad systemd do not work with kFreeBSD and Hurd, then we could use the
same mechanism on all architectures.

-- 
Happy hacking
Petter Reinholdtsen

Re: Debian Buster release to partially drop non-systemd support

[Martin Pitt]

Petter Reinholdtsen [2018-10-16 15:55 +0200]:
> [Benda Xu]
> > I was about to reply to this thread, but you have completely expressed
> > what I want to say:
> >
> > 1. systemd-shim is not necessary, even for DEs (except GNOME3).
> > 2. sysvinit-core is very stable and do not need new uploads.
> 
> Thank you for expressing so well the cause of the fate for sysvinit in
> Debian.  It seem clear its proponents believe everything is OK and no
> effort is needed to save sysvinit.  If this continues, sysvinit in
> Debian will continue to rot and end up being removed.
> 
> I know from maintaining the sysvinit set of packages that it require
> work to maintain them.  There are hundreds of open bugs against the
> sysvinit packages in Debian already.

It's not only that. The sysvinit package *itself* doesn't actually do much
really. That's not to downplay your past involvement there of course (e. g.
developing insserv alone was a huge task), but the *real* maintenance is in all
the packages that *ship* SysV init scripts.

SysV init leaves all the really hard problems to these, as it cannot really do
much by itself. That's a fact that people that keep yelling "but SysV init was
so easy!" keep finessing..

So "how many RC bugs does sysvinit have" is a completely useless metric IMHO.

Martin

Re: Debian Buster release to partially drop non-systemd support

[Thorsten Glaser]

On Tue, 16 Oct 2018, Adam Borowski wrote:

> > > With only two modified binary packages (policykit-1 and udisks2) I’ve

> 1. You need to recompile these packages, this is not something an average
> user or even sysadmin knows how to do.

I publish .deb packages for them (although not for all arches yet).

> 2. You lose basic functionality like being able to shutdown from a GUI.

Oh? For me, Ctrl-Alt-Backspace+Ctrl-Alt-Del works.

> > 1. systemd-shim is not necessary, even for DEs (except GNOME3).
> 
> Alas, dependency chains say otherwise.

Huh?

> What almost all of those packages want is logind functionality, but I quite

I don’t know about “logind functionality” and don’t care about it,
I’ve never needed it, and disqualifying sysvinit because it doesn’t
have it is plain wrong because there are a *lot* of use cases that
don’t need it.

Perhaps it’d be better if it were available. But the counter-reaction
of disqualifying if it’s not available is invalid.

> Other pieces are some power management that has been moved into logind, etc.

Eh? The acpi command works, and sysfs writes do so, too…

> > 2. sysvinit-core is very stable and do not need new uploads.
> 
> Exactly!  Almost any changes in recent years were entirely because "systemd
> wants X".  Thus, no wonders people are angry because of unnecessary work.

Hm. I didn’t follow those changes, but if it’s that… good point.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Tue, Oct 16, 2018 at 07:47:36PM +0800, Benda Xu wrote:
> Thorsten Glaser  writes:
> > … this applies to the shim only. I was a bit surprised seeing on
> > someone else’s system that it was no longer installable, but almost
> > all systemd-free systems of people I know do not use the shim anyway,
> > so I’d take the Subject line with a few grains of salt.
> >
> > With only two modified binary packages (policykit-1 and udisks2) I’ve
> > got a complete KDE environment running, except for network-manager,
> > without the shim. People who do not use the full desktop environments
> > (but the leaner ones, or just a window manager, or no X11 at all) have
> > no problems with the current situation.

1. You need to recompile these packages, this is not something an average
user or even sysadmin knows how to do.

2. You lose basic functionality like being able to shutdown from a GUI.

> I was about to reply to this thread, but you have completely expressed
> what I want to say:
> 
> 1. systemd-shim is not necessary, even for DEs (except GNOME3).

Alas, dependency chains say otherwise.

What almost all of those packages want is logind functionality, but I quite
don't get "why?".  The only answer I received so far is "multiseat". 
Except, logind doesn't allow multiple GUI logins on the same machine for the
same user no matter how many seats you connect from (this worked correctly
before!), and it offers additional features for non-GUI logins either.  So
all this functionality does is telling you that user X is logged on via
vt/pty Y.  I recall a command named "who" on stone age Unices, and wonder
what the whole hassle is about...

But, it's not entirely unreasonable to provide the dbus interface logind
users want.  I'd prefer such an interface be a shim to standard Unix (like
who -- utmp), which would have the added benefit of working on BSD and Hurd
(which I don't personally care about but some do) -- yet such an daemon
would have to be written.  I for one don't volunteer to write it by
tomorrow...  Thus, let's use elogind which actually exists.

Other pieces are some power management that has been moved into logind, etc.

> 2. sysvinit-core is very stable and do not need new uploads.

Exactly!  Almost any changes in recent years were entirely because "systemd
wants X".  Thus, no wonders people are angry because of unnecessary work.


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Petter Reinholdtsen]

[Benda Xu]
> I was about to reply to this thread, but you have completely expressed
> what I want to say:
>
> 1. systemd-shim is not necessary, even for DEs (except GNOME3).
> 2. sysvinit-core is very stable and do not need new uploads.

Thank you for expressing so well the cause of the fate for sysvinit in
Debian.  It seem clear its proponents believe everything is OK and no
effort is needed to save sysvinit.  If this continues, sysvinit in
Debian will continue to rot and end up being removed.

I know from maintaining the sysvinit set of packages that it require
work to maintain them.  There are hundreds of open bugs against the
sysvinit packages in Debian already.

-- 
Vennlig hilsen
Petter Reinholdtsen

Re: Debian Buster release to partially drop non-systemd support

[The Wanderer]

On 2018-10-16 at 08:48, Philipp Kern wrote:

> On 2018-10-16 14:36, Ian Jackson wrote:
> 
>> Philipp Kern writes ("Re: Debian Buster release to partially drop 
>> non-systemd support"):
>> 
>>> Could someone reiterate about what the current state of init
>>> diversity is supposed to be? Is it assumed to be best effort of
>>> every maintainer being required to ship an init script next to
>>> the systemd unit that is actually used by default[1]?
>> 
>> I think describint that as `effort' is rather much.
> 
> I don't understand. If I submit a merge request to the maintainer,
> it's on me to test what I submit actually works. So if I add stuff
> for a completely different init system I have to test it. The
> question is: Is the package buggy if it does not contain an init
> script but a systemd unit and it seems to be the case. Note that
> there are a *lot* of useful options in a systemd unit that would need
> emulation to make properly work with sysvinit.

To my eye, this resembles the situation I see with Websites and JavaScript.

My position is that any Webpage which does not inherently need to be
dynamic (as only a tiny fraction of them do) should have a fallback to
work "well enough" in an environment which lacks JavaScript.
Importantly, "well enough" does *not* mean "just as well".

One example I give of the difference is that once upon a time, when I
visited an article on the Website of the Washington Post in Firefox with
NoScript, the page would render with multiple screens' worth of blank
space (except possibly for a generic left-hand sidebar) at the top,
before the actual page content - the article itself - at the bottom.
That was in no way working "just as well" as the with-JavaScript case,
but it did let me read the article, so it did qualify as working "well
enough".

In the same way, I would opine that a package does not need to work
"just as well" via the init script as via the systemd unit in order to
qualify as having sufficient sysvinit support, but it does need to work
"well enough" that way. That is, not all the fancy bells and whistles
that could be make the package more useful or easier to work with or
suchlike necessarily need to be included, but the basic functionality
should be present.

(And I say that as a near-diehard sysvinit user, who finds the idea of
sysvinit being dropped from Debian a source of considerable stress.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Debian Buster release to partially drop non-systemd support

[Philipp Kern]

On 2018-10-16 14:36, Ian Jackson wrote:

Philipp Kern writes ("Re: Debian Buster release to partially drop
non-systemd support"):

Could someone reiterate about what the current state of init diversity
is supposed to be? Is it assumed to be best effort of every maintainer
being required to ship an init script next to the systemd unit that is
actually used by default[1]?

I think describint that as `effort' is rather much.


I don't understand. If I submit a merge request to the maintainer, it's 
on me to test what I submit actually works. So if I add stuff for a 
completely different init system I have to test it. The question is: Is 
the package buggy if it does not contain an init script but a systemd 
unit and it seems to be the case. Note that there are a *lot* of useful 
options in a systemd unit that would need emulation to make properly 
work with sysvinit.



Can we rely on sysvinit users to report the
bugs with the scripts or how intensively do they need to be tested?

You should rely on users to report bugs.


Okay. In this case I contributed to the package of someone else and 
don't want to make it buggy.



Similarly, are maintainers allowed to ship timer units in lieu of
cronjobs? As an example I invested some time in
prometheus-node-exporter[2] to run textfile collectors of monitoring
data (SMART, apt) in the background. Would I have been required by
policy to make sure that all of this also works on a system with
sysvinit?

Obviously it would be better to make ti work with cron.  Ideally it
would go into cron.daily which I assume works with systemd too.


It'd need to run much more often (every 15 minutes). So cron.daily 
wouldn't fit. For the sake of the argument it'd need to be a shell 
script that checks multiple conditions (see [1]). And we currently don't 
have timer/cron deduplication, unfortunately. That means it'd also need 
to disable itself on systemd systems (but of course cron would still 
invoke the script periodically). Similarly - as a more general remark - 
having it as a cronjob doesn't let you monitor it in quite the same way.



But if you do just the systemd thing, I think if someone sends you a
patch to make it work with cron I think you should accept and carry
that patch.


In this case that might be feasible because if it breaks that user is 
hopefully going to monitor it anyway, because it's a monitoring thing. 
But there is a cost to carrying such things (such as cron confusingly 
invoking something whose output isn't used at all because it's going to 
be short circuited at startup).


Kind regards
Philipp Kern

[1] 
https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1/diffs#229e10b19f8b27233d2301c8bb553b6bdd8e5b1a

Re: Debian Buster release to partially drop non-systemd support

[Ian Jackson]

Philipp Kern writes ("Re: Debian Buster release to partially drop non-systemd 
support"):
> Could someone reiterate about what the current state of init diversity 
> is supposed to be? Is it assumed to be best effort of every maintainer 
> being required to ship an init script next to the systemd unit that is 
> actually used by default[1]?

I think describint that as `effort' is rather much.

> Can we rely on sysvinit users to report the 
> bugs with the scripts or how intensively do they need to be tested?

You should rely on users to report bugs.

> Similarly, are maintainers allowed to ship timer units in lieu of 
> cronjobs? As an example I invested some time in 
> prometheus-node-exporter[2] to run textfile collectors of monitoring 
> data (SMART, apt) in the background. Would I have been required by 
> policy to make sure that all of this also works on a system with 
> sysvinit?

Obviously it would be better to make ti work with cron.  Ideally it
would go into cron.daily which I assume works with systemd too.

But if you do just the systemd thing, I think if someone sends you a
patch to make it work with cron I think you should accept and carry
that patch.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian Buster release to partially drop non-systemd support

[Ian Jackson]

KatolaZ writes ("Re: Debian Buster release to partially drop non-systemd 
support"):
> The problem that spurred this thread is that sysvinit needs a
> maintainer. That's why some of us are here: our intention is to help
> with maintaining sysvinit in Debian if possible, since we will keep
> maintaining it in Devuan nevertheless.

Thank you.  That would be awesome.

I am very sorry that Debian is a toxic environment for this kind of
work.  As someone who has a lot of investment in Debian I find it very
sad.

TBH I have been head-in-the-sand about much of this, because I find
these kind of discussions in Debian fora so unpleasant.  I think it's
only a minority who make personal attacks and generate negative
energy, but it's awful.

Please come to debian-init-divers...@chiark.greenend.org.uk.

> I am not interested in chit-chat or flames, because those don't get
> packages released. The only reason I am here is that sysvinit is
> effectively getting kicked off Debian, and I think I can help avoiding
> that.

Great.

I will sponsor your uploads to Debian.

Ian.

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Matthew Vernon - 16.10.18, 13:27:
> Ian Jackson  writes:
> > Also we are hampered by the lack of a safe space to communicate and
> > coordinate.  I looked at some of the technical work done in other
> > distros to try to make desktoppy stuff continue to work well, and it
> > generally seems sane.  But some of those projects are quite toxic
> > here in Debian, as can be seen from some of the messages here.
> > 
> > We are setting up a separate mailing list on my server where we hope
> > to do the work without having to deal with people who don't see the
> > point or who have problems with some of the contributors.
> 
> I've done this, since it seemed a natural extension of my previous
> email about trying to find people who might have effort and maybe
> facilitate a bit of co-ordination.
> 
> So:
> http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversi
> ty
> 
> It's a standard mailman list with a public archive. I'm hoping people
> interested in init system diversity in Debian can use it as a place to
> co-ordinate. I don't want it to be used to slag off $init_system or
> $distribution_or_derivative.

Thank you.

I think it is good to move there for anything about actually having 
sysvinit and related packaged being maintained again.

And I agree to leave let go on anything else.

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Philipp Kern]

On 2018-10-16 13:27, Matthew Vernon wrote:

So:
http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity

It's a standard mailman list with a public archive. I'm hoping people
interested in init system diversity in Debian can use it as a place to
co-ordinate. I don't want it to be used to slag off $init_system or
$distribution_or_derivative.


Could someone reiterate about what the current state of init diversity 
is supposed to be? Is it assumed to be best effort of every maintainer 
being required to ship an init script next to the systemd unit that is 
actually used by default[1]? Can we rely on sysvinit users to report the 
bugs with the scripts or how intensively do they need to be tested?


Similarly, are maintainers allowed to ship timer units in lieu of 
cronjobs? As an example I invested some time in 
prometheus-node-exporter[2] to run textfile collectors of monitoring 
data (SMART, apt) in the background. Would I have been required by 
policy to make sure that all of this also works on a system with 
sysvinit? Note that this includes the usage of file presence checks and 
OnBootSec, so I suppose that'd mean both anacron and cron as well as an 
actual shell script that checks for the preconditions. Would anacron and 
cron need to be depended upon in that case or would they could they even 
just be recommended? Both would not be needed on a default Debian system 
that ships with systemd.


Kind regards and thanks
Philipp Kern

[1]
"Alternative init implementations must support running SysV init scripts 
as described at System run levels and init.d scripts for compatibility."

[https://www.debian.org/doc/debian-policy/ch-opersys.html#alternate-init-systems]
[2] 
https://packages.qa.debian.org/p/prometheus-node-exporter/news/20181015T165248Z.html

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

KatolaZ - 16.10.18, 13:39:
> On Tue, Oct 16, 2018 at 12:38:19PM +0200, Michael Biebl wrote:
> 
> [cut]
> 
> > What you say is obviously wrong, and you should know that if you
> > follow devuan.
> > 
> > Even the founder of Devuan regularly uses exactly the words Ansgar
> > described.
> > Chris Lamb not to long ago was target of those conspiracy theories
> > and hate mails (search for redis on their mailing list) if you
> > don't believe me.
> The problem that spurred this thread is that sysvinit needs a
> maintainer. That's why some of us are here: our intention is to help
> with maintaining sysvinit in Debian if possible, since we will keep
> maintaining it in Devuan nevertheless. You can still decide you don't
> want this kind of help because we stink or you find Devuan "toxic"
> (even if this would be against some of the principles we should
> instead agree upon). That could be fine, if motivated by a solid
> reasoning, and not just by a flame.
> 
> In the last four years there has been hatred from both camps (Debian
> vs Devuan), and there is no doubt that most of that could/should have
> been avoided on both parts. Grepping through email archives and
> resurecting posts from 3 or 4 years ago won't help to move on, though.
> 
> I am not interested in chit-chat or flames, because those don't get
> packages released. The only reason I am here is that sysvinit is
> effectively getting kicked off Debian, and I think I can help avoiding
> that.

I wholeheartedly agree with that.

Digging for mud in the past just brings up mud from the past as I wrote 
in my other post.

As we are all human beings with feelings, human beings who sometimes 
feel hurt and or hurt each other, there is plenty of opportunity to find 
mud in the past. And I am pretty sure that you can find this mud on any 
side, with any party of the discussion back then.

I won't engage in doing so anymore than I did in my other post as it 
does not help to move forward and get work done.

I strongly recommend to move on and see whether KatolaZ and others from 
the Devuan can help with maintaining sysvinit. I see this decision 
mainly with those who maintained it in the past.

Michael, I interacted both with you and with KatolaZ. I have seen you at 
Debconf 2015 and I was surprised to see how friendly you interacted with 
others. I surprised cause I still remembered how I interacted with mail 
– and I am including myself in here, I think I did not make it easy for 
you at times. I also interacted with KatolaZ and he treated me friendly 
and kindly as well.

I perceived both you, Michael, and you, KatolaZ as being friendly in 
supportive. Each one of you in their own ways.

Michael, now can you let go and let the shadows of the past… be in the 
past? Having sysvinit be maintained in Debian again, can also help you 
along with not having to upload it yourself from time to time anymore :)

Of course, as long as KatolaZ or other Devuan developers helping with 
Sysvinit maintenance are not at least Debian maintainers someone would 
need to sponsor their work. But it could be Ian or any of the former 
Sysvinit maintainers as well. And it may be a good approach to start 
cooperation in this smaller way.

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

I intend this to be my last response on that topic here. So even if you 
choose to reply in a way that I feel hurt about, I intend to just let go 
and end the hurting cycle within my heart instead of replying another 
time.

Ansgar Burchardt - 16.10.18, 12:20:
> On Tue, 2018-10-16 at 09:57 +0200, Martin Steigerwald wrote:
> > Ansgar Burchardt - 16.10.18, 08:53:
> > > If some people consistently call others a "cancer", accuse them of
> > > "vandalizing" open source, spread obvious FUD and so on, then I
> > > don't
> > > think they would fit in well in Debian's culture where they would
> > > have to accept that packages such as systemd exist.
> > 
> > I disagree. So far I saw none of the Devuan developers (!) I had
> > contact with doing any of the stuff you accuse them of. I think it
> > is important to see the difference between the comments on random
> > people in some mailing list or IRC channel and *actual* Devuan
> > *developers*.
> Let me see how some actual Devuan developers think about systemd:
> 
> +---
> 
> | I personally find hilarious that most of the people out there are
> | still convinced that the systemd-nonsense is just a replacement for
> | sysv-init, while it should be clear by now that it is already
> | becoming a pervasive cancer...
> 
> +---[ Enzo Nicosia aka KatolaZ in
> 20150330170221.gm22...@katolaz.homeunix.net ]

*sigh* I thought I might provoke such a response actually digging for 
dirt from the past. As such my previous post may not have been helpful.

There are two important things about this:

1) KatolaZ is writing about Systemd as a software or as a project. *Not* 
about a person. This is a *huge* difference.

2) This has been 2015. It was a heated discussion back and there have 
been a lot of heated comments back then. From all sides. As I raised 
concerns of users on systemd-user and then added my own interpretation, 
Lennart Poettering called me "You are just being a dick now."¹ I 
unsubscribed from systemd-devel after that, as I did not tolerate this 
personal attack. I also would not be surprised when some Debian 
developers back then also have posted heated comments. Ian got the 
impression that there has been toxic behavior within the Debian project 
as well. I agree.

[1] [systemd-devel] I wonder… why systemd provokes this amount of 
polarity and resistance
https://lists.freedesktop.org/archives/systemd-devel/2014-October/
024180.html

(no message-id as I deleted this message from my mail client back then)

While I personally may not use the word cancer, I also have the 
impression that Systemd meanwhile is almost everywhere. I noticed so as 
I updated my Linux training slides for Systemd. I have it in service 
management chapter, I have it in cron job chapter, I have it in network 
chapter (hostnamectl + service, systemd-networkd at least mentioned), I 
have it in time management and NTP chapter (timedatectl as well as in-
built NTP server mentioned). And then there is systemd-logind and so on…

Seeing that I perfectly see how one can come to the conclusion that 
Systemd is almost everywhere – similar to cancer. I personally would not 
say today that it "infected" these areas of Linux eco system, but 
Systemd is almost everywhere meanwhile and back then I had the 
impression that how Systemd spread was similar to the embrace, extend, 
extinguish pattern seen with Microsoft. This analogy back then triggered 
the personal attack of Lennart. It may have been a quite direct and 
probably not even justified attack at Systemd by me at that time, but it 
was not directed at him personally.

But full stop already: This is about a past discussion. And it is a 
discussion about Systemd, not about a person. I do not see a personal 
attack in any of the posts you cited. Unless Lennart identified himself 
with Systemd, well then he chose to receive such attacks as being 
personal.

There are different approaches:

1. Have it all in one larger integrated package.

2. Have one tool for one job and another tool for another job. 
Separately packaged and mixable.

It even is not about which is better. Some believe approach 1 is. Others 
believe approach 2 is.

What this whole thing is about: Can people who believe approach 2 is, 
help Debian with maintaining sysvinit? I am sure they can.

And did some people learn from the past and let go? I am sure they did.

Recycling the past just gives us that: A recycled past.

The same crap that triggered so much hurting on all sides back then.

So now, would it be possible to let the past *be* in the past. And see 
what can be done now?

> +---
> 
> | that's exactly what I referred to when I talked of the
> | systemd-nonsense as a "cancer". The damage is not merely technical
> | and localised to the relatively minor issue of replacing PID 1, as
> | you correctly pointed out, but "systemic" and "social". And that's
> | exactly why we should be more concerned about it.
> 
> +---[ Enzo Nicosia aka KatolaZ in
> 

Re: Debian Buster release to partially drop non-systemd support

[Benda Xu]

Hi Thorsten,

Thorsten Glaser  writes:

> … this applies to the shim only. I was a bit surprised seeing on
> someone else’s system that it was no longer installable, but almost
> all systemd-free systems of people I know do not use the shim anyway,
> so I’d take the Subject line with a few grains of salt.
>
> With only two modified binary packages (policykit-1 and udisks2) I’ve
> got a complete KDE environment running, except for network-manager,
> without the shim. People who do not use the full desktop environments
> (but the leaner ones, or just a window manager, or no X11 at all) have
> no problems with the current situation.
>
>> >   sysvinit currently has two maintainers, but they've only
>> > ever made one upload (over a year ago).
>> 
>> It seems that these facts are either largely ignored or unknown and I
>> wonder if some noise should be made so that interested people can pick
>> up the work now and not only complain later.
>
> Why would sysvinit need uploads? It’s largely working software
> that needs few changes. I personally find upload frequency as
> a measurement misused too often: sure, no uploads raises some
> questions, but more than four to six uploads a year should, in
> my opinion, raise even more questions (namely whether the soft‐
> ware is ripe and stable enough in the first place).

I was about to reply to this thread, but you have completely expressed
what I want to say:

1. systemd-shim is not necessary, even for DEs (except GNOME3).
2. sysvinit-core is very stable and do not need new uploads.

Cheers,
Benda

Re: Debian Buster release to partially drop non-systemd support

[KatolaZ]

On Tue, Oct 16, 2018 at 12:38:19PM +0200, Michael Biebl wrote:

[cut]

> 
> What you say is obviously wrong, and you should know that if you follow
> devuan.
> 
> Even the founder of Devuan regularly uses exactly the words Ansgar
> described.
> Chris Lamb not to long ago was target of those conspiracy theories and
> hate mails (search for redis on their mailing list) if you don't believe me.
>

The problem that spurred this thread is that sysvinit needs a
maintainer. That's why some of us are here: our intention is to help
with maintaining sysvinit in Debian if possible, since we will keep
maintaining it in Devuan nevertheless. You can still decide you don't
want this kind of help because we stink or you find Devuan "toxic"
(even if this would be against some of the principles we should
instead agree upon). That could be fine, if motivated by a solid
reasoning, and not just by a flame.

In the last four years there has been hatred from both camps (Debian
vs Devuan), and there is no doubt that most of that could/should have
been avoided on both parts. Grepping through email archives and
resurecting posts from 3 or 4 years ago won't help to move on, though.

I am not interested in chit-chat or flames, because those don't get
packages released. The only reason I am here is that sysvinit is
effectively getting kicked off Debian, and I think I can help avoiding
that.

HND

Enzo Nicosia

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Matthew Vernon]

Ian Jackson  writes:

> Also we are hampered by the lack of a safe space to communicate and
> coordinate.  I looked at some of the technical work done in other
> distros to try to make desktoppy stuff continue to work well, and it
> generally seems sane.  But some of those projects are quite toxic here
> in Debian, as can be seen from some of the messages here.
>
> We are setting up a separate mailing list on my server where we hope
> to do the work without having to deal with people who don't see the
> point or who have problems with some of the contributors.

I've done this, since it seemed a natural extension of my previous email
about trying to find people who might have effort and maybe facilitate a
bit of co-ordination.

So:
http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity

It's a standard mailman list with a public archive. I'm hoping people
interested in init system diversity in Debian can use it as a place to
co-ordinate. I don't want it to be used to slag off $init_system or
$distribution_or_derivative.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: Debian Buster release to partially drop non-systemd support

[Michael Biebl]

Am 16.10.18 um 09:57 schrieb Martin Steigerwald:
> Ansgar Burchardt - 16.10.18, 08:53:
>> If some people consistently call others a "cancer", accuse them of
>> "vandalizing" open source, spread obvious FUD and so on, then I don't
>> think they would fit in well in Debian's culture where they would have
>> to accept that packages such as systemd exist.
> 
> I disagree. So far I saw none of the Devuan developers (!) I had contact 
> with doing any of the stuff you accuse them of.

..

>> And no, it's not just that infobot factoid or just random people that
>> are totally unrelated to Devuan.
> 
> A claim without facts. So FUD in itself. I let go on spending energy to 
> prove otherwise.

What you say is obviously wrong, and you should know that if you follow
devuan.

Even the founder of Devuan regularly uses exactly the words Ansgar
described.
Chris Lamb not to long ago was target of those conspiracy theories and
hate mails (search for redis on their mailing list) if you don't believe me.

Personally I'm happy that the Devuan people moved to their own place as
debian-devel and debian-user became bearable again.

Michael

[1] https://lists.dyne.org/lurker/message/20171024.145026.a763a9da.en.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Tue, 2018-10-16 at 09:57 +0200, Martin Steigerwald wrote:
> Ansgar Burchardt - 16.10.18, 08:53:
> > If some people consistently call others a "cancer", accuse them of
> > "vandalizing" open source, spread obvious FUD and so on, then I don't
> > think they would fit in well in Debian's culture where they would have
> > to accept that packages such as systemd exist.
> 
> I disagree. So far I saw none of the Devuan developers (!) I had contact 
> with doing any of the stuff you accuse them of. I think it is important 
> to see the difference between the comments on random people in some 
> mailing list or IRC channel and *actual* Devuan *developers*.

Let me see how some actual Devuan developers think about systemd:

+---
| I personally find hilarious that most of the people out there are
| still convinced that the systemd-nonsense is just a replacement for
| sysv-init, while it should be clear by now that it is already
| becoming a pervasive cancer...
+---[ Enzo Nicosia aka KatolaZ in 20150330170221.gm22...@katolaz.homeunix.net ]

+---
| that's exactly what I referred to when I talked of the
| systemd-nonsense as a "cancer". The damage is not merely technical and
| localised to the relatively minor issue of replacing PID 1, as you
| correctly pointed out, but "systemic" and "social". And that's exactly
| why we should be more concerned about it.
+---[ Enzo Nicosia aka KatolaZ in 20150331093754.go22...@katolaz.homeunix.net ]

+---
| What we really need is to build sufficient maintainer capacity and
| capability to fork more packages and excise this systemd cancer once and
| for all. [...] If we don't slay the beast, it will continue to
| grow and infect more components ever more invasively,
+---[ Daniel Reurich in 
https://lists.dyne.org/lurker/message/20180619.232314.a3229d06.html ]

As a lazy person I was just grepping for "cancer" in the mail archive
and picked a few examples.  Too lazy to search for other insults.

I'm not alone in seeing this as a problem in the Devuan community.  A
certain Martin Steigerwald pointed out:

+---
| As a honest feedback:
|
| Currently I do not read much of the threads here.
|
| Cause again and again I see language like systemd being like a cancer or 
| infecting people´s systems.
+---[ Martin Steigerwald in 24625919.fzpRARYAEh@merkaba ]

Tolerating this *does* reflect back on project leaders, more so if some
of them also engage in the behavior.

Debian already had a systemd maintainer step back because of abuse from
a certain group of people[1].  As I would like to see systemd still
maintained in the future, I don't think it's worth to try to integrate
the abusers in Debian as package maintainers.

Given that the systemd maintainers also have to deal with sysvinit,
maintainership of sysvinit is probably especially problematic.

  [1] 
https://err.no/personal/blog/tech/debian/2014-11-16-23-55_resigning_from_pkg-systemd/

> > And no, it's not just that infobot factoid or just random people that
> > are totally unrelated to Devuan.
> 
> A claim without facts. So FUD in itself. I let go on spending energy to 
> prove otherwise.

See above for a few examples.

> In addition to that the infobot factiod may easily have not been from a 
> Devuan developer or someone else related to Devuan:
> 
> goli...@dyne.org - 16.10.18, 03:32:
> > infobot is a bot with a database that references 119770 factoids that
> > can be queried. Each one has it's own individual author and literally
> > anybody can add new factoids to the bot. It has been around for about
> > 20 years. It *allows* Devuan to use the bot services and would allow
> > Debian to do exactly same.�
> 
> https://lists.dyne.org/lurker/message/20181016.013255.cada93dc.en.html
>
> I put the emphasis on *anybody* here.

Dunno, I saw it used by IRC channel operators.  I would assume that IRC
channel ops are not totally unrelated people...
 
> So I close with a snippet from the post of KatolaZ mentioned above:
> 
> KatolaZ - 16.10.18, 06:23:
> > Let's try to reduce the useless chit-chat and drama to a minimum,
> > please (and the minimum is zero, in this case), since that's not
> > helpful at all, and does not build packages. I subscribed to
> > debian-devel as well, and will reach out later.
> 
> https://lists.dyne.org/lurker/message/20181016.042148.1688fecb.en.html
> 
> Drama is not helpful to get anything done. KatolaZ already reached out.

Ah, one of the people calling systemd a cancer. Great.

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Philip Hands]

Ansgar Burchardt  writes:

...
> Please no.  I don't think it would help Debian to have toxic people
> maintain packages.

You are using a fairly blunt tool if you judge people based on their
preference of operating system. ;-)

Let's instead judge people by the way they behave.

I admit that I have encountered individuals who were in some sense
supportive of Devuan and were also at least somewhat antagonistic, but
it seems unlikely they will be the ones to get in touch and offer help.

That being the case, I seriously doubt you need to be concerned.

If people with a preference for Devuan wish to work constructively
within Debian, we should welcome them.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Ian Jackson]

Martin Steigerwald writes ("Re: Debian Buster release to partially drop 
non-systemd support"):
> Ian, cc'ing you to make you aware of this discussion, in case you 
> aren't, and give you an opportunity to comment on your aim to adopt 
> sysvinit package from some time ago.

Thanks.  That's very helpful.

I had in fact missed this entire discussion because I had `systemd' in
my killfile from the relentless advocacy flamewars ~4-5 years ago.

As Matthew Vernon writes, some of us have been working to fix these
problems but we are indeed somewhat hampered by a lack of effort.

Also we are hampered by the lack of a safe space to communicate and
coordinate.  I looked at some of the technical work done in other
distros to try to make desktoppy stuff continue to work well, and it
generally seems sane.  But some of those projects are quite toxic here
in Debian, as can be seen from some of the messages here.

We are setting up a separate mailing list on my server where we hope
to do the work without having to deal with people who don't see the
point or who have problems with some of the contributors.

There'll be another mail shortly with details of the list.

Ian.

Re: Debian Buster release to partially drop non-systemd support

[Ian Campbell]

On Tue, 2018-10-16 at 09:48 +0100, Jonathan Dowland wrote:
> On Tue, Oct 16, 2018 at 08:59:16AM +0200, Narcis Garcia wrote:
> > I'm using this express-made address because personal addresses
> > aren't
> > masked enough at this mail public archive. Public archive
> > administrator
> > should fix this against automated addresses collectors.
> 
> The right way to fight spam is to get a good spam filter. It's
> effectively a solved problem these days. Hiding addresses makes
> legitimate use of mail harder. Why let spammers make our lives
> harder?

Not to mention that public lists like d-devel are distributed and
archived all over the Internet in places we have absolutely no control
or influence over, our own archives on lists.d.o are just one drop in
that ocean.

Ian.

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Mon, Oct 15, 2018 at 04:03:45PM +0200, Ansgar Burchardt wrote:

Please no.  I don't think it would help Debian to have toxic people
maintain packages.


At least some of the people who were at least once involved in Devuan
(I haven't kept on top) were once valued Debian contributors - e.g.
Roger Leigh. But I appreciate that some very troublesome individuals
are associated with it, and we wouldn't want to deal with them.

I see it as a sign of our project's healthiness that we are concerned
about such things and have processes to deal with it when it happens.


(As an example, Devuan's infobot has fun facts like this one:
"<+infobot> 'sth is poettering' means it acts invasive, possessive,
destructive, and generally in an egocentric exacerbating negative way.
``this cancer is extremely poettering'' [...]")


I agree that's reprehensible, reflects badly on their project, and I
don't condone it.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Tue, Oct 16, 2018 at 08:59:16AM +0200, Narcis Garcia wrote:

I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.


The right way to fight spam is to get a good spam filter. It's
effectively a solved problem these days. Hiding addresses makes
legitimate use of mail harder. Why let spammers make our lives
harder?

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Ansgar Burchardt - 16.10.18, 08:53:
> If some people consistently call others a "cancer", accuse them of
> "vandalizing" open source, spread obvious FUD and so on, then I don't
> think they would fit in well in Debian's culture where they would have
> to accept that packages such as systemd exist.

I disagree. So far I saw none of the Devuan developers (!) I had contact 
with doing any of the stuff you accuse them of. I think it is important 
to see the difference between the comments on random people in some 
mailing list or IRC channel and *actual* Devuan *developers*.

I am no Debian maintainer or developer in the formal sense, but I 
maintain two packages for Debian. In one of them, fio, I integrated an 
sysvinit script for running fio as a service in addition to the Systemd 
unit – also for improving support in Devuan that I use with my servers. 
As I had some issues with that I asked on Devuan's dng mailing list and 
got professional help from KatolaZ mentioning a fio option I was not 
aware of and did not think of checking for. That helped me to improve 
the upstream Systemd unit as well. Yes, that is right: My work on that 
sysvinit script actually led to an improvement of the Systemd unit.

https://tracker.debian.org/news/947012/accepted-fio-35-1-source-amd64-into-unstable/

What I saw so far is that Devuan developers are actually not at all 
interested in drama, but in getting work done. Here a recent example for 
that:

KatolaZ
Re: [devuan-dev] Debian Buster release to partially drop non-systemd 
support
https://lists.dyne.org/lurker/message/20181016.042148.1688fecb.en.html

> And no, it's not just that infobot factoid or just random people that
> are totally unrelated to Devuan.

A claim without facts. So FUD in itself. I let go on spending energy to 
prove otherwise.


In addition to that the infobot factiod may easily have not been from a 
Devuan developer or someone else related to Devuan:

goli...@dyne.org - 16.10.18, 03:32:
> infobot is a bot with a database that references 119770 factoids that
> can be queried. Each one has it's own individual author and literally
> anybody can add new factoids to the bot. It has been around for about
> 20 years. It *allows* Devuan to use the bot services and would allow
> Debian to do exactly same.

https://lists.dyne.org/lurker/message/20181016.013255.cada93dc.en.html

I put the emphasis on *anybody* here.

So I close with a snippet from the post of KatolaZ mentioned above:

KatolaZ - 16.10.18, 06:23:
> Let's try to reduce the useless chit-chat and drama to a minimum,
> please (and the minimum is zero, in this case), since that's not
> helpful at all, and does not build packages. I subscribed to
> debian-devel as well, and will reach out later.

https://lists.dyne.org/lurker/message/20181016.042148.1688fecb.en.html

Drama is not helpful to get anything done. KatolaZ already reached out.

I suggest to continue discussion about getting work done on Debian 
sysvinit maintainer's list. And to end it here.

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Ian Campbell]

On Mon, 2018-10-15 at 22:31 -0700, Alessio Treglia wrote:
> On Mon, Oct 15, 2018 at 9:51 PM Enzo Nicosia 
> wrote:
> > Please, just tell us who we should contact (current/last
> > maintainer?) to start working on that.
> 
> That's easy [1].

It is, but the link you gave is a rather cryptic way of putting it.

Enzo, you can reach the current maintainers at:


Note that alioth lists were migrated to another service some time
ago[0], so this is really this list behind the scenes (e.g. if you were
looking to subscribe or for the archives):

   https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sysvinit-devel

You might also find https://tracker.debian.org/pkg/sysvinit useful, in
particular it lists the "Uploaders" which is some kind of imperfect
proxy for "most recently active maintainers".

HTH,
Ian.

[0] https://alioth-lists.debian.net/ has some info on that.

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Ian, cc'ing you to make you aware of this discussion, in case you 
aren't, and give you an opportunity to comment on your aim to adopt 
sysvinit package from some time ago.

KatolaZ, Ian feel free to drop Cc's again, I won't be offended :)

Alessio Treglia - 16.10.18, 07:31:
> On Mon, Oct 15, 2018 at 9:51 PM Enzo Nicosia  
wrote:
> > Please, just tell us who we should contact (current/last
> > maintainer?) to start working on that.
> 
> That's easy [1].
> 
> Thanks.
> 
> [1]
> https://qa.debian.org/developer.php?login=pkg-sysvinit-de...@lists.al
> ioth.debian.org

In addition to that

https://tracker.debian.org/pkg/sysvinit

gives a good overview of the state of the package.

Including the request for adoption that has been already mentioned in 
the thread:

RFA: sysvinit -- System-V-like init utilities - transitional package
https://bugs.debian.org/811377

(I reported the spam in that bug already.)

Also the changelog gives an impression who worked last on the packages:

https://tracker.debian.org/media/packages/s/sysvinit/
changelog-2.88dsf-59.11

Michael Biebl maintains Systemd and related packages and uploaded the 
last version mainly to activate some changes that benefit Systemd. Ian 
Jackson was the last one aiming at adopting the package, but apparently 
did not work on it afterwards anymore:

Re: Bug#811377: fixed in sysvinit 2.88dsf-59.9
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377#104

To me it looks like that the package is ready for adoption, as Petter 
also already mentioned:

Re: Debian Buster release to partially drop non-systemd support
https://lists.debian.org/debian-devel/2018/10/msg00171.html

For adopting it, one would need to become at least a Debian maintainer, 
or… have someone who sponsors uploads. For an easy start I think the 
sponsoring can work out nicely, but for a permanent solution its good to 
be allowed to upload new versions.

I'd suggest to write to sysvinit-devel mailinglist for any further 
coordination as I bet the larger audience of debian-devel is not really 
needed or helpful for that:

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sysvinit-devel

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 15/10/18 a les 16:18, Thorsten Glaser ha escrit:
> Several people have said they believe that to be the end of Devuan,
> and I concur, from what I’ve read.

https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

Martin Steigerwald writes:
> Ansgar Burchardt - 15.10.18, 16:03:
>> Please no.  I don't think it would help Debian to have toxic people
>> maintain packages.
>> 
>> (As an example, Devuan's infobot has fun facts like this one:
>> "<+infobot> 'sth is poettering' means it acts invasive, possessive,
>> destructive, and generally in an egocentric exacerbating negative way.
>> ``this cancer is extremely poettering'' [...]")
>
> Calling people "toxic" IMHO is quite similar to what Devuan's infobot 
> displays: Both are attacks on persons. And both are not helpful.

I'm also guilty of calling MikeeUSA a toxic person, also a horrible
personal attack.  For me enough Devuan-related people have managed to
end up in the same category by hard work.  I don't think it's
coincidence that the "VUA" liked MikeeUSA's writings about why systemd
is so evil.

If some people consistently call others a "cancer", accuse them of
"vandalizing" open source, spread obvious FUD and so on, then I don't
think they would fit in well in Debian's culture where they would have
to accept that packages such as systemd exist.

And no, it's not just that infobot factoid or just random people that are
totally unrelated to Devuan.

(Yes, I know Devuan eventually banned MikeeUSA for his writings.)

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Alessio Treglia]

On Mon, Oct 15, 2018 at 9:51 PM Enzo Nicosia  wrote:
> Please, just tell us who we should contact (current/last
> maintainer?) to start working on that.

That's easy [1].

Thanks.

[1] 
https://qa.debian.org/developer.php?login=pkg-sysvinit-de...@lists.alioth.debian.org

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

Re: Debian Buster release to partially drop non-systemd support

[Enzo Nicosia]

On Tue, Oct 16, 2018 at 09:16:37AM +0800, Paul Wise wrote:
> On Tue, Oct 16, 2018 at 12:18 AM Adam Borowski wrote:
> 
> > The main problem with sysvinit is the lack of a git repository.
> 
> There is an upstream git repository with commits up to September 2018:
> 
> http://savannah.nongnu.org/projects/sysvinit
> http://git.savannah.nongnu.org/cgit/sysvinit.git
> 

Indeed.

Sorry for the short presentation: another Devuan developer here (and
Debian user/admin/tinkerer since 1998).

I guess the bottom line of the discussion is: Devuan will keep
supporting sysvinit. Now, it would obviously be better to have this
support in Debian, so that all the Debian derivatives will
automatically benefit of it. This seems like "just the right time" to
do that. Please, just tell us who we should contact (current/last
maintainer?) to start working on that.

Otherwise, Devuan will keep supporting sysvinit nevertheless.

Best Regards

Enzo Nicosia

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Paul Wise]

On Tue, Oct 16, 2018 at 12:18 AM Adam Borowski wrote:

> The main problem with sysvinit is the lack of a git repository.

There is an upstream git repository with commits up to September 2018:

http://savannah.nongnu.org/projects/sysvinit
http://git.savannah.nongnu.org/cgit/sysvinit.git

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Buster release to partially drop non-systemd support

[Mattia Rizzolo]

On Mon, Oct 15, 2018 at 06:02:37PM +0200, Adam Borowski wrote:
> On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote:
> > I’ve volunteered to help out earlier in the thread, within constraints
> > (but rather that than to see things go and break).
> 
> The main problem with sysvinit is the lack of a git repository.  There's a
> massive amount of opportunities for drive-by contributions, but no way to
> collaborate doing so.

Seriously that's the main problem in your opinion?

:/

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Samuel Thibault]

Adam Borowski, le lun. 15 oct. 2018 18:02:37 +0200, a ecrit:
> On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote:
> > Matthew Vernon wrote:
> > >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).
> 
> The main problem with sysvinit is the lack of a git repository.

I guess we could just move on and create a collab-maint one?

Samuel

Re: Debian Buster release to partially drop non-systemd support

[Thorsten Glaser]

On Mon, 15 Oct 2018, Petter Reinholdtsen wrote:

> Note, I can with authority, as the person introducing dependency based
> boot and shutdown ordering in Debian, report that insserv were not
> introduced for parallell boot, nor for boot speed.  It was introduced to
> correct broken boot and shutdown ordering using a system wide reordering
> of every scripts at once.  This was needed as it proved impossible to
> get every package maintainer involved in a boot sequence reordering to
[…]

Ah, okay, thanks for the explanation.

> By all means, feel free to try to reintroduce the static sequence number
> ordering again, if you believe it is a sensible way forward.  I

With this extra information, I do not believe that any more.

> Just wanted to clear any misunderstanding about the use of insserv being
> related to speed and running scripts in parallell.  It is not true.
> Insserv provided correct ordering, and a byproduct was that correct
> ordering made it possible to run scripts in parallell for higher speed
> using startpar.

OK. I was using file-rc at the time those changes were introduced,
so they hit me only much later when file-rc was no longer viable at
all somehow, which is why I lacked that background info.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Re: Debian Buster release to partially drop non-systemd support

[Petter Reinholdtsen]

[Thorsten Glaser]
> 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

Note, I can with authority, as the person introducing dependency based
boot and shutdown ordering in Debian, report that insserv were not
introduced for parallell boot, nor for boot speed.  It was introduced to
correct broken boot and shutdown ordering using a system wide reordering
of every scripts at once.  This was needed as it proved impossible to
get every package maintainer involved in a boot sequence reordering to
lift together in a finite amount of time, where the last one in a
sequence had to change its number, before the second to last changed its
number, and so on and so forth.  There were lots of incorrect sequence
numbers in the boot and shutdown sequence before we introduced
dependency based boot ordering, and this was solved when we introduced
dependency based boot ordering.

By all means, feel free to try to reintroduce the static sequence number
ordering again, if you believe it is a sensible way forward.  I
recommend to use the dependency information provided in the packages to
verify you get it right.  The /usr/share/insserv/check-initd-order
script can be used to compare the sequence numbers with the
dependencies, to detect any errors.

After we introduced dependency based ordering, the sequence number that
used to be passed to update-rc.d was made obsolete, and it is not really
used any more.  This means the number, if it is provided, can no longer
be trusted.  The 'start/stop' arguments for update-rc.d is no longer
supposed and have not been supported for several years.  There is no
going back to static sequence numbers without changing around 1000
packages to add these sequence numbers back.  I wish you luck motivating
the maintainers to reinsert them.  Personally I was a very happy when I
did not have to pick a number between 00 and 99, and instead could just
state relationships with other init scripts.

Just wanted to clear any misunderstanding about the use of insserv being
related to speed and running scripts in parallell.  It is not true.
Insserv provided correct ordering, and a byproduct was that correct
ordering made it possible to run scripts in parallell for higher speed
using startpar.

-- 
Happy hacking
Petter Reinholdtsen

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Martin Steigerwald - 15.10.18, 17:56:
> Anyway, I will make Devuan people aware of this discussion. Let's see
> whether someone likes to cooperate.

As Evilham also pointed out, Devuan people are aware of this discussion 
already:

[devuan-dev] sysvinit in debian is under threat of being dropped for 
buster...
https://lists.dyne.org/lurker/thread/
20181015.095534.cb35153b.en.html#20181015.095534.cb35153b

And actually there is interest to cooperate.

Now, if people step over their own shadows… magic could happen.

Thanks,
-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Samuel Thibault]

Svante Signell, le lun. 15 oct. 2018 17:49:23 +0200, a ecrit:
> On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote:
> > It's a matter of people subscribing to the
> > pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there,
> > I
> > don't see why anything heavier would be needed.
> 
> I thought alioth was no more, but maybe the mailing list remains?

See https://alioth-lists.debian.net/
https://wiki.debian.org/Alioth/MailingListContinuation and
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo

Samuel

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote:
> 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…

elogind is an isolated part extracted from systemd-logind, maintained by Void
people, and in use by several other distributions (Gentoo, Devuan, etc).  It
is a drop-in replacement for interfaces exposed by libpam-systemd.

I'm using it for several months myself, and intended to package it in
Debian, but had a lack of tuits to do so.

I just started a new job and I think I'll have a small but non-zero amount
of tuits in the evenings, but havent't finished moving and can't comfortably
run anything that needs reasonable VMs (got nothing but a Pinebook with me),
so I can't be of much help -- but if anyone wants to start the work on
elogind, I'll try to do what I can.

> >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).

The main problem with sysvinit is the lack of a git repository.  There's a
massive amount of opportunities for drive-by contributions, but no way to
collaborate doing so.

Then, there are nice-looking new upstream releases of sysvinit (three in
this year, after several years of dormancy), but that'd require some real
testing.  Unlike elogind, it could perhaps reasonably be tested remotely...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Martin Steigerwald]

Ansgar Burchardt - 15.10.18, 16:03:
> On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote:
> > On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote:
> > > I believe Andreas Henriksson is right, the packages are going to
> > > be
> > > removed unless someone with time and interest show up to take care
> > > of
> > > them.  A good start would be to split initscripts off from the
> > > sysvinit binary packages, to let them live separate lives.  It
> > > will be sad, but the proper way for Debian to handle unmaintained
> > > packages in a sad state.
> > 
> > Is it worth interested parties reaching out to the Devuan project
> > regarding person-power for sysvinit maintenance?
> 
> Please no.  I don't think it would help Debian to have toxic people
> maintain packages.
> 
> (As an example, Devuan's infobot has fun facts like this one:
> "<+infobot> 'sth is poettering' means it acts invasive, possessive,
> destructive, and generally in an egocentric exacerbating negative way.
> ``this cancer is extremely poettering'' [...]")

Calling people "toxic" IMHO is quite similar to what Devuan's infobot 
displays: Both are attacks on persons. And both are not helpful.

Anyway, I will make Devuan people aware of this discussion. Let's see 
whether someone likes to cooperate.

-- 
Martin

Re: Debian Buster release to partially drop non-systemd support

[Svante Signell]

On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote:
> 
> It's a matter of people subscribing to the
> pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there,
> I
> don't see why anything heavier would be needed.

I thought alioth was no more, but maybe the mailing list remains?

Re: Debian Buster release to partially drop non-systemd support

[Samuel Thibault]

Evilham, le lun. 15 oct. 2018 16:27:25 +0200, a ecrit:
> Where to now?
> At devuan-dev, Adam Sampson has suggested that the debian-bsd and
> debian-hurd communities are also very interested in keeping non-systemd
> things working,

Yes, but they aren't populated so much either, with already a lot of
things in their plate.

> which is why I'd hope this won't end up in non-systemd
> support being dropped, but that this thread becomes the distress call
> that the topic needed.
> 
> If I had to guess, this requires some organisation first, and since it
> may require cross-communities organisation it may be somewhat tricky.

It's a matter of people subscribing to the
pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there, I
don't see why anything heavier would be needed.

Samuel

Re: Debian Buster release to partially drop non-systemd support

[Evilham]

Dear debian-devel,

Am 15/10/2018 um 15:20 schrieb Jonathan Dowland:
> [ 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… ]
> 
> On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote:
>> I believe Andreas Henriksson is right, the packages are going to be
>> removed unless someone with time and interest show up to take care of
>> them.  A good start would be to split initscripts off from the sysvinit
>> binary packages, to let them live separate lives.  It will be sad, but
>> the proper way for Debian to handle unmaintained packages in a sad
>> state.
> 
> Is it worth interested parties reaching out to the Devuan project
> regarding person-power for sysvinit maintenance? As a derivative
> distribution, I imagine their lives would become much harder if we did
> drop sysvinit; they would have to pay the cost of maintaining the
> sysvinit package themselves (which is what I am proposing they do now)
> *as well* as a rapidly growing delta of sysvinit-support/initscripts in
> lots of other packages, as they steadily rotted in Debian.

it's my first time writing to this ML, which calls for a quick
hello/intro and the FYI that I intended to send:

The quick hello/intro:
I go on the internet by Evilham and have been using Debian for ages.
When it was time for me to give back to the community, systemd and
Devuan were both already a thing, and things ended up bringing me to
help Devuan first.

The FYI:
Devuan is not blind to this topic or reticent to contributing in Debian,
the discussion is indeed taking place over at devuan-dev and, without
having discussed it thoroughly yet, many are of the opinion that it *is*
in everyone's best interest to keep the packages in Debian, and in a
good state.

https://lists.dyne.org/lurker/message/20181015.100838.2018520a.en.html

At least personally speaking, there is interest in helping Debian from
Devuan, as most of us see that there is big benefit in both distros.

However, as you are aware, maintaining a distro is a lot of work (BTW:
thank you all for your contribution to Debian), there have been
priorities other than supervising state of packages in Debian.

I don't think many were aware of the state of things and that this was
the path these (very critical) packages were following in Debian.


Where to now?
At devuan-dev, Adam Sampson has suggested that the debian-bsd and
debian-hurd communities are also very interested in keeping non-systemd
things working, which is why I'd hope this won't end up in non-systemd
support being dropped, but that this thread becomes the distress call
that the topic needed.

If I had to guess, this requires some organisation first, and since it
may require cross-communities organisation it may be somewhat tricky.

From Devuan's side, there is a weekly meeting happening on (UTC)
Wednesday evening, where this will surely be a big topic.

Just letting you know, things are moving (albeit somewhat late and slowly).

Best regards,
-- 
Evilham



signature.asc
Description: OpenPGP digital signature

Re: Debian Buster release to partially drop non-systemd support

[Thorsten Glaser]

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

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote:
> On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote:
> > I believe Andreas Henriksson is right, the packages are going to be
> > removed unless someone with time and interest show up to take care of
> > them.  A good start would be to split initscripts off from the sysvinit
> > binary packages, to let them live separate lives.  It will be sad, but
> > the proper way for Debian to handle unmaintained packages in a sad
> > state.
> 
> Is it worth interested parties reaching out to the Devuan project
> regarding person-power for sysvinit maintenance?

Please no.  I don't think it would help Debian to have toxic people
maintain packages.

(As an example, Devuan's infobot has fun facts like this one:
"<+infobot> 'sth is poettering' means it acts invasive, possessive,
destructive, and generally in an egocentric exacerbating negative way.
``this cancer is extremely poettering'' [...]")

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Andrey Rahmatullin]

On Mon, Oct 15, 2018 at 02:20:03PM +0100, Jonathan Dowland wrote:
> Is it worth interested parties reaching out to the Devuan project
> regarding person-power for sysvinit maintenance? 
It's hard to discuss this with a straight face, but in any case even they
admit they don't have any person-power:
http://maemo.cloud-7.de/irclogs/freenode/_devuan-dev/_devuan-dev.2018-09-05.log.html

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

[ 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… ]

On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote:

I believe Andreas Henriksson is right, the packages are going to be
removed unless someone with time and interest show up to take care of
them.  A good start would be to split initscripts off from the sysvinit
binary packages, to let them live separate lives.  It will be sad, but
the proper way for Debian to handle unmaintained packages in a sad
state.


Is it worth interested parties reaching out to the Devuan project
regarding person-power for sysvinit maintenance? As a derivative
distribution, I imagine their lives would become much harder if we did
drop sysvinit; they would have to pay the cost of maintaining the
sysvinit package themselves (which is what I am proposing they do now)
*as well* as a rapidly growing delta of sysvinit-support/initscripts in
lots of other packages, as they steadily rotted in Debian.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to debian-devel.

Re: Debian Buster release to partially drop non-systemd support

[Matthew Vernon]

Holger Levsen  writes:

> On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
>> > Has policy changed regarding support for multiple inits, or is it just that
>> > no one is maintaining the shim and sysvinit-core?
>> 
>> The latter.  systemd-shim has been orphaned for over 2 years, and has
>> RC bugs.   sysvinit currently has two maintainers, but they've only
>> ever made one upload (over a year ago).
>
> It seems that these facts are either largely ignored or unknown and I
> wonder if some noise should be made so that interested people can pick
> up the work now and not only complain later.

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
interest/effort in getting sysvinit (and related bits) in a better state
for buster, do drop me a line.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

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 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.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.