Re: Integration with systemd

[Marco d'Itri]

On Oct 31, "Theodore Y. Ts'o"  wrote:

> handled on a case by case basis.  Exactly how much of a win do we get
> if we use a particular systemd feature in core Debian packaging?  How
> hard is it to emulate that for non-systemd systems?  I don't think
> that decision can be made in the abstract, unless we as an entire
> project want to vote to deliberately, and with malice aforethought,
> kill off sysvinit support in Debian.
We have already voted with apt: less than 1% of new installs use 
sysvinit. If you do not believe that 1% is low enough, then how low do 
you want to put the bar?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

RFC: How about using MRs to communicate the diffs for NMUs with an MR

[Gert Wollny]

Dear all,

with salsa and most of the packaging going on in git I wonder whether 
we could add using MRs as an alternative way to communicate the diff
that is related to an NMU instead of adding a patch to the related bug.

When preparing an NMU people  might already be using git anyway, and if
one uses a fork of the packaging repo submitting the NMU diff as an MR
comes naturally, and also makes it easy to review the changes in salsa,
and to accept them (or not).

Maybe one could even add a webhook for MRs that send a message to the
BTS to provide a link when the MR message mentions a bug that is fixed
in the MR message or the commits it includes (similar to the one  that
sends a message when a bugfix is pushed to a packaging repository).  

With that the wording of the second sentence in the paragraph of 5.11.1
the policy would change to something like:

"Then, you either prepare the NMU in a fork of the original packaging
repository and submit a merge request referencing the bug you are
fixing, or send a patch containing the differences between the current
package and your proposed NMU to the BTS."

What do you think about this? 

Thanks, 
Gert

Re: Integration with systemd

[Simon Richter]

Hi,

On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:

> One can individually say that one doesn't care about those features, but
> we just cannot say Debian as a whole should not care about those features.
> It doesn't work.  We have to take an affirmative stance on what Debian is
> going to do with software that does care about and use those features;
> whether we're committing to porting it, whether we're going to kick it out
> of the archive (that seems highly unlikely to be viable), whether we're
> going to say that software with a hard dependency on systemd features is
> allowed to only work on systems running systemd, or some other
> alternative.

>From an integration point of view we need to make sure that software that
is installed also works, and I have little trouble when packages declare an
explicit dependency on systemd running as pid 1. They need to declare a
dependency nonetheless, because init systems have never been Essential, and
also because the dependency likely needs a minimum version.

There is no point for Debian in taking a stance against using systemd
features, because upstreams will do that anyway, and we neither have the
manpower as a volunteer project to provide alternatives, nor as a
distribution the duty to.

Our goal is to provide packages that allow you to put together a working
system. If upstream decides that their software will only work with
systemd, we make note of that and move on. We already have enough work to
deal with the fallout in our own infrastructure -- I've mentioned
earlier[1] that libgtk-3-0 pulls in systemd-sysv, so autobuilders will
install it quite often, and we need to make sure this doesn't break
anything.

However, a lot of our software comes from the BSD world and will never
fully switch to systemd, and that software is often used in server contexts
by people who know exactly what they are doing. I don't see why we
shouldn't support these people anymore, especially as they are the ones who
cannot be served equally well by other distributions.

> > That's leaving aside that a reimplementation of systemd's features will
> > tend towards becoming systemd, and we have one of those already. What is
> > the actual goal?

> The actual goal is to allow for different ecosystems that provide the same
> features while embracing different implementation philosophies.

Not quite, I think. The goal is to allow people to omit complexity from
features they will not use. My laptop will never automount USB sticks, so
the code path for that doesn't even need to exist. My web server will die
in a horrible way if someone finds a buffer overflow in the SSL code, and
it will stay down until I can manually investigate, there is no code path
that will give the attacker another chance to get the offset right.

The freedom to configure a system without things I do not want is one of
the main reasons that made me switch over from Windows to Debian, a bit
more than twenty years ago.

> 1. Do we as a project want to do the work to leave open the possibility
>that such resources will materialize?  This means doing things like
>defining a subset of systemd unit features that packages can rely on,
>and requiring (some? all?) packages not use features outside of that
>set.  "No" is a possible answer here, but this is a political question
>with significant consequences, and I think it should be decided
>democratically.

That is work we have to do regardless of whether we want to support
alternatives or not, but in the simple case we just list what is supported
by the systemd version we have decided to ship in the last stable release,
so we can have backport packages with reasonable effort.

Infrastructure I'd like to see is

 - dh_systemd generating a versioned dependency for the unit files given

 - apt being able to blacklist packages and hide packages that depend on
   those

This cuts both ways: for packages with optional systemd integration, I'd
expect "sysvinit" variants to pop up, and we don't want users running
systemd to accidentally install these if a tighter integrated variant is
available.

> 2. Are we as a project *capable* of producing a non-systemd alternative
>that's viable?  If the answer to question 1 is "no," then this question
>doesn't arise.  But it's entirely possible that the answer to question
>1 is "yes" but the answer to this question is still "no."

No, and that's not our job. There are a lot of people out there building
non-systemd systems. We do what we've always done, packaging them to the
best of our ability.

   Simon

[1] https://lists.debian.org/debian-devel/2019/08/msg00278.html

Re: [RFC] Proposal for new source format

[Ian Jackson]

Sean Whitton writes ("Re: [RFC] Proposal for new source format"):
> Sorry, I didn't phrase my suggestion carefully.  I was assuming that we
> will continue to expect maintainers to accept patches in the BTS, but
> that if they *prefer* something else, they could document that in
> README.source.
> 
> Someone making a large number of changes could just choose to submit
> them all as patches to the BTS, due to the high cost of checking
> README.source -- I'm sure maintainers would understand this.

Well, that's fair enough as far as it goes.  But I think we could do
better.

It would be possible to imagine some service that works like this:

 * NMUer does dgit clone, makes changes, does tag2upload with some
   option (ie a parseable note in the git tag) to say "automatically
   do the NMU things"

 * tag2upload service, or some related service:
- determines that the maintainer is using a dgit-compatible git
  workflow, by looking at the tags, and looks at some in-dsc
  metadata to find the maintainer's repo
- determines that the maintainer is using salsa or launchpad,
  converts the NMU to the maintainer branch's format, and
  submits an MR
- files a Debian bug referencing the MR
- if the preconditions are not satisfied, sends a traditional
  debdiff by email to the BTS instead

 * Maintainer looks at the MR.  (If discussion is needed they do it in
   the bug [1].)  Maintainer merges the branch to master.

 * git hosting service autocloses the MR.  Metadata gateway service
   marks the Debian bug pending.

I think this would give us most of the best of the various possible
worlds.  (You could also do most of this without the actual upload of
course.  Such an canonical-view-to-maintainer-MR gateway would already
be possible, and would work when the maintainer used dgit.)

Ian.

[1] IMO bugs are better for this because they provide a less bitty
conversational structure and are archived and published more usefully.
But it would be possible to handle this via the hosting system MR
conversation instead, or maybe mirror the conversation.

-- 
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: TZ=UTC wrong?

[Michael Stone]

On Wed, Oct 30, 2019 at 05:01:56PM +0100, Guillem Jover wrote:

This indeed works in Debian, but I think it's strictly speaking
incorrect according to POSIX, and as such is non-portable.


It's non portable in a way which hasn't been relevant in more than 20 
years and as such isn't worth wasting time over. The POSIX TZ spec is 
irrelevant to real systems except insofar as it can be used to explain 
unexpected behavior when people make a typo.

Re: Integration with systemd

[Ansgar]

Simon Richter writes:
> On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:
>
>> One can individually say that one doesn't care about those features, but
>> we just cannot say Debian as a whole should not care about those features.
>> It doesn't work.  We have to take an affirmative stance on what Debian is
>> going to do with software that does care about and use those features;
>> whether we're committing to porting it, whether we're going to kick it out
>> of the archive (that seems highly unlikely to be viable), whether we're
>> going to say that software with a hard dependency on systemd features is
>> allowed to only work on systems running systemd, or some other
>> alternative.
>
> From an integration point of view we need to make sure that software that
> is installed also works, and I have little trouble when packages declare an
> explicit dependency on systemd running as pid 1.

Such a dependency doesn't work well with services installed in
containers which can still access stuff outside the container.
Or services started by a user (who doesn't have to use the provided
system integration).

> They need to declare a
> dependency nonetheless, because init systems have never been Essential, and
> also because the dependency likely needs a minimum version.

No: init systems have been essential until systemd (or init) replaced
sysvinit.

Note that there are other cases where we don't have explicit
dependencies such as depending on the Linux kernel itself, even though
some programs require minimum versions (including glibc).

> However, a lot of our software comes from the BSD world and will never
> fully switch to systemd, and that software is often used in server contexts
> by people who know exactly what they are doing. I don't see why we
> shouldn't support these people anymore, especially as they are the ones who
> cannot be served equally well by other distributions.

Sure, you can just not install any init system.  This doesn't require
Debian to support other init systems and provide integration with them.

> Infrastructure I'd like to see is
>
>  - dh_systemd generating a versioned dependency for the unit files
>  given

That makes supporting other init systems even less possible as
everything shipping any systemd service will start to pull in systemd,
even though one might not use it to start the service.

I think this is not a good idea.

>  - apt being able to blacklist packages and hide packages that depend on
>those

Implicitly hiding some packages seems very confusing.

Ansgar

Re: Integration with systemd

[Ansgar]

Russ Allbery writes:
> Josh Triplett  writes:
>
>> Part of the problem is that the people interested in sysvinit don't tend
>> to care about those features and often argue that others shouldn't care
>> either, and the people interested in those features don't tend to care
>> about sysvinit. It's difficult to motivate people to work on
>> alternatives for a system they already have and prefer.
>
> *This* is the thing that I feel we need to tackle head-on.  Because there
> are a lot of reasons to care about those features, but possibly more
> convincingly, as Ted points out, *upstreams* care about those features and
> are not going to stop caring about those features just because Debian
> packagers do not.

But many people *don't* care.  See the history of consolekit and
systemd-shim which nobody wanted to maintain and then were unhappy when
they were eventually gone...  The argument there has always been "I
don't care about these features", but upstream projects used them and
eventually systemd was the only implementation.

>> It seems evident based on the history of such efforts that there is
>> *not* sufficient people/interest/motivation to reimplement the majority
>> of systemd features, let alone doing so in a way that meets the
>> additional constraints imposed on such solutions.
>
> I don't think the question has yet been forced.  Up through buster, one
> has been able to mostly run Debian on sysvinit without doing this work,
> with some pain and some gaps and some issues.  I think we're coming up to
> a point where this issue will be forced because both packaging practices
> and upstreams are diverging away from sysvinit support.
>
> I think there are two questions here:
>
> 1. Do we as a project want to do the work to leave open the possibility
>that such resources will materialize?  This means doing things like
>defining a subset of systemd unit features that packages can rely on,
>and requiring (some? all?) packages not use features outside of that
>set.  "No" is a possible answer here, but this is a political question
>with significant consequences, and I think it should be decided
>democratically.

Is there someone willing to do the work you envision?  If not, what
would be the use of deciding about it democratically?

I think we shouldn't spend large amounts of resources to provide support
for such a hypothetical possibility.

I can imaging doing the same for other system interfaces, such as
mandating only a subset of the Linux kernel API to be used to support
alternative implementations of that API.  These already exist,
e.g. Microsoft's Linux subsystem (the old one) and I believe BSDs also
can pretend to be a Linux kernel.

We could also standardize the libc ABI to allow alternative
implementations, or at least not use non-standard extensions that make
replacing glibc harder.

I don't see why systemd should be treated different from other parts of
Debian.

> 2. Are we as a project *capable* of producing a non-systemd alternative
>that's viable?  If the answer to question 1 is "no," then this question
>doesn't arise.  But it's entirely possible that the answer to question
>1 is "yes" but the answer to this question is still "no."

I don't really believe writing init systems is Debian's goal, just like
implementing our own X server or other stuff.

That other implementations that use systemd's unit files might be
useful, but so far no other implementation has come into existence for
years.

Ansgar

Re: Integration with systemd

[Martin Steigerwald]

Hi!

I thought about just silently unsubscribing from debian-devel… but as I 
got the impression that almost no one argues for the freedom to choose 
the init system here in this thread, I decided to speak up:

Theodore Y. Ts'o - 31.10.19, 00:57:48 CET:
> And if we do this in core Debian infrastructure, such as say, in dpkg,
> then that's *really* different.  That's completely ruling out
> sysvinit.  And that to me is different from something like "GNOME no
> longer works on sysvinit" (until someone enhances elogind).  In that
> case, it's the GNOME Project which screwed over sysvinit, not Debian
> --- and we're just saying that it's not the GNOME Debian packaging
> team which is obligated to fix things up.
> 
> But the dpkg maintainer making a change which screws over sysvinit
> *feels* different, both in that it affects all Debian installations,
> versus just the ones using a particular GUI, and whether it was Debian
> or GNOME that made that particular decision.
> 
> Let me be clear, my personal opinion is that Lennart, and the
> acceptance of systemd by the vast majority of the major distributions,
> means that eventually, most upstreams will be using more and more
> systemd features, and people who like sysvinit should just get over
> it.  But whether we should accelerate that transition, or let it
> happen at a more natural pace, is something which IMHO, needs to be
> handled on a case by case basis.  Exactly how much of a win do we get
> if we use a particular systemd feature in core Debian packaging?  How
> hard is it to emulate that for non-systemd systems?  I don't think
> that decision can be made in the abstract, unless we as an entire
> project want to vote to deliberately, and with malice aforethought,
> kill off sysvinit support in Debian.

While I do not expect maintainers of Debian packages to implement 
support for alternate init systems themselves, I still believe if 
someone works constructively and consistently on making such support 
available in Debian, it would be good to be inclusive enough to allow 
him or her to do this work and find a good way to integrate.

Like with elogind.

Refusing to work together constructively due to emotional exhaustion 
even tough Mark did all he can to remain as constructive and supportive 
as he could… is understandable, but ultimately does not help and may 
ultimately alienate those who use Debian with an alternative init 
system.

For me one of the core issues is that with how systemd is designed it 
can be challenging to find a win-win solution, at least if you like to 
use all its features. Systemd appears to be an all-or-nothing-approach. 
And thus the analogy you made, Ted, that Josh judged and silenced as 
"gratuitous flame" appeared to be perfectly valid to me as for it 
described what I see happening here. In this concrete example Mark came 
up with several such win-win solutions to the best of his ability 
anyway.

Making core Debian infrastructure dependent on Systemd will very likely 
alienate me away from Debian. This laptop, for the sake of packaging 
flexible I/O tester, is the last of my machines still running on Debian. 
All the others are running Devuan. I am not looking back. I have no 
intention what so ever to switch back to Systemd again. For that reason 
I for example use unbound instead of knot-resolver. Cause I still have a 
choice which upstream projects to choose. If I would not be able to run 
Debian with sysvinit or runit in the end I might also drop my packaging 
and at least some other contributions to Debian at one point in time. If 
Debian is not inclusive enough for me to run it the way I like it to, 
what is the point of contributing to it any longer unless I can still 
use the Debian packaging as a base for the package in Devuan?

Making core Debian infrastructure dependent on Systemd would also deepen 
the split between Debian and Devuan. So far it has been possible to keep 
the differences at a minimum, making Devuan more of a slight variation to 
Debian instead of a fork that would develop in a different direction. 
Keeping the differences minimal is also an intention of Devuan project 
members as far as I got.

As for upstream I'd wait for what actually would really happen instead 
of trying to predict the future. So far, I am able to run all I need on 
sysvinit and/or openrc+sysvinit based systems. Others are to¹. That even 
includes third party software like rspamd, now available in Debian too, 
and I also expect the Elastic Stack to work. Cause in the end, most of 
them are services which do not really care for how they have been 
started.

Also the KDE project shows no signs limiting itself to Systemd based 
systems. The Plasma desktop needs some logind, but that is basically it. 
I expect that to stay this way at least for as long as FreeBSD is 
supported and quite some KDE applications even run and in part are also 
supported on Windows. For the KDE project portability is a feature not a 
hindrance.

Even

Re: Integration with systemd

[Martin Steigerwald]

Martin Steigerwald - 31.10.19, 13:19:56 CET:
> While I do not expect maintainers of Debian packages to implement
> support for alternate init systems themselves, I still believe if
> someone works constructively and consistently on making such support
> available in Debian, it would be good to be inclusive enough to allow
> him or her to do this work and find a good way to integrate.
> 
> Like with elogind.
> 
> Refusing to work together constructively due to emotional exhaustion
> even tough Mark did all he can to remain as constructive and
> supportive as he could… is understandable, but ultimately does not
> help and may ultimately alienate those who use Debian with an
> alternative init system.

As to this, I did not yet see that the migration of elogind to testing 
has been accepted.

Thank you very much, Sam, Ian, Mark!

However, as to the broader topic of integrating with systemd, what I 
wrote still applies.

Best,
-- 
Martin

Re: Integration with systemd

[Ian Jackson]

Martin Steigerwald writes ("Re: Integration with systemd"):
> As to this, I did not yet see that the migration of elogind to testing 
> has been accepted.

Yes.

I find these conversations draining, exhausting, awful.  I am sure
that most people who are sceptical of systemd agree.  The constant
negging and doom-saying is very unpleasant.

Meanwhile, elsewhere, where the real technical work is being done,
systems are being built that run modern software (including GNOME,
whatever the latest daemons, etc.) without systemd.

The question is: are we going to permit those technical contributions
into Debian ?  Are we going to keep making it awkward or are we
actually going to _welcome_ them ?

Are we going to say to those of our contributors who want to see a
nice tidy hegemony, "sure, throw all the sysvinit stuff away, it is OK
to reject the patches with init scripts, it is OK to work to make it
impossible to have this stuff in Debian, even if the software works" ?

And, are we going to continue to wear people down with awful threads
like this one, where a parade of doomsayers tell us we can't have what
we want *even though it already exists and is maintained* ?

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.

Bug#943892: ITP: python-backcall -- Specify callback function signatures for Python

[Gordon Ball]

Package: wnpp
Severity: wishlist
Owner: Gordon Ball 

* Package name: python-backcall
  Version : 0.1.0
  Upstream Author : Thomas Kluyver
* URL : https://github.com/takluyver/backcall
* License : BSD
  Programming Lang: Python
  Description : Specify callback function signatures for Python

This is a small library for annotating callback functions in Python.

This is a new dependency for upgrading IPython.

It will be maintained under the DPMT aegis.

Q: what's the blocker for firefox-esr update migrates to testing

[Hideki Yamane]

Hi,

 firefox-esr package doesn't migrate to testing but I cannot
 find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
 
 Could someone tell me why, please?


-- 
Hideki Yamane 

Re: Q: what's the blocker for firefox-esr update migrates to testing

[The Wanderer]

On 2019-10-31 at 10:25, Hideki Yamane wrote:

> Hi,
> 
>  firefox-esr package doesn't migrate to testing but I cannot
>  find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
>  
>  Could someone tell me why, please?

Quoted from that page:

>> Issues preventing migration:
>> firefox-esr unsatisfiable Build-Depends(-Arch) on armel: nodejs (>= 8.11)
>> missing build on armel

That seems clear enough to me, although I haven't looked into the
reasons why that dependency can't currently be satisfied on that
architecture.

-- 
   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: Q: what's the blocker for firefox-esr update migrates to testing

[Boyuan Yang]

According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
esr build-depends on nodejs, which is not available on armel anymore
(explicitly not built on armel). Since armel is an release architecture,
firefox-esr won't migrate to Testing when its armel build is missing.

The excuses page also shows some missing new versions of rust packages not
migrated yet but I assume it a temporary issue.

These are not good signs, especially when both firefox-esr and chromium in
Testing are notably outdated.

-- 
Regards,
Boyuan Yang

在 2019-10-31四的 23:25 +0900，Hideki Yamane写道：
> Hi,
> 
>  firefox-esr package doesn't migrate to testing but I cannot
>  find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
>  
>  Could someone tell me why, please?


signature.asc
Description: This is a digitally signed message part

Re: Integration with systemd

[Marco d'Itri]

On Oct 31, Simon Richter  wrote:

> However, a lot of our software comes from the BSD world and will never
> fully switch to systemd, and that software is often used in server contexts
> by people who know exactly what they are doing. I don't see why we
> shouldn't support these people anymore, especially as they are the ones who
> cannot be served equally well by other distributions.
Because by using systemd features in the Debian packaging we make better 
packages: simpler to maintain and more robust.

(And then everything else that Ansgar patiently explained.)

> The freedom to configure a system without things I do not want is one of
> the main reasons that made me switch over from Windows to Debian, a bit
> more than twenty years ago.
http://www.islinuxaboutchoice.com/

> That is work we have to do regardless of whether we want to support
> alternatives or not, but in the simple case we just list what is supported
> by the systemd version we have decided to ship in the last stable release,
> so we can have backport packages with reasonable effort.
It is not obvious to me why we would need a different policy for systemd 
than for other packages which backports may depend on.

> No, and that's not our job. There are a lot of people out there building
> non-systemd systems.
Data says: not really a lot.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Q: what's the blocker for firefox-esr update migrates to testing

[Paolo Greppi]

FYI: https://bugs.debian.org/818552#15

P.

On 31/10/19 16:08, Boyuan Yang wrote:
> According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
> esr build-depends on nodejs, which is not available on armel anymore
> (explicitly not built on armel). Since armel is an release architecture,
> firefox-esr won't migrate to Testing when its armel build is missing.
> 
> The excuses page also shows some missing new versions of rust packages not
> migrated yet but I assume it a temporary issue.
> 
> These are not good signs, especially when both firefox-esr and chromium in
> Testing are notably outdated.

Re: Integration with systemd

[Theodore Y. Ts'o]

On Thu, Oct 31, 2019 at 01:19:56PM +0100, Martin Steigerwald wrote:
> alienate me away from Debian. This laptop, for the sake of packaging 
> flexible I/O tester, is the last of my machines still running on Debian. 
> All the others are running Devuan. I am not looking back. I have no 
> intention what so ever to switch back to Systemd again. For that reason 
> I for example use unbound instead of knot-resolver. Cause I still have a 
> choice which upstream projects to choose. If I would not be able to run 
> Debian with sysvinit or runit in the end I might also drop my packaging 
> and at least some other contributions to Debian at one point in time.

I think there was mis-undrestanding about what I was trying to say.
My basic premise is that we can't *force* people to work on
technology.  Debian is a volunteer organization.  So we can't force
people to work on improving elogind.

However, that's *different* from adopting new dependencies on systemd
as part of Debian packaging or core Debian packages.  If KDE or GNOME
wants to add new systemd dependencies, that's GNOME's or KDE's
decision.  But if Debian decides to do something which makes it harder
for sysvinit, we need to think ***really** hard about whether it's
worth it, and I would claim the default answer is we shouldn't make
the change unless there are darned good reasons to do so.

It may be that sysvinit is doomed.  But we shouldn't be accelerating
the process.

- Ted

Re: Q: what's the blocker for firefox-esr update migrates to testing

[Aron Xu]

On Thu, Oct 31, 2019 at 11:09 PM Boyuan Yang  wrote:
>
> According to https://qa.debian.org/excuses.php?package=firefox-esr , firefox-
> esr build-depends on nodejs, which is not available on armel anymore
> (explicitly not built on armel). Since armel is an release architecture,
> firefox-esr won't migrate to Testing when its armel build is missing.
>

This could be a reminder that we should start thinking about whether
we want to keep armel as a release architecture for bullseye.

Cheers,
Aron

Bug#943904: ITP: uwsgi-apparmor -- apparmor plugin for uwsgi

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: uwsgi-apparmor
  Version : 0.0.0+git.2014.09.15.7d6d7bd7eb
  Upstream Author : Unbit 
* URL : https://github.com/unbit/uwsgi-apparmor
* License : Expat
  Programming Lang: C, Python
  Description : apparmor plugin for uwsgi

 uWSGI presents a complete stack for networked/clustered web applications,
 implementing message/object passing, caching, RPC and process management.
 It uses the uwsgi protocol for all the networking/interprocess communications.
 .
 This package provides a plugin to apply AppArmor profiles to uwsgi
 applications.

My intention is to add AppArmor profiles to most OpenStack services.

Re: Integration with systemd

[Martin Steigerwald]

Theodore Y. Ts'o - 31.10.19, 16:03:29 CET:
> On Thu, Oct 31, 2019 at 01:19:56PM +0100, Martin Steigerwald wrote:
> > alienate me away from Debian. This laptop, for the sake of packaging
> > flexible I/O tester, is the last of my machines still running on
> > Debian. All the others are running Devuan. I am not looking back. I
> > have no intention what so ever to switch back to Systemd again. For
> > that reason I for example use unbound instead of knot-resolver.
> > Cause I still have a choice which upstream projects to choose. If I
> > would not be able to run Debian with sysvinit or runit in the end I
> > might also drop my packaging and at least some other contributions
> > to Debian at one point in time.
> I think there was mis-undrestanding about what I was trying to say.
> My basic premise is that we can't *force* people to work on
> technology.  Debian is a volunteer organization.  So we can't force
> people to work on improving elogind.

Sure. I totally get that. I replied to your mail, since you mentioned 
that for you integrating Debian core infrastructure like dpkg or apt 
with Systemd would be something new and different. So while I chose your 
mail to reply to as you summarized this so accurately, I really 
responded to the intention to use Systemd features within core Debian 
packages.

> However, that's *different* from adopting new dependencies on systemd
> as part of Debian packaging or core Debian packages.  If KDE or GNOME
> wants to add new systemd dependencies, that's GNOME's or KDE's
> decision.  But if Debian decides to do something which makes it harder

Sure. For KDE I am pretty confident they won't. And if they would… I and 
others would probably speak out loudly that this may not be such a good 
idea.

> for sysvinit, we need to think ***really** hard about whether it's
> worth it, and I would claim the default answer is we shouldn't make
> the change unless there are darned good reasons to do so.

I fully second this. 

> It may be that sysvinit is doomed.  But we shouldn't be accelerating
> the process.

Or it may not be.

It is similar with "the" cloud. All say it will disrupt everything 
around… and it does. Yet, there are attempts to disrupt the cloud 
already by making machines powerful enough that they do not need a 
centralized cloud provider even if storing a huge lot of data.

Or with the climate.

I can respond to things like this in a way "Oh, we are doomed it does 
not make sense to do anything about it" or say "Let's challenge this and 
see what comes out of it". For the climate it is of course way more 
important to challenge how we are doing things, but it has been and will 
continue to be challenged for Systemd as well.

And yes, in a way Systemd challenged the status quo. As well as "the" 
cloud. But eventually both will be challenged again.

As for Debian for me the question would also be: Are we just following 
the lead of other distributions? Or are we actually inventing things not 
seen elsewhere. Just implementing more of Systemd integration would not 
be anything new. Others have been there before. What makes Debian unique 
these days if not the community?

-- 
Martin

Re: Integration with systemd

[Martin Steigerwald]

Marco d'Itri - 31.10.19, 15:45:47 CET:
> On Oct 31, Simon Richter  wrote:
[…]
> > The freedom to configure a system without things I do not want is
> > one of the main reasons that made me switch over from Windows to
> > Debian, a bit more than twenty years ago.
> 
> http://www.islinuxaboutchoice.com/

I kindly ask you to stop repeating old arguments.

We have been there before and if this is about throwing links around… I 
can for sure throw in a dozen links how and why using something else 
than Systemd would be better, including with more links to more pages 
and so on.

Please, we have been there before and there is no need to go there 
again.

Can you just agree to disagree so we can see where to go from there?

Please stop making this another thread pro and contra Systemd.

-- 
Martin

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

Russ,

On 10/29/19 11:19 PM, Russ Allbery wrote:
> [...] we do not have clear
> project consensus that sysvinit support is mandatory in new packages, so
> the support is starting to bitrot, and given the lack of clear project
> guidance, no one is clearly empowered to prevent it from bitrotting.

I think we mostly agree on the topic, but now what the consensus is.

My understanding is that the current guidance is that doing init script
isn't mandatory. What is mandatory, is to ACK init scripts / patches
when contributed (through the BTS).

I think that's fair enough for everyone, and I don't see why we need to
change anything to this rule.

> The current Policy text is a mess, and everything it says on the topic is
> essentially accidental, being left over from text that was added to
> clarify how to support upstart, before the TC decision on the default init
> system.  It's unclear what requirements Policy should actually set on
> packages that want to ship daemons, and any attempt to hammer that out is
> likely to be contentious and have great difficulty reaching consensus.

Sure, the Debian policy text needs some love and contributions, though
what I wrote above is more or less what we all agreed on. Besides this,
the state of the policy is (unfortunately, and because the policy needs
updates) orthogonal to this discussion.

> I think it was the right thing to do to refuse to make a clear long-term
> decision at the time, when the project had just gone through a bruising
> and awful argument.  Now that we have some distance and have seen how the
> ecosystem has subsequently evolved, I think it's time to circle back and,
> hopefully with more accumulated wisdom, a bit of emotional distance, and a
> bit more calm, make the deferred decision.

Make what deferred decision? That we want to actively dismiss patches
adding init script support? This IMO would just destroy any work
attempted in the non-linux ports, or anyone willing to add support for a
new init system. I don't think that's fair for these. Voting them out
would not feel right.

> If we're really going to continue to fully support sysvinit

As much as I understand, we never wrote or decided we would. We just
need to accept patches to add or fix sysv-rc scripts. What makes you
think sysv-rc scripts are mandatory?

Thomas Goirand (zigo)

Re: Q: what's the blocker for firefox-esr update migrates to testing

[Carsten Schoenert]

Am 31.10.19 um 16:28 schrieb Aron Xu:

This could be a reminder that we should start thinking about whether
we want to keep armel as a release architecture for bullseye.


No, but some X-based applications might simply get excluded from the 
that architecture. There are still a lot armv5 based hardware outside 
which is simply working fine with recent Debian releases. I see no real 
reason to make all this hardware obsolete simply because some software 
which requires some X features isn't build-able on armel.


--
Regards
Carsten Schoenert

Re: Integration with systemd

[Josh Triplett]

Russ Allbery wrote:
> Josh Triplett  writes:
> > Part of the problem is that the people interested in sysvinit don't tend
> > to care about those features and often argue that others shouldn't care
> > either, and the people interested in those features don't tend to care
> > about sysvinit. It's difficult to motivate people to work on
> > alternatives for a system they already have and prefer.
>
> *This* is the thing that I feel we need to tackle head-on.  Because there
> are a lot of reasons to care about those features, but possibly more
> convincingly, as Ted points out, *upstreams* care about those features and
> are not going to stop caring about those features just because Debian
> packagers do not.

(And some Debian packagers care about those features, too.)

The problem isn't that nobody cares; the problem is that the people who
care most about those features have a solution that works and don't feel
the need for a new one. The more people are (or become) convinced they
want and care about these features, the more likely they are to *also*
want the existing system that already implements them. Resources
available to implement an alternative that compatibly supports those
features but doesn't use or work anything like the existing solution
would have to come from the small intersection of "wants those features"
and "doesn't want the existing system implementing those features".

I'm not suggesting that group doesn't exist, but conditions don't look
good for it to grow substantially, or become sustainable.

(And unfortunately, by comparison, the more acrimonious approach of
fighting against those features and their usage is relatively easier, at
least within Debian.)

> Sure, some systemd features are only marginally better than what came
> before (I admit to not being much of a fan of timer units, for instance).
> But this will vary by person.  For example, as a security person, I care a
> *lot* about namespacing, capability reduction, and seccomp filters, and I
> want to use those features in my packages to make the default
> configuration more secure.  Other people are going to care a lot about
> D-Bus integration, and some upstreams are going to fully embrace socket
> activation (which, again, I'll point out is one of the easiest features of
> systemd to implement outside of systemd; implementations of the same idea
> predated systemd by many years) and just not support any way of spawning
> their service that doesn't satisfy the systemd socket activation API.
> 
> One can individually say that one doesn't care about those features, but
> we just cannot say Debian as a whole should not care about those features.
> It doesn't work.  We have to take an affirmative stance on what Debian is
> going to do with software that does care about and use those features;
> whether we're committing to porting it,

"committing to porting it" isn't a stance that "Debian as a whole" can
take. (Nor is committing to reimplement those features in another init
system.) That's certainly a stance that developers could take,
individually or as a dedicated group, but otherwise it's just "someone
should bell the cat".

> But saying "no one should care about those features" isn't a choice and
> isn't a path forward and we can't stop there as a project.

Agreed.

> > That's leaving aside that a reimplementation of systemd's features will
> > tend towards becoming systemd, and we have one of those already. What is
> > the actual goal?
> 
> The actual goal is to allow for different ecosystems that provide the same
> features while embracing different implementation philosophies.  I know
> that you don't think this is a valuable goal

That wasn't the point I was making, and I'm sorry if it came across
otherwise.

My point was that that makes any potential reimplementation even
*harder*. A simple reimplementation won't suffice. Reuse of existing
code won't suffice. It wouldn't help for folks who like systemd to
reimplement those features, because the reimplementation is not going to
satisfy the additional constraints of people who don't like systemd.
And the dual constraints of "must be compatible with systemd" and "must
have a fundamentally different approach than systemd" *inherently*
creates impedance mismatches and implementation challenges.

There's a reason why this reimplementation work hasn't happened, and
doesn't seem likely to happen. And *because* of that, there's instead
effort directed to try to stop people from using and depending on such
features.

> > It seems evident based on the history of such efforts that there is
> > *not* sufficient people/interest/motivation to reimplement the majority
> > of systemd features, let alone doing so in a way that meets the
> > additional constraints imposed on such solutions.
> 
> I don't think the question has yet been forced.  Up through buster, one
> has been able to mostly run Debian on sysvinit without doing this work,
> with some pain and some gaps and some issues.  I 

Re: Integration with systemd

[Svante Signell]

On Thu, 2019-10-31 at 15:45 +0100, Marco d'Itri wrote:
> > On Oct 31, Simon Richter  wrote:
> > 
> > No, and that's not our job. There are a lot of people out there
> > building non-systemd systems.
> Data says: not really a lot.

When elogind enters testing there would be many more people running
Debian with sysvinit/elogind. elogind is needed for desktop usage when
not using systemd as PID 1. And as said numerous times Debian
maintainers don't have to create sysvinit scripts, they have only to
_accept_ patches to add or fix sysvinit scripts.

Additionally, do you know that sysvinit (and elogind) has an active
upstream and an active maintainer. The number of bugs on sysvinit-
related packages has been reduced considerably recently! I can try to
find the actual numbers for the last months if somebody is interested.

Any ideas of the non-linux ports: Scrap them, and leave them in the
cold?

Re: BITS from the DPL For September/October 2019

[Moritz Mühlenhoff]

Thomas Goirand  schrieb:
> My understanding is that the current guidance is that doing init script
> isn't mandatory.

With policy not updated, people claim it's mandatory, see e.g.
#925473 on Tomcat.

The discussed GRs would provide clarification on what the project
at large actually wants (and what policy should spell out).

Cheers,
Moritz

Bug#943914: RM: firefox-esr [armel] -- RoQA; build-dependency nodejs not available on armel

[Ansgar]

Package: ftp.debian.org

Hideki Yamane writes:
>  firefox-esr package doesn't migrate to testing but I cannot
>  find the reason at https://qa.debian.org/excuses.php?package=firefox-esr

I believe we should remove firefox-esr/armel to allow the current
version to migrate to testing.

Ansgar

Re: BITS from the DPL For September/October 2019

[Alf Gaida]

On Thu, 31 Oct 2019 18:40:58 +0100
Thomas Goirand  wrote:
> On 10/29/19 11:19 PM, Russ Allbery wrote:

> > of clear project guidance, no one is clearly empowered to prevent
> > it from bitrotting.  
What is wrong with bitrotting if nobody cares about - in case nobody
cares about it's the logical consequence. And please don't even try to
enforce this care. 

> My understanding is that the current guidance is that doing init
> script isn't mandatory. What is mandatory, is to ACK init scripts /
> patches when contributed (through the BTS).
I read it the same way - and also a logical consequece: if these
patches lead to bugs, the maintainer should not be forced to fix the
mess. I for myself would just remove buggy things that nobody care in a
certain amount of time.
 
> I think that's fair enough for everyone, and I don't see why we need
> to change anything to this rule.
Dito

> Make what deferred decision? That we want to actively dismiss patches
> adding init script support? This IMO would just destroy any work
> attempted in the non-linux ports, or anyone willing to add support
> for a new init system. I don't think that's fair for these. Voting
> them out would not feel right.
See it different: if the provided scripts/patches are good, why not
take and keep them - systemd users are not hurt. If the scripts/patches
don't work - ignore the upcoming bugs and downgrade everything about to
whishlist - or if interested in: Fix the bugs. Default will work and
good. And i don't want to provoke, i see it exactly this way, if people
spend time one something, why blocking or discourage if it do no harm.
I even merge patches for kfreebsd and the hurd upstream - but i would
never active work on it.

> As much as I understand, we never wrote or decided we would. We just
> need to accept patches to add or fix sysv-rc scripts. What makes you
> think sysv-rc scripts are mandatory?
Good question - if these things are not mandatory nothing needs to
change.

> 
> Thomas Goirand (zigo)
> 



-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

Re: Integration with systemd

[Simon Richter]

Hi,

On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:

> > That is work we have to do regardless of whether we want to support
> > alternatives or not, but in the simple case we just list what is supported
> > by the systemd version we have decided to ship in the last stable release,
> > so we can have backport packages with reasonable effort.

> It is not obvious to me why we would need a different policy for systemd 
> than for other packages which backports may depend on.

We need *a* policy in the first place.

When a package requires a systemd feature that isn't present in the current
stable release,

 - how do we detect this?

There is not even infrastructure in place that can map the features used in
unit files to required minimum systemd versions. Detecting dynamically used
features may be possible by looking at library symbols used, but this would
still have to be developed.

Right now, if I take a package from testing, compile it in a stable chroot
and get an installable binary package that has no dependencies not
satisfiable in stable, how do I verify that the package will work?

 - how should we react?

If a backported package does not work, and we find out somehow, what is the
correct course of action? Should the package be removed from the backports
archive, and users told to upgrade to testing? Should the backporter create
workarounds for missing features?

If you look at the history of the Debian Policy, the question of backwards
compatibility has always been a major point of contention. It took several
years to implement the "build-arch" target in debian/rules, because there
was no reliable way to detect whether the target was supported, so it was
impossible to distinguish between a build failure and an old package.

For some reason, all that caution seems to have gone out of the window.

We have had systemd as default pid 1 for longer than it took to get
"build-arch" documented, added to policy as optional, transitioning all
packages in the archive and making it mandatory so autobuilders could use
it. In all this time the only mention of systemd in policy are two
instances of adding dh_installsystemd after a mention of dh_installinit,
and section 9.3.5., titled "Example", pointing to a manpage instead of
giving an actual example.

Debian is entirely unprepared to do backports of anything that uses newer
systemd features. For GNOME that isn't a problem, large installations will
simply wait for the next stable release and laptop users will switch to
testing, but for libvirt, that is going to be a big deal.

> > No, and that's not our job. There are a lot of people out there building
> > non-systemd systems.

> Data says: not really a lot.

Even if we limit our view to "Debian installations", there is no sensible
way to measure that, or to distill it down to a useful number. Is an
administrator for a large installation a single user? Should we look at
downloads or at popcon statistics? Do autobuilders pulling systemd-sysv as
a dependency of libgtk-3-dev count?

My point with that sentence is a different one though: a lot of Free
Software exists outside the Linux sphere that does neither anticipate nor
require tight integration with systemd, and that software is still useful,
so it makes sense to ship it. It is niche, but it is the niche we have been
traditionally good at, so I don't see a reason for leaving that and
focusing on an oversaturated field without even marginally preparing.

Mind you, we still need to cover that field, but the reason people have
forgiven us to usually be the last distribution to ship new versions is
that when we ship, we get it right -- and that's what I'm not seeing here.

We're not only short on volunteers to backport systemd features to
sysvinit, we're also short on volunteers to lay the groundwork for systemd
based services. Is that is an indication of "lack of interest", as it seems
to be when sysvinit support is concerned?

The other big elephant in the room is what Ansgar mentioned in his reply to
me: containers where the systemd instance lives outside the container. I
would expect that several users want to run "stable" systemd, and import
containers for specific services. What infrastructure, what policies are in
place to ensure that services inside the container are compatible with
systemd outside?

   Simon

Re: BITS from the DPL For September/October 2019

[Gunnar Wolf]

Simon Richter dijo [Wed, Oct 30, 2019 at 12:46:21PM +0100]:
> Hi,
> 
> On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote:
> 
> > If we have such vote again, I'll continue on this direction: I'd prefer
> > if we didn't have to vote.
> 
> >From a Policy perspective, packages are supposed to integrate into the
> system by providing init scripts, and Policy has a lengthy definition of
> how init scripts need to behave.
> 
> We need to at least mention systemd unit files at some point, so action is
> needed, and that action needs to be backed up by a vote to avoid being
> more divisive than necessary.

I completely agree with this -- It is time for Policy to specify at
least the equivalence of init scripts to systemd units.

Policy has always documented standard practice, so it was right for it
to lag before doing this. It is, I guess, time to revisit...

> So far, systemd adoption has been mostly smooth sailing because the
> ecosystem effectively consists of two blocks: the systemd core, which is
> centrally coordinated, and some traditional Unix daemons hanging off it,
> but essentially not integrating. This is about to change as projects
> actually start using systemd.

Yes. And that will be a thorn for people investing time in maintaining
Debian as an init-system-agnostic distribution. Or worse, following
the examples you provide :-\

> (...)
> All that requires way more complex unit files than anything we normally
> deal with in Debian, and we need to decide how much control we want to keep
> over package integration here, because that is what Debian does: take
> upstream software and provide a coherent integrated whole.
> 
> By leaving it unspecified in Policy what systemd features are expected in a
> particular Debian release, we essentially take a back seat in what should
> be our core competence.

Although by taking advantage of them, we will not be able to support
on an equal tier other init systems.

> If the project feels that these use cases are not worth supporting, then
> that is a policy decision that needs to be voted on, not just silently
> implemented, last but not least so we can update our marketing materials
> with footnotes on the "universal operating system" tagline, and users (who,
> after all, are one of our priorities) can adjust their expectations.
> 
> So yes, having a vote is necessary at this point. We've neglected setting
> policy way too long, the scope of the project is unclear at this point, and
> people are pulling in all kinds of directions.

Very much agree with this. It is time to revisit and think clearly
about what we win/lose, and where are we heading as a
project. Probably the only way forward is via the full GR process.


signature.asc
Description: PGP signature

Re: Integration with systemd

[Russ Allbery]

Ian Jackson  writes:

> The question is: are we going to permit those technical contributions
> into Debian ?  Are we going to keep making it awkward or are we actually
> going to _welcome_ them ?

> Are we going to say to those of our contributors who want to see a nice
> tidy hegemony, "sure, throw all the sysvinit stuff away, it is OK to
> reject the patches with init scripts, it is OK to work to make it
> impossible to have this stuff in Debian, even if the software works" ?

> And, are we going to continue to wear people down with awful threads
> like this one, where a parade of doomsayers tell us we can't have what
> we want *even though it already exists and is maintained* ?

Exactly.  And this to me is why a GR is a good idea, because right now we
don't have a clear project decision to point to, and therefore everyone
feels free to argue their side of the issue every time it comes up.  And
there isn't a clear project statement that people shouldn't remove init
scripts from their package, or that people shouldn't reject patches with
init scripts, that's documented somewhere and that we support as a
community.

We have a rough compromise that those of us who were there at the time
remember and try to support, but it's not written down, and there are
far-flung segments of Debian that don't read debian-devel and only
interact with systemd systems and aren't going to naturally support that
compromise.  Plus, that compromise was understood at the time to be
contingent on future developments, so we need to revisit it.

This is the deferred decision that I'm talking about: what is the project
going to say is Debian's position on what we're supporting and what we're
not supporting?  One option is to ratify the existing compromise, which
would have the advantage of putting some teeth into it and which I will
volunteer to try to write Policy text for.  But I do think it's not 100%
obvious that a majority in Debian supports that compromise, or understands
it in the same way.  We gain a lot of clarity by figuring that out.

I should also point out that this is exactly why Ian wanted a clear TC
ruling or GR on this after the original systemd debate, and what we're
seeing are the negative consequences of not doing that, just as he had
predicted.  As mentioned elsewhere, I still support the decision the
project made at the time for other reasons, but this is the downside that
we have not yet come to grips with, and I think it's worth noting that Ian
was correct about the negative consequences.

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

Re: Integration with systemd

[Ansgar]

Simon Richter writes:
>> > No, and that's not our job. There are a lot of people out there building
>> > non-systemd systems.
[...]
> My point with that sentence is a different one though: a lot of Free
> Software exists outside the Linux sphere that does neither anticipate nor
> require tight integration with systemd, and that software is still useful,
> so it makes sense to ship it. It is niche, but it is the niche we have been
> traditionally good at, so I don't see a reason for leaving that and
> focusing on an oversaturated field without even marginally preparing.

I'm not sure what that has to do with Debian supporting multiple init
systems?  Nobody is suggesting to not package software that doesn't need
tight integration with systemd; most software probably won't.

Ansgar

Re: Integration with systemd

[Ole Streicher]

Svante Signell  writes:
> And as said numerous times Debian maintainers don't have to create
> sysvinit scripts, they have only to _accept_ patches to add or fix
> sysvinit scripts.

Even as someone who does not really care about the init system (being a
desktop user, I use whatever is the base there): I fully support you.

I really don't get the point of the discussion here: We have several
people trying to reach their goal with Debian. There are people fighting
for reproducibility, we have people supporting cross-building,
inofficial ports etc.

And we have people that want to support several init systems.

As a maintainer, my own interest in all these topics varies, by topic
and by package; therefore my own active support varies as well. But for
every topic I see some rationale, and so the minimum support is always
to accept patches (maybe after some review and discussion if it
influences my own packaging). If this creates a bug, I would however
just forward it to the patch creator, and just revert the patch if it
doesn't get fixed.

I think the openness of our distribution for well-defined goals is one
of our big strengths, and we should keep this up. I don't see a reason
why a maintainer should not accept sysvinit patches, or crossbuilding
patches, as long as they don't interfere with the rest of the package.

Being liberal would IMO really help here, and hurt nobody.

Just my 2 cents

Ole

Re: Integration with systemd

[John Goerzen]

On Thu, Oct 31 2019, Theodore Y. Ts'o wrote:
> It may be that sysvinit is doomed.  But we shouldn't be accelerating
> the process.

You are quite right.  I have also found myself wondering, though, what
are the BSDs doing?  Clearly systemd isn't going to be workable for
them.  Is their approach something that would be at all useful here?

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

On 10/31/19 7:36 PM, Moritz Mühlenhoff wrote:
> Thomas Goirand  schrieb:
>> My understanding is that the current guidance is that doing init script
>> isn't mandatory.
> 
> With policy not updated, people claim it's mandatory, see e.g.
> #925473 on Tomcat.

Well, the policy is wrong, and should be updated then. I do believe we
all agree on this already.

Now, looking at the said bug, we have Thorsten Glaser proposing:
"I’d very happily maintain the init script."

I haven't read all the bug entry, but if someone is claiming that
accepting such contribution is mandatory, then that's very much right,
at least that the consensus we're in right now, indeed. Which is *very*
different from mandating the package maintainers to do the work all by
themselves.

> The discussed GRs would provide clarification on what the project
> at large actually wants (and what policy should spell out).

So, if I understand well, you guys want to remove the mandatory
acceptation of contributed sysv-rc init scripts. At this point in time,
we could do that, but well, if it's this way, I do believe we must as well:
- stop any non-linux port effort, and remove them from ports.d.o.
- remove sysv-rc, filerc and openrc from Debian.
- edit the policy and mandate each package having .service files.
- file (probably non-rc) bugs against things providing a sysv-rc script,
asking for its removal.
- make a release goal for Bullseye so that we get rid of any non-systemd
startup scripts.

Because if we can't provide support for these, we may as well remove
them all together, and if we do, we should do it the right way.

In the text of the said GR, please make all of this very clear,
otherwise, we'd be misleading the voters!

Cheers,

Thomas Goirand (zigo)

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

On 10/31/19 8:07 PM, Alf Gaida wrote:
> I read it the same way - and also a logical consequece: if these
> patches lead to bugs, the maintainer should not be forced to fix the
> mess. I for myself would just remove buggy things that nobody care in a
> certain amount of time.

I'd be very much fine with this type of move.

The idea has always been that it would be on best-effort from people who
volunteer, without forcing anyone to do any sysv-rc support if they
don't feel like it. What you describe goes along this line.

Thomas Goirand (zigo)

Re: Integration with systemd

[Theodore Y. Ts'o]

On Thu, Oct 31, 2019 at 01:44:58PM +, Ian Jackson wrote:
> Martin Steigerwald writes ("Re: Integration with systemd"):
> > As to this, I did not yet see that the migration of elogind to testing 
> > has been accepted.
> 
> Yes.
> 
> I find these conversations draining, exhausting, awful.  I am sure
> that most people who are sceptical of systemd agree.  The constant
> negging and doom-saying is very unpleasant.
> 
> And, are we going to continue to wear people down with awful threads
> like this one, where a parade of doomsayers tell us we can't have what
> we want *even though it already exists and is maintained* ?

That's true SO FAR.  The fact remains that systemd has *tons* and
*tons* of new features which to date, aren't yet getting used in huge
numbers of open source software packages or in Debian packaging --- YET.

If we do need to have a GR, we need to be very careful how the choices
are worded.  We should be clear whether we are giving carte blanche
for Debian developers to use every possible systemd feature under the
sun, whether or not there are non-systemd emulation possibilities yet.

Or whether we are simply saying that we are not mandating that Debain
Maintainers don't have to do extra work to support non-systemd
systems, but they shouldn't be actively working to make things.

Let's take e2fsprogs for example.  I had applied a patch which had a
cron script alternative on top of the timer unit file.  It turns out
the cron script was buggy, and it took multiple tries before we got it
right --- because I don't maintain a test system with sysvinit to test
it.  So I applied patches, but I was *not* doing my own testing before
releasing updates with the cron support.  I'd call that "best efforts"
support.

The GR should make clear whether or not what I did was sufficient ---
I took patches and attempted bug fixes to support sysvinit --- or
whether I should have been doing more explicit testing for sysvinit.

The GR should also make clear whether it would be a good thing if I,
as the Debian Maintainer, were to deliberately use some esoteric
systemd feature for which there is not non-systemd alternative in a
package's packaging scripts.  (I wouldn't do such a thing, in general,
since I personally a good programmer should do things portably, and
using an esoteric systemd feature is *not* good programming practice.
But it's clear that others, like perhaps Josh Triplett, feel
differently.  And I don't feel that I should necessarily be imposing
my personal beliefs on everyone.)

Again, look at Josh's list of all of the random esoteric systemd
features that people *could* be using.  I think you're painting a far
too optismistic picture that there will always be enough programmer
interest to keep up with systemd's many and varied new features.

- Ted

Re: RFC: How about using MRs to communicate the diffs for NMUs with an MR

[Sean Whitton]

Hello,

On Thu 31 Oct 2019 at 12:00PM +01, Gert Wollny wrote:

> "Then, you either prepare the NMU in a fork of the original packaging
> repository and submit a merge request referencing the bug you are
> fixing, or send a patch containing the differences between the current
> package and your proposed NMU to the BTS."

I'd like to suggest that the nmudiff in the BTS remain the method
mentioned first, and then you could append "... or if the maintainer
has enabled MRs for their repo and your changes are based on that repo,
you can submit a MR instead."

This is the least disruptive change.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: BITS from the DPL For September/October 2019

[Moritz Mühlenhoff]

Thomas Goirand  schrieb:
> "I’d very happily maintain the init script."
>
> I haven't read all the bug entry, but if someone is claiming that
> accepting such contribution is mandatory, then that's very much right,
> at least that the consensus we're in right now, indeed.

This isn't limited to just shipping an init script, have a look at the
tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
Continuing to support an init script also means to retain on all the
packaging boilerplate which got obsoleted by systemd config declaratives,
forcing the least common denominator of init system features.

Cheers,
Moritz

Re: [RFC] Proposal for new source format

[Sean Whitton]

Hello,

On Thu 31 Oct 2019 at 11:59AM +00, Ian Jackson wrote:

> Well, that's fair enough as far as it goes.  But I think we could do
> better.
>
> It would be possible to imagine some service that works like this:
> [...]

This would be cool!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Integration with systemd

[Thomas Goirand]

On 10/30/19 10:54 PM, Josh Triplett wrote:
> It seems evident based on the history of such efforts that there is
> *not* sufficient people/interest/motivation to reimplement the majority
> of systemd features, let alone doing so in a way that meets the
> additional constraints imposed on such solutions. That support isn't
> going to materialize out of hope.

You are very right with the above, some features are probably never
going to be implemented elsewhere than in systemd.

However, this doesn't mean that anything non-systemd must implement all
things that systemd does, or just die. It really doesn't make sense to
tell that, for example, OpenRC should be forced into implementing a
parser of .timer files, just because some maintainers wont care about
cron jobs. These cron jobs could be maintained by those who care, just
like with sysv-rc scripts, as a best-effort basis.

Thomas Goirand (zigo)

Re: Integration with systemd

[Marco d'Itri]

On Oct 31, Svante Signell  wrote:

> When elogind enters testing there would be many more people running
> Debian with sysvinit/elogind. elogind is needed for desktop usage when
> not using systemd as PID 1. And as said numerous times Debian
elogind is already in testing: I will be delighted to see how the number 
of testing/unstable users running sysvinit will change in November.

> maintainers don't have to create sysvinit scripts, they have only to
> _accept_ patches to add or fix sysvinit scripts.
The problem is not just shipping a sysvinit script to start a daemon.
The problem is integrating in the boot system packages to support things 
like LVM, FCoE and multipath.
The problem is all the brittle machinery needed to support switching 
among differeny init systems.
The problem is having a daemon whose listening ports and addresses 
should be configured with systemd units or their configuration file 
depending on the init system being used.
The problem is starting X and then starting all the programs in the user 
session with systemd user units or with something totally different 
which maybe 1% of the users base has tested.
The problem is other packages having to support two totally different 
kinds of suspend/resume hooks.
And so on.

It was never just about sysvinit scripts: if all needed to make our 
few sysvinit users happy were just accepting patches to add missing init 
scripts then who would object?

> Any ideas of the non-linux ports: Scrap them, and leave them in the
> cold?
The non-Linux ports already died due to lack of users and developers 
because they are pointless, this has nothing to do with systemd.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Integration with systemd

[Craig Small]

On Fri, 1 Nov 2019 at 08:27, Thomas Goirand  wrote:

> However, this doesn't mean that anything non-systemd must implement all
> things that systemd does, or just die. It really doesn't make sense to
> tell that, for example, OpenRC should be forced into implementing a
> parser of .timer files, just because some maintainers wont care about
> cron jobs. These cron jobs could be maintained by those who care, just
> like with sysv-rc scripts, as a best-effort basis.
>
I think this, or something like this, is the policy update the project
needs.  I think this is a fine option, but does the project as a whole
think so, or perhaps they do with some changes?

At the moment, my guess is most developers have no idea what the "right"
(e.g. what the project as a whole believe is right) solution for this.
Should I just use systemd support only? With sysvinit? If I get bug reports
about lack of support for one or the other how important is it?

 - Craig


> Thomas Goirand (zigo)
>
>

Re: Integration with systemd

[Russ Allbery]

Craig Small  writes:
> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand  wrote:

>> However, this doesn't mean that anything non-systemd must implement all
>> things that systemd does, or just die. It really doesn't make sense to
>> tell that, for example, OpenRC should be forced into implementing a
>> parser of .timer files, just because some maintainers wont care about
>> cron jobs. These cron jobs could be maintained by those who care, just
>> like with sysv-rc scripts, as a best-effort basis.

> I think this, or something like this, is the policy update the project
> needs.  I think this is a fine option, but does the project as a whole
> think so, or perhaps they do with some changes?

> At the moment, my guess is most developers have no idea what the "right"
> (e.g. what the project as a whole believe is right) solution for this.
> Should I just use systemd support only? With sysvinit? If I get bug
> reports about lack of support for one or the other how important is it?

One variation on this that's worth at least thinking about, although
perhaps it would be unworkable, is if those cron jobs, init scripts, and
other similar components that need to be maintained could be shipped in
their own Debian package.

A lot of the process friction is in getting Debian maintainers to add this
support to their packages.  Even if all concerns about testing, support,
and so forth go away, we know that this is still not painless (see, for
instance, translations, where we do *reasonably* well but where
translations can still sit in the BTS for extended periods of time).  If
it's possible to allow the people who are maintaining those files to
upload them directly, it would remove that friction and process and might
be easier to maintain.

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

Re: [RFC] Proposal for new source format

[gregor herrmann]

On Thu, 31 Oct 2019 11:59:07 +, Ian Jackson wrote:

>  * tag2upload service, or some related service:
> - determines that the maintainer is using a dgit-compatible git
>   workflow, by looking at the tags, and looks at some in-dsc
>   metadata to find the maintainer's repo
> - determines that the maintainer is using salsa or launchpad,
>   converts the NMU to the maintainer branch's format, and
>   submits an MR

… after checking that the current state of the git repo corresponds
to the current version in the archive (which is often not the case in
my experience with NMUs) …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: You Know Who I Am


signature.asc
Description: Digital Signature

Re: tomcat9 using systemd specific stuff is now vendor lock-in [was: BITS from the DPL For September/October 2019]

[Thomas Goirand]

On 10/31/19 9:56 PM, Moritz Mühlenhoff wrote:
> This isn't limited to just shipping an init script, have a look at the
> tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
> Continuing to support an init script also means to retain on all the
> packaging boilerplate which got obsoleted by systemd config declaratives,
> forcing the least common denominator of init system features.

Ok, let's have a look.

So I saw this:

* Simplified the postinst script by using systemd-sysusers to create
the 'tomcat' user

and then investigated a little bit what systemd-sysusers is (I didn't
know it). And it's really a disaster ... at many levels!

Instead of using well understood parameters to adduser, which we've been
using for decades, and understand well the parameters, systemd provides
now a mechanism through /usr/lib/sysusers.d. Tomcat uses it by adding a
file in /usr/lib/sysusers.d/tomcat9.conf. I'm immediately questionning
myself is it wouldn't have been better in /etc/systemd/sysusers.d, so
that we get CONFFILE, but that's Red Hat tooling, so... and maybe we can
override it in /etc/systemd? Anyways...

So, this is supposed to be "more simple". Really? I'm not convinced.
Looking into the script, I now also have to look into the indirection of
that data file, and package that file.

What's for sure now, is that tomcat9 is vendor-locked-in, as in, no way
to escape systemd, otherwise the postinst will crash. I suppose the
maintainer perfectly understands it, but doesn't mind/care. [I by the
way wonder why tomcat9 runtime depends on both lsb-base *AND* systemd]

Probably, systemd-sysusers got the logic to check with getent if the
user is present before adding it and such things. So it may be useful
(hard to tell, but looking quickly at its source code, it seems doing
that, and even a lot more, to the point that it starts to get scary).
But that's not the point.

The question is, why is systemd-sysusers part of just systemd, and not
packaged / shipped somewhere else? This really looks like something that
could be taken away from systemd itself, and proposed as a separate
tool, in a general way, so that other init system could use it. To the
point that, IMO, even upstream should have separate it from systemd
itself (in another project?).

This is precisely what a distribution should do through a policy:
enforce common tooling for our maintainer scripts, so we can do things
together. Of course, that's not on the systemd agenda, where the goal
seems to be to take over everything. But maybe as a distribution, we
could be smarter than this?

Finally, this really shows we don't have enough in our policy. Indeed,
using systemd-sysusers *OR* some common Debian tooling should be
documented somewhere, and not left as a decision to the package
maintainer. I have to admin that I wrote my own tooling around adduser /
addgroup / getend / usermod, but considering how many traps there,
probably a more generic tooling should have been written and generalized
for all of Debian.

The other things I saw from the changelog are less controversial:
* Let systemd automatically create /var/log/tomcat9 and /var/cache/tomcat9

this can easily be added in the init script

* Restart the server automatically on failures

that's a nice standard systemd feature, which we don't have to enforce
on other init systems.

Did I miss something else?

Cheers,

Thomas Goirand (zigo)

Re: RFC: How about using MRs to communicate the diffs for NMUs with an MR

[gregor herrmann]

On Thu, 31 Oct 2019 13:54:11 -0700, Sean Whitton wrote:

> On Thu 31 Oct 2019 at 12:00PM +01, Gert Wollny wrote:
> > "Then, you either prepare the NMU in a fork of the original packaging
> > repository and submit a merge request referencing the bug you are
> > fixing, or send a patch containing the differences between the current
> > package and your proposed NMU to the BTS."
> I'd like to suggest that the nmudiff in the BTS remain the method
> mentioned first, and then you could append "... or if the maintainer
> has enabled MRs for their repo and your changes are based on that repo,
> you can submit a MR instead."

"and your changes are based on that repo" is an important addition.

Still, I'm not quite happy because bugs in the BTS (for team
maintained packages) go to a team mailing list which reaches
everyone, whereas mails from salsa go only to people who changed
their notification setting in order to get those mails.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: You Know Who I Am


signature.asc
Description: Digital Signature

Re: Integration with systemd

[Thomas Goirand]

On 10/31/19 11:30 PM, Russ Allbery wrote:
> Craig Small  writes:
>> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand  wrote:
> 
>>> However, this doesn't mean that anything non-systemd must implement all
>>> things that systemd does, or just die. It really doesn't make sense to
>>> tell that, for example, OpenRC should be forced into implementing a
>>> parser of .timer files, just because some maintainers wont care about
>>> cron jobs. These cron jobs could be maintained by those who care, just
>>> like with sysv-rc scripts, as a best-effort basis.
> 
>> I think this, or something like this, is the policy update the project
>> needs.  I think this is a fine option, but does the project as a whole
>> think so, or perhaps they do with some changes?
> 
>> At the moment, my guess is most developers have no idea what the "right"
>> (e.g. what the project as a whole believe is right) solution for this.
>> Should I just use systemd support only? With sysvinit? If I get bug
>> reports about lack of support for one or the other how important is it?
> 
> One variation on this that's worth at least thinking about, although
> perhaps it would be unworkable, is if those cron jobs, init scripts, and
> other similar components that need to be maintained could be shipped in
> their own Debian package.
> 
> A lot of the process friction is in getting Debian maintainers to add this
> support to their packages.  Even if all concerns about testing, support,
> and so forth go away, we know that this is still not painless (see, for
> instance, translations, where we do *reasonably* well but where
> translations can still sit in the BTS for extended periods of time).  If
> it's possible to allow the people who are maintaining those files to
> upload them directly, it would remove that friction and process and might
> be easier to maintain.

While I very much like the idea of letting others do their work without
the maintainer to even notice to avoid frictions, I don' think adding
cron jobs in a separate package is the sensible solution.

Thomas Goirand (zigo)

Re: Integration with systemd

[Svante Signell]

On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> On Oct 31, Svante Signell  wrote:
> 
> > When elogind enters testing there would be many more people running
> > Debian with sysvinit/elogind. elogind is needed for desktop usage
> > when not using systemd as PID 1.

> elogind is already in testing: I will be delighted to see how the
> number  of testing/unstable users running sysvinit will change in
> November.

Marco, I think your information about elogind is not up-to-date:
https://tracker.debian.org/pkg/elogind

testing migrations:
excuses:
Migration status for elogind (239.3+20190131-1+debian1 to
241.3-1+debian1): Will attempt migration (Any information below is
purely informational)
Additional info:
Updating elogind fixes old bugs: #939101
Piuparts tested OK - 
https://piuparts.debian.org/sid/source/e/elogind.html
115 days old (needed 5 days)

Yes, 115 days old...

Re: Integration with systemd

[Thomas Goirand]

On 10/31/19 9:32 PM, Theodore Y. Ts'o wrote:
> Let's take e2fsprogs for example.  I had applied a patch which had a
> cron script alternative on top of the timer unit file.  It turns out
> the cron script was buggy, and it took multiple tries before we got it
> right --- because I don't maintain a test system with sysvinit to test
> it.  So I applied patches, but I was *not* doing my own testing before
> releasing updates with the cron support.  I'd call that "best efforts"
> support.
> 
> The GR should make clear whether or not what I did was sufficient ---
> I took patches and attempted bug fixes to support sysvinit --- or
> whether I should have been doing more explicit testing for sysvinit.

As much as I understand, at this point in time, the project considers
that what you did was enough. I don't think we need a GR for this.

> The GR should also make clear whether it would be a good thing if I,
> as the Debian Maintainer, were to deliberately use some esoteric
> systemd feature for which there is not non-systemd alternative in a
> package's packaging scripts. (I wouldn't do such a thing, in general,
> since I personally a good programmer should do things portably, and
> using an esoteric systemd feature is *not* good programming practice.
> But it's clear that others, like perhaps Josh Triplett, feel
> differently.  And I don't feel that I should necessarily be imposing
> my personal beliefs on everyone.)

IMO, this type of decision should go in the policy, case by case, and
I'm not sure a GR is the solution: it's going to be a generic "use all
of systemd" vs a "be careful to use only things implemented elsewhere".
 I don't think this works, as often, there is maybe a middle ground
"well, it depends on the situation". For the systemd-sysusers in
tomcat9, probably best would have been to keep thinks as they were
rather than using an implementation that only has the side effect as to
get locked-in, especially when it's easy to avoid the problem. For other
cases, maybe it's nice to be able to use systemd-only features, and here
I'm thinking namely about cgroup stuff, for example.

Cheers,

Thomas Goirand (zigo)

Re: "the" cloud [Integration with systemd]

[Thomas Goirand]

Hi Martin!

On 10/31/19 5:13 PM, Martin Steigerwald wrote:
> It is similar with "the" cloud.

Why is there quotes around "the", and why do you think there's only a
single instance of a cloud out there?

> Yet, there are attempts to disrupt the cloud already by making
> machines powerful enough that they do not need a centralized cloud
> provider even if storing a huge lot of data.

We must be living in very different worlds... in mine, there's no such
thing as "a centralized cloud provider", and it's cheaper to deploy your
own cloud on top of Debian. It's also still impossible to store dozens
of petabytes in a single compute (if you have such hardware available,
please give me a link to the vendor), and I'm not yet scratching topics
such as automation, high availability and scalability.

Besides this, I completely miss the point that you're trying to make,
and how this is related to init systems... :)

Cheers,

Thomas Goirand (zigo)

Work-needing packages report for Nov 1, 2019

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1259 (new: 2)
Total number of packages offered up for adoption: 249 (new: 1)
Total number of packages requested help for: 54 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   arpack++ (#943879), orphaned today
 Reverse Depends: libarpack++2-dev
 Installations reported by Popcon: 275
 Bug Report URL: https://bugs.debian.org/943879

   python-bayespy (#943918), orphaned today
 Installations reported by Popcon: 20
 Bug Report URL: https://bugs.debian.org/943918

1257 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   python-expiringdict (#943747), offered 2 days ago
 Description: Python3 caching library
 Reverse Depends: python3-dnsq python3-pyaff4
 Installations reported by Popcon: 32
 Bug Report URL: https://bugs.debian.org/943747

248 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 1065 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker
 Installations reported by Popcon: 1177
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 2958 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 694
 Bug Report URL: https://bugs.debian.org/642906

   broadcom-sta (#886599), requested 661 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1790
 Bug Report URL: https://bugs.debian.org/886599

   cargo (#860116), requested 933 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 1306
 Bug Report URL: https://bugs.debian.org/860116

   cyrus-sasl2 (#799864), requested 1499 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap
   cairo-dock-mail-plug-in cyrus-caldav cyrus-clients cyrus-common
   cyrus-dev cyrus-imapd cyrus-imspd (77 more omitted)
 Installations reported by Popcon: 201985
 Bug Report URL: https://bugs.debian.org/799864

   dee (#831388), requested 1203 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core
 Installations reported by Popcon: 42945
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 1888 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 7968
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#800413), requested 1493 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian customdeb debci debian-builder debmake debpear (31 more
   omitted)
 Installations reported by Popcon: 12023
 Bug Report URL: https://bugs.debian.org/800413

   docker.io (#908868), requested 411 days ago
 Description: Linux container runtime
 Reverse Depends: golang-docker-dev
   golang-github-containers-image-dev
   golang-github-containers-storage-dev
   golang-github-fsouza-go-dockerclient-dev
   golang-github-google-cadvisor-dev
   golang-github-openshift-imagebuilder-dev
   golang-github-samalba-dockerclient-dev kubernetes-node subuser
   whalebuilder
 Installations reported by Popcon: 2389
 Bug Report URL: https://bugs.debian.org/908868

   ed (#886643), requested 661 days ago
 Description: classic UNIX line editor
 Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn
 Installations reported by Popcon: 16198
 Bug Report URL: https://bugs.debian.org/886643

   ejabberd (#767874), requested 1823 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-default-contacts ejabberd-mod-default-rooms
   ejabberd-mod-deny-omemo ejabberd-mod-filter ejabberd-mod-grafite
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   (10 more omitted)
 Installations reported by Popcon: 443
 Bug Report URL: https:/

Re: Integration with systemd

[Russ Allbery]

Thomas Goirand  writes:

> IMO, this type of decision should go in the policy, case by case, and
> I'm not sure a GR is the solution: it's going to be a generic "use all
> of systemd" vs a "be careful to use only things implemented elsewhere".
> I don't think this works, as often, there is maybe a middle ground
> "well, it depends on the situation". For the systemd-sysusers in
> tomcat9, probably best would have been to keep thinks as they were
> rather than using an implementation that only has the side effect as to
> get locked-in, especially when it's easy to avoid the problem. For other
> cases, maybe it's nice to be able to use systemd-only features, and here
> I'm thinking namely about cgroup stuff, for example.

So, let's explore this "Policy on a case-by-case basis" approach.

I think we should adopt sysusers.d fragments as the preferred mechanism
for creating system users (with some rules, such as a standard for how to
name the users and a requirement that the UID be specified as - unless one
goes through the normal base-passwd registration process).  It supports a
declarative syntax, doesn't require putting runes of code into a shell
script, moves us farther down the path towards reducing us of maintainer
scripts for most packages, and avoids the whole dependency and
pre-dependency mess with adduser that took forever to sort out.  The
syntax for sysusers.d is straighforward to parse, and support for
non-systemd init systems via a trigger or boot-time script (or both) via
adduser could be easily written, hiding the distinction between init
systems.

So I should propose putting that into Policy, right?  Presumably you would
object.

And presumably you would instead propose banning use of systemd-sysusers
and sysusers.d and requiring continuing to use adduser from maintainer
scripts as we currently do.  I would object because to me that's obviously
inferior to a declarative syntax.  I've been beating the drum for
declarative syntax to replace maintainer scripts in Debian since before
systemd existed, and I personally don't care whether systemd happens to be
the project that came up with a good facility or not.  If I see a good
opportunity for moving to declarative syntax, I'll support it.

So now neither of our proposals has consensus, and Policy continues to be
somewhat ambiguous about systemd-sysusers.  (Policy currently says, in
kind of a weird place, that using adduser is a "should," which makes it a
non-RC bug to not do so, but shoulds are often interpreted by the project
to imply a certain amount of maintainer discretion.)

Now what?

This is why I don't think your strategy of avoiding a GR and just having
Policy sort this out somehow doesn't work.

(Also, just to head this off in advance in case anyone wants to argue it,
I personally am dead-set against a position that says "if we can't get
consensus, we require everyone to do what we've always done."  I think
that's a recipe for endless sniping, hard feelings, and eventual
obsolescence.  Debian is too large now to be able to do literally
*everything* by consensus; there are some things where we'll always find
someone who objects to every course of action.)

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

Re: Integration with systemd

[Thomas Goirand]

On 11/1/19 1:51 AM, Russ Allbery wrote:
> Thomas Goirand  writes:
> 
>> IMO, this type of decision should go in the policy, case by case, and
>> I'm not sure a GR is the solution: it's going to be a generic "use all
>> of systemd" vs a "be careful to use only things implemented elsewhere".
>> I don't think this works, as often, there is maybe a middle ground
>> "well, it depends on the situation". For the systemd-sysusers in
>> tomcat9, probably best would have been to keep thinks as they were
>> rather than using an implementation that only has the side effect as to
>> get locked-in, especially when it's easy to avoid the problem. For other
>> cases, maybe it's nice to be able to use systemd-only features, and here
>> I'm thinking namely about cgroup stuff, for example.
> 
> So, let's explore this "Policy on a case-by-case basis" approach.
> 
> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users (with some rules, such as a standard for how to
> name the users and a requirement that the UID be specified as - unless one
> goes through the normal base-passwd registration process).  It supports a
> declarative syntax, doesn't require putting runes of code into a shell
> script, moves us farther down the path towards reducing us of maintainer
> scripts for most packages, and avoids the whole dependency and
> pre-dependency mess with adduser that took forever to sort out.  The
> syntax for sysusers.d is straighforward to parse, and support for
> non-systemd init systems via a trigger or boot-time script (or both) via
> adduser could be easily written, hiding the distinction between init
> systems.
> 
> So I should propose putting that into Policy, right?  Presumably you would
> object.
> 
> And presumably you would instead propose banning use of systemd-sysusers
> and sysusers.d and requiring continuing to use adduser from maintainer
> scripts as we currently do.  I would object because to me that's obviously
> inferior to a declarative syntax.  I've been beating the drum for
> declarative syntax to replace maintainer scripts in Debian since before
> systemd existed, and I personally don't care whether systemd happens to be
> the project that came up with a good facility or not.  If I see a good
> opportunity for moving to declarative syntax, I'll support it.
> 
> So now neither of our proposals has consensus, and Policy continues to be
> somewhat ambiguous about systemd-sysusers.  (Policy currently says, in
> kind of a weird place, that using adduser is a "should," which makes it a
> non-RC bug to not do so, but shoulds are often interpreted by the project
> to imply a certain amount of maintainer discretion.)
> 
> Now what?

I agree with some of the things you wrote above, but...

...the bigger question is: why systemd-sysusers is part of systemd, and
not a standalone thing, which we could make an essential package. If we
want it to be part of a package standard toolkit, it means systemd
becomes an essential package, which isn't really what we want (we don't
need an init system in a chroot, as you know). For that reason alone,
it's probably a bad idea to recommend systemd-sysusers everywhere.

Cheers,

Thomas Goirand (zigo)

Re: Integration with systemd

[Russ Allbery]

Thomas Goirand  writes:

> ...the bigger question is: why systemd-sysusers is part of systemd, and
> not a standalone thing, which we could make an essential package. If we
> want it to be part of a package standard toolkit, it means systemd
> becomes an essential package, which isn't really what we want (we don't
> need an init system in a chroot, as you know). For that reason alone,
> it's probably a bad idea to recommend systemd-sysusers everywhere.

I don't claim to know the full answer to this question, but if I had to
guess, it's not particularly exciting: (a) the people who wrote it decided
to include it in the systemd project for watever reason, probably because
it was convenient and they were systemd developers, and (b) in the absence
of any particular reason to break parts of systemd off into separate
packages, the systemd maintainers have quite rationally minimized their
work and packaging complexity.

Note that upstream is probably not interested in promising
systemd-sysusers will always run under non-systemd init systems.  I don't
know if there's any current or future reason why it wouldn't (maybe the %b
or %m specifiers use some systemd library, although maybe they don't; I
have done precisely zero investigation), but I doubt they'd make such a
guarantee.  Folks may with some reason think they're wrong for not caring
about that, but they're of course entitled to care and not care about
whatever they want.  It therefore might be as simple as just making a new
binary package, or it might not, and even if it is now, it might not
always be.

On my side, what I find interesting is the declarative syntax and
therefore the configuration files.  I don't really care if we use the
systemd-sysusers program or something else (although obviously it's easier
to use the thing that's already written and that someone else is
maintaining for us).  I do (mildly) care that we use the same syntax and
features as systemd because I think there's value in convergence between
Debian, Red Hat, and other distributions.  The divergence between Debian
and Red Hat and the correspondingly large differences in how you
administered systems used to be really irritating; reducing gratuitous
difference where neither approach is better, just different ways of doing
the same thing, is a feature to me.

What I want out of a GR is to decide the deeper meta question of just how
much effort the project wants to put into problems like this.  The
*easiest* approach for Debian (assuming you agree with me about moving to
a declarative syntax) would be to just say sysusers.d is now supported and
preferred (except possibly in edge cases where it won't work; places where
adduser is a pre-dependency will require special handling), and use the
existing implementation and move on.  This would obviously break sysvinit
until someone wrote an equivalent program.

A more moderate approach would be to say that once that alternative
implementation was written, or alternately we've established that
systemd-sysuers will work on sysvinit systems and we're at least somewhat
committed to keeping it that way or writing something new if it doesn't,
*then* we can start using sysusers.d, but until then it's not allowed (and
there's a bug in the tomcat9 package).

Yet another option would be to say that we like adduser and maintainers
are still required to use adduser, and systemd-sysusers is not supported
and not allowed.

Of course, we shouldn't use a GR to decide this for systemd-sysusers
specifically.  That's way too detailed for a GR.  But the point of many of
us in the thread is that pretty much exactly this same set of alternatives
are present for something like ten different facilities (if not more).  I
don't think we actually want to make separate conflicting decisions about
each one; I'm pretty sure that there is a general *philosophy* that we
want to apply here, which is roughly somewhere on a spectrum between
"let's start using systemd native services whenever they're available,
stable, and solve some Debian problem, regardless of whether that breaks
sysvinit" to "all this systemd stuff is unappealing and inferior to what
we can do ourselves; let's decide to not use it and stick with our
facilities."

(Note that there is another option, which is "let's go all in on systemd
and use the systemd-native way of doing *everything*, right away."  I'm
fairly sure that at most a tiny minority of folks in Debian want to do
that; I'm pretty sure not even the systemd maintainers want that.  Rather,
the most aggressive option I expect anyone to support in significant
numbers still implies some sort of Policy vetting of a new facility to
make sure it solves a real problem and that we've given some thought to
how to integrate with it before we just start using it.  For instance, we
would want to make sure that systemd-sysusers honors our system UID ranges
and naming rules.)

I truly don't know where on that spectrum the *project* wants to be.  I
know where a lot