Add systemd

  • Open
  • quality assurance status badge
Details
5 participants
  • Efraim Flashner
  • Leo Prikler
  • Leo Famulari
  • Ludovic Courtès
  • Tony O
Owner
unassigned
Submitted by
Tony O
Severity
normal
T
T
Tony O wrote on 8 Jun 2021 18:19
(name . guix-patches@gnu.org)(address . guix-patches@gnu.org)
dvQW5QOoMhwaIXz7zMjE5FemgwPRLjI5ygh4wgbnFN2zo3gBq0-FrBzSeS78AnUQbLTcCyyMeywb5DGDy4AcGA==@fron.io
Hello.

Unsure what the conventional prelude here is, see attached my patch to add systemd to (gnu packages freedesktop) for use as a library in other packages.

Thanks

--
ix/ixmpp <on> libera
Attachment: file
Attachment: signature.asc
L
L
Ludovic Courtès wrote on 9 Jun 2021 19:42
(name . Tony O)(address . me@fron.io)(address . 48924@debbugs.gnu.org)
87wnr3aqa6.fsf@gnu.org
Hi Tony!

Tony O <me@fron.io> skribis:

Toggle quote (9 lines)
> From f2c7d9f76ab8f2dcaaf8d4fdfb1f050fdb04c588 Mon Sep 17 00:00:00 2001
> From: Tony Olagbaiye <me@fron.io>
> Date: Tue, 8 Jun 2021 17:15:02 +0100
> Subject: [PATCH] gnu: Add systemd
>
> ---
> gnu/packages/freedesktop.scm | 222 +++++++++++++++++++++++++++++++++++
> 1 file changed, 222 insertions(+)

Woow, quite a piece of work! Is this based on Marius’ earlier work?

The policy for Guix is to accept free software packages; this one
clearly fits the bill.

Now, it would be unusable, unless/until Guix System supports systemd (an
option I do not support). For example, ‘guix install systemd’ wouldn’t
be of any use, right?

All in all, with my co-maintainer hat on, it seems to me that the
maintenance cost would be high (because it’s a large piece of software
that evolves very quickly), for a package that’d be practically
unusable, so I’d lean towards not including it.

WDYT?

Thanks,
Ludo’.
T
T
Tony O wrote on 9 Jun 2021 20:08
(address . ludo@gnu.org)(name . 48924)(address . 48924@debbugs.gnu.org)
YNI_xB5G_0jHAWpD9mD6rWGMzXtE6P0dMG0L4wy_E8SDJssGgaaHlgVe9TRpuJmv5Q-0elQfKCfqexhQAY0Gkg==@fron.io
Hi,

Yes, it is based on mbakke's work, I updated the version to latest stable and fixed the new errors :)

I'm quite happy to keep it outside guix if it's not deemed suitable, I was just encouraged to upstream stuff rather than keep things to myself.

My usecase at least doesnt require regular updating, so for things dependent on just "a libsystemd" this would work fine.

Whatever happens happens!
Best,
ix
\-------- Original Message --------
On 9 Jun 2021, 18:42, Ludovic Courtès < ludo@gnu.org> wrote:

Toggle quote (36 lines)
>
>
>
> Hi Tony!
>
> Tony O <me@fron.io> skribis:
>
> > From f2c7d9f76ab8f2dcaaf8d4fdfb1f050fdb04c588 Mon Sep 17 00:00:00 2001
> > From: Tony Olagbaiye <me@fron.io>
> > Date: Tue, 8 Jun 2021 17:15:02 +0100
> > Subject: \[PATCH\] gnu: Add systemd
> >
> > ---
> > gnu/packages/freedesktop.scm \| 222 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 222 insertions(+)
>
> Woow, quite a piece of work! Is this based on Marius’ earlier work?
> https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00001.html
>
> The policy for Guix is to accept free software packages; this one
> clearly fits the bill.
>
> Now, it would be unusable, unless/until Guix System supports systemd (an
> option I do not support). For example, ‘guix install systemd’ wouldn’t
> be of any use, right?
>
> All in all, with my co-maintainer hat on, it seems to me that the
> maintenance cost would be high (because it’s a large piece of software
> that evolves very quickly), for a package that’d be practically
> unusable, so I’d lean towards not including it.
>
> WDYT?
>
> Thanks,
> Ludo’.
>
Attachment: file
Attachment: signature.asc
L
L
Ludovic Courtès wrote on 9 Jun 2021 22:25
(name . Tony O)(address . me@fron.io)(name . 48924)(address . 48924@debbugs.gnu.org)
87sg1qbxb0.fsf_-_@gnu.org
Hello,

Tony O <me@fron.io> skribis:

Toggle quote (2 lines)
> Yes, it is based on mbakke's work, I updated the version to latest stable and fixed the new errors :)

Heh, neat. Be sure to preserve Marius’ copyright line.

Toggle quote (3 lines)
> I'm quite happy to keep it outside guix if it's not deemed suitable, I was just encouraged to upstream stuff rather
> than keep things to myself.

Sure, it’s a good idea in general!

Toggle quote (3 lines)
> My usecase at least doesnt require regular updating, so for things dependent on just "a libsystemd" this would work
> fine.

So what’s your use case?

Specifically, what’s the answer to this question:

Toggle quote (4 lines)
> Now, it would be unusable, unless/until Guix System supports systemd (an
> option I do not support). For example, ‘guix install systemd’ wouldn’t
> be of any use, right?

By knowing the answer and understanding potential use cases, we can make
more informed decisions.

TIA,
Ludo’.
T
T
Tony O wrote on 9 Jun 2021 22:31
(address . ludo@gnu.org)(address . 48924@debbugs.gnu.org)
rlnRDNsOy3WhfYIT2u39eHjY16ckiPJyCzJBFBcR-WDKtnV2sgow4pu1qYMTIOSatQTJYWXasChOlRgKHEyYbw==@fron.io
In particular, im using it to relink against a nonfree binary which responds badly to tampering, so im using it only as a library. Others (on irc) expressed interest in using the package, and i can envision other usecases such as container images.

The downside to it being in my repo or being in "another channel" is that anyone wanting to use it then risks nonfree software, and that's already been lamented when i offered to do this in irc.

I'll leave it to your discretion...
Best,
ix
\-------- Original Message --------
On 9 Jun 2021, 21:25, Ludovic Courtès < ludo@gnu.org> wrote:

Toggle quote (33 lines)
>
>
>
> Hello,
>
> Tony O <me@fron.io> skribis:
>
> > Yes, it is based on mbakke's work, I updated the version to latest stable and fixed the new errors :)
>
> Heh, neat. Be sure to preserve Marius’ copyright line.
>
> > I'm quite happy to keep it outside guix if it's not deemed suitable, I was just encouraged to upstream stuff rather
> > than keep things to myself.
>
> Sure, it’s a good idea in general!
>
> > My usecase at least doesnt require regular updating, so for things dependent on just "a libsystemd" this would work
> > fine.
>
> So what’s your use case?
>
> Specifically, what’s the answer to this question:
>
> > Now, it would be unusable, unless/until Guix System supports systemd (an
> > option I do not support). For example, ‘guix install systemd’ wouldn’t
> > be of any use, right?
>
> By knowing the answer and understanding potential use cases, we can make
> more informed decisions.
>
> TIA,
> Ludo’.
>
Attachment: file
Attachment: signature.asc
L
L
Leo Prikler wrote on 10 Jun 2021 00:33
(address . 48924@debbugs.gnu.org)
8c9f7f3961274fd2fef3b715a0ff8b21026bb283.camel@student.tugraz.at
Hello,

As the one, who encouraged the sending of this patch I do have a few
words to say. First of all, I misunderstood the context -- rather than
systemd as a whole, I thought it would just be some systemd-related
package. This does not matter that much, since a fully functioning
systemd package would still be nice to have, but it still is important
to distinguish between plain systemd, which doesn't work on Guix for
various reasons and replacement libraries like elogind, which do.

Next, let's address the elephant in the room:
Am Mittwoch, den 09.06.2021, 20:31 +0000 schrieb Tony O:
Toggle quote (2 lines)
> In particular, im using it to relink against a nonfree binary which
> responds badly to tampering, so im using it only as a library.
A systemd package, which serves no purpose other than being linked
against nonfree binaries does not sound particularly useful, especially
not when thinking in terms of FSDG compliance. We don't even know
whether *free* software linked against this systemd would behave as
expected, let alone nonfree software.

This was in part already discussed in IRC, but to reiterate, I think
that the systemd package should be usable in some capacity -- be it,
that we can run systemd as user daemons or be it, that we can
*meaningfully* link free software against it. Note however, that the
latter most likely implies the first, since there's no meaningful
linkage against systemd without one of its daemons running.

Toggle quote (2 lines)
> Others (on irc) expressed interest in using the package, and i can
> envision other usecases such as container images.
Interest in a working systemd package has apparently existed longer
than I was aware of, it's just the specifics of the term "working",
that we need to argue about.

Toggle quote (3 lines)
> The downside to it being in my repo or being in "another channel" is
> that anyone wanting to use it then risks nonfree software, and that's
> already been lamented when i offered to do this in irc.
I don't think, that's a realistic risk. For one, people could just
cherry-pick systemd from your tainted channel, but more importantly
you're assuming that the systemd you've packaged works in a context
other than linking it against some evil binary without actually wanting
to use it. Which is not to say that it doesn't, just that there hasn't
been enough evidence to support that claim yet.

There's nothing wrong with pushing WIP stuff to your own repo or any
other channel that will accept them. There is however a problem with
leaving them there and not even considering to submit them towards Guix
(assuming that having a package for some given software in Guix proper
is an option, regardless of the current state of the package
definition), because then Guix will be blissfully unaware that a
perhaps even proper package definition for it exists and might thereby
be missing some awesome software.

As far as the patch itself is concerned, there are a few FIXMEs too
many for me to consider it ready -- in particular the double disabling
of tests rubs me the wrong way. There's also some minor aesthetic
stuff like the "add-shared-lib" phase, which is both not informative
and bound to break with version updates, but I think that should be
manageable.

Going forward, I'd like to ask you (or anyone else willing to package
systemd) to do the following:
1. Can you look into whether systemd or at least parts of it can be run
from the package inside Guix?
2. Can you look into the disabled tests, particularly those, that are
currently just FIXMEs?

Regards,
Leo
L
L
Ludovic Courtès wrote on 11 Jun 2021 18:39
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87h7i45p9y.fsf@gnu.org
Hi,

Leo Prikler <leo.prikler@student.tugraz.at> skribis:

Toggle quote (9 lines)
> Am Mittwoch, den 09.06.2021, 20:31 +0000 schrieb Tony O:
>> In particular, im using it to relink against a nonfree binary which
>> responds badly to tampering, so im using it only as a library.
> A systemd package, which serves no purpose other than being linked
> against nonfree binaries does not sound particularly useful, especially
> not when thinking in terms of FSDG compliance. We don't even know
> whether *free* software linked against this systemd would behave as
> expected, let alone nonfree software.

Yeah, that’s definitely not a good reason to include it.

Toggle quote (7 lines)
> This was in part already discussed in IRC, but to reiterate, I think
> that the systemd package should be usable in some capacity -- be it,
> that we can run systemd as user daemons or be it, that we can
> *meaningfully* link free software against it. Note however, that the
> latter most likely implies the first, since there's no meaningful
> linkage against systemd without one of its daemons running.

Given the maintenance cost, we’d need a more convincing argument than
“should be usable”. :-)

So it seems to me that we’re done with it as far as inclusion in Guix is
concerned. Thoughts?

It’s typically a situation where an external channel is more
appropriate, IMO.

Thanks,
Ludo’.
L
L
Leo Prikler wrote on 11 Jun 2021 19:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
6bb174687e5520154f4cb0fefe8306158d594c01.camel@student.tugraz.at
Hi,

Am Freitag, den 11.06.2021, 18:39 +0200 schrieb Ludovic Courtès:
Toggle quote (18 lines)
> > This was in part already discussed in IRC, but to reiterate, I
> > think
> > that the systemd package should be usable in some capacity -- be
> > it,
> > that we can run systemd as user daemons or be it, that we can
> > *meaningfully* link free software against it. Note however, that
> > the
> > latter most likely implies the first, since there's no meaningful
> > linkage against systemd without one of its daemons running.
>
> Given the maintenance cost, we’d need a more convincing argument than
> “should be usable”. :-)
>
> So it seems to me that we’re done with it as far as inclusion in Guix
> is concerned. Thoughts?
>
> It’s typically a situation where an external channel is more
> appropriate, IMO.
I'm definitely leaning towards not including it as-is/perhaps having it
in an external channel as well, but I don't think "high maintenance"
should generally be a deterrent against a functioning package (or
rather the only reason to keep a package from being included). Guix
already has packages, that I would consider to be of higher
maintenance, e.g. GNOME, and I do think it would help Guix users if
(parts of) systemd became a viable option. I am simply doubting the
functionality of this package as it currently exists.

That said, I don't think myself to be in a place to make accurate
judgements about entry requirements. I suggested “should be usable” as
a bare minimum because it seemed easy to convey. There are also other
things to consider, like coding style, adherence to packaging
guidelines, etc. with maintainability somewhere among them, but I can't
really phrase all of those well into a simple sentence. I also think
that some reviewer should be able to take an already functioning
package description and perform cosmetic changes to transform it into
one better suited for Guix, though that might be a bit of a
controversial statement.

Regards,
Leo
E
E
Efraim Flashner wrote on 13 Jun 2021 09:31
Re: [bug#48924] Add systemd
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
YMW0R8aZi0s0RXme@3900XT
On Fri, Jun 11, 2021 at 07:11:18PM +0200, Leo Prikler wrote:
Toggle quote (45 lines)
> Hi,
>
> Am Freitag, den 11.06.2021, 18:39 +0200 schrieb Ludovic Courtès:
> > > This was in part already discussed in IRC, but to reiterate, I
> > > think
> > > that the systemd package should be usable in some capacity -- be
> > > it,
> > > that we can run systemd as user daemons or be it, that we can
> > > *meaningfully* link free software against it. Note however, that
> > > the
> > > latter most likely implies the first, since there's no meaningful
> > > linkage against systemd without one of its daemons running.
> >
> > Given the maintenance cost, we’d need a more convincing argument than
> > “should be usable”. :-)
> >
> > So it seems to me that we’re done with it as far as inclusion in Guix
> > is concerned. Thoughts?
> >
> > It’s typically a situation where an external channel is more
> > appropriate, IMO.
> I'm definitely leaning towards not including it as-is/perhaps having it
> in an external channel as well, but I don't think "high maintenance"
> should generally be a deterrent against a functioning package (or
> rather the only reason to keep a package from being included). Guix
> already has packages, that I would consider to be of higher
> maintenance, e.g. GNOME, and I do think it would help Guix users if
> (parts of) systemd became a viable option. I am simply doubting the
> functionality of this package as it currently exists.
>
> That said, I don't think myself to be in a place to make accurate
> judgements about entry requirements. I suggested “should be usable” as
> a bare minimum because it seemed easy to convey. There are also other
> things to consider, like coding style, adherence to packaging
> guidelines, etc. with maintainability somewhere among them, but I can't
> really phrase all of those well into a simple sentence. I also think
> that some reviewer should be able to take an already functioning
> package description and perform cosmetic changes to transform it into
> one better suited for Guix, though that might be a bit of a
> controversial statement.
>
> Regards,
> Leo
>

I'd also argue that some of the bioinformatics packages are high
maintenance and no one likes having to update them.

One thing that I've noticed with elogind is that it doesn't interact
will with systemd-logind on other machines. Any loginctl command
normally fails because the version we have looks in /var/lib/elogind and
systemd uses /var/lib/systemd.

It would also be useful to figure out how to run user level systemd
services, likely using systemd itself, for those who are interested in
doing so.

I've heard that systemd is modular, in that at compile time it's
possible to choose which modules to build. Perhaps we can build a subset
which are actually useful for us?

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmDFtEYACgkQQarn3Mo9
g1EKbxAArfWqwXlvjGGnNtnAavmnPtFmhAeWPsshxClOo8HP40eeS3OXG7znm4+f
hqFlZdaP47iPawXQJq8Xvm6b0gBaGfVed5gC0Sfa5BUP1FOCmJjcXKovkjU7UHz1
d4ej5izw6Cw3RD67n8Q94rleirfsHMVwGD9nrD2Wml7Z2TDvlsphk2vdLOnPYH9V
kV72wTO2JX2enyijoMCRv1MEmkQZPs6KXqq2dLu8Ysd85QLBWbhCjN8RVfbObNM5
r7G0crg6Ee7Uy20kZT1KGYWema8G29X3QIV8XF8XIybcQdC09ePZGZU51YiSdoju
DZ1koLUqh/iL05+8yDIN+tBKKDkdBIZOuWiUc3BOEGRrxFH+LNAnYVCTiGe7LVx9
Pm2vM7DXY4fW9H1KcoXacgXkZdgExjZPyDke+CxAHXBhdnQmwBfxBAxOC4aoyCNF
yg69+TDW8SAroLyIm9QZ+YXJPrv0mfMWee7qN01tKOeyvOk91CKtg8t2tkyQi6Pr
Se1YndWaLbHQkWLwg9JiQl6TFRuS8AGEaq/t/Sk7+3rNEiskALYMYFhgGm6SvVF6
wfrrkBz+vV21/rPufZ3Eq7/x/FdP53I4svpYO1Gt9iq8gtASWERzcdQxAhagNm+x
j6zjDeeGH0G8OulWgRGQEKKAfyyUnTPY1GESVfw3n8WJ3naMurA=
=M6RO
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 13 Jun 2021 11:36
(name . Efraim Flashner)(address . efraim@flashner.co.il)
87sg1m2jjl.fsf@gnu.org
Hi!

Efraim Flashner <efraim@flashner.co.il> skribis:

Toggle quote (2 lines)
> On Fri, Jun 11, 2021 at 07:11:18PM +0200, Leo Prikler wrote:

[...]

Toggle quote (5 lines)
>> I'm definitely leaning towards not including it as-is/perhaps having it
>> in an external channel as well, but I don't think "high maintenance"
>> should generally be a deterrent against a functioning package (or
>> rather the only reason to keep a package from being included).

[...]

Toggle quote (3 lines)
> I'd also argue that some of the bioinformatics packages are high
> maintenance and no one likes having to update them.

I agree with the two of you. What I’m saying is that if in addition of
having a high maintenance cost, it’s pretty much unusable, then that’s
not good.

Toggle quote (5 lines)
> One thing that I've noticed with elogind is that it doesn't interact
> will with systemd-logind on other machines. Any loginctl command
> normally fails because the version we have looks in /var/lib/elogind and
> systemd uses /var/lib/systemd.

Oh you’re saying that someone on a foreign distro might be interested in
running ‘systemctl’ from Guix’ ‘systemd’ package? That sounds like a
bit far-fetched to me, dunno.

Toggle quote (8 lines)
> It would also be useful to figure out how to run user level systemd
> services, likely using systemd itself, for those who are interested in
> doing so.
>
> I've heard that systemd is modular, in that at compile time it's
> possible to choose which modules to build. Perhaps we can build a subset
> which are actually useful for us?

Good question, no idea.

Thanks,
Ludo’.
E
E
Efraim Flashner wrote on 13 Jun 2021 14:19
(name . Ludovic Courtès)(address . ludo@gnu.org)
YMX3wA87imqUahTK@3900XT
On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:
Toggle quote (15 lines)
> Hi!
>
> Efraim Flashner <efraim@flashner.co.il> skribis:
>
> [...]
>
> > One thing that I've noticed with elogind is that it doesn't interact
> > will with systemd-logind on other machines. Any loginctl command
> > normally fails because the version we have looks in /var/lib/elogind and
> > systemd uses /var/lib/systemd.
>
> Oh you’re saying that someone on a foreign distro might be interested in
> running ‘systemctl’ from Guix’ ‘systemd’ package? That sounds like a
> bit far-fetched to me, dunno.

I meant it more like this:

(ins)efraim@g4:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 118 sddm seat0
12683 1000 efraim seat0 tty2
13 1000 efraim seat0 tty3
15005 1000 efraim pts/2

4 sessions listed.

(ins)efraim@3900XT ~$ loginctl list-sessions
SESSION UID USER SEAT TTY
c1 980 sddm seat0
c2 1000 efraim seat0 tty8

2 sessions listed.
(ins)efraim@3900XT ~$ loginctl -H g4 list-sessions
bash: line 1: elogind-stdio-bridge: command not found

It should be possible to interoperate between them
(-H --host=[USER@]HOST Operate on remote host)

Toggle quote (13 lines)
> > It would also be useful to figure out how to run user level systemd
> > services, likely using systemd itself, for those who are interested in
> > doing so.
> >
> > I've heard that systemd is modular, in that at compile time it's
> > possible to choose which modules to build. Perhaps we can build a subset
> > which are actually useful for us?
>
> Good question, no idea.
>
> Thanks,
> Ludo’.

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmDF970ACgkQQarn3Mo9
g1HaDw//Q+4d43AhQ7ppBt86wHJhl4+ArArx8bDeZWH2OOuYUDv3nIuQ59qLmAc0
OEReFAQoeRVrWEsZe5AQGrD+khLNrbRqzOYgvaec6OGRasinXNzp3Oe0QGNzG3AH
JEicRx4TZ6CISpKzeFVs8j3Mm8WDJN+p3WQR+zradKqGSSVtLciU+4eTqE+nM/sB
qK/UPi+TS8LOyTF3wxzuqBycjy9RuVC69/r6mbilTr1nWmlDc+qmnp3gFlBJ2R5b
Xz1NtOtlmrMBLy28dZP7T5ocP/5/pdVDTeUDFyUtEM1UCX00e9DHU8IMXXc7hlva
nXCefAEKgsfG65sre1PPh+6U9Yeb3MU62eEouKWX1ujxYDozd/wAQBVyieAL0Gu4
+7WstlhqVFgtPMUeMfsFRIJnSqTg34qIGCItc0SiMXHaFuLHoZSwlsD3NDzGNcqt
n9WRAYrJx07qFTHueEbdB6SuQ84jT9933hbyqvSRTl+MnAP6ZKyGpK+yMrAgvioq
4O32f93kGANglRecZiZY1noUG8gZep6/53Bc08JJsTZ4KyGqMID1Tk7L+UgNbCg8
cKft0izXRbZgnllU6kcCDw00uNlS9NPYULLDcNsprvAW7VCdfUvKmmrSYr2zIF74
w0OdVbTaKrWqvvyhqReMDJBqtM6nKtw8eYrjLaoPt0HRYjUbKus=
=ZBTn
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 13 Jun 2021 20:14
(name . Ludovic Courtès)(address . ludo@gnu.org)
YMZLEDYuMSZwxfzP@jasmine.lan
On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:
Toggle quote (8 lines)
> Efraim Flashner <efraim@flashner.co.il> skribis:
> > I'd also argue that some of the bioinformatics packages are high
> > maintenance and no one likes having to update them.
>
> I agree with the two of you. What I’m saying is that if in addition of
> having a high maintenance cost, it’s pretty much unusable, then that’s
> not good.

I share Efraim's point — maintenance burden has never been a primary
reason to exclude things from Guix. I think it's important to handle
this patch in a manner that is consistent with the precedent set by
years of Guix code review.

I'm sorry, I haven't read this entire discussion closely. Tony, does
this package seem useful for you?

There is a weird gamergate-esque faction in the free software community
who hate systemd for reasons that are basically inexplicable. It seems
to be one of several proxy battles fought by a far-right [0] political
camp in a struggle over the direction of free software (I'm not sure
*who* they are fighting... most distros just ignore them). We should
recognize their longwinded sophistry for what it is. Systemd works and
it works very well.

Maybe we *should* start rejecting very high-maintenance contributions if
we do not think they will be maintained adequately. But, I do not think
that systemd should be the package that spurs that decision, because of
the special importance that some people have placed on systemd, which
has nothing to do with software, either technically or in terms of
software freedom.

Toggle quote (4 lines)
> Oh you’re saying that someone on a foreign distro might be interested in
> running ‘systemctl’ from Guix’ ‘systemd’ package? That sounds like a
> bit far-fetched to me, dunno.

I use systemd extensively with Guix-on-Debian, and it's one component
that I will probably not replace with a Guix package. It's too deeply
integrated within Debian for me to feel confident replacing it, although
perhaps systemctl will work fine when provided by a 3rd party. I really
don't know.

The benefits of Guix on other distros — the strong control over the
dependency graph and ability to modify it and roll it back — do not hold
for systemd, in my opinion. Debian's operating system integration and QA
process is good, at this level of the system.

[0] I know that's a gross generalization, but it just seems that way to
me
T
T
Tony O wrote on 13 Jun 2021 20:54
Qgzo1on2NZiWvZk_r8asfneqqAWJwn8LLydDNPQfV_zVTuw9mBiCQG2oEbaTDOhEa3cKEklNRcU2N7agPPznZg==@fron.io
Hi leo. As mentioned previously, I do find this useful, I'm using it currently in LD\_PRELOAD for a nonfree package that requires systemd and does not function with elogind patched in instead. Other usecases exist but they're just speculation so far, though the package is otherwise fully functional.
\-------- Original Message --------
On 13 Jun 2021, 19:14, Leo Famulari < leo@famulari.name> wrote:

Toggle quote (53 lines)
>
>
>
> On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:
> > Efraim Flashner <efraim@flashner.co.il> skribis:
> > > I'd also argue that some of the bioinformatics packages are high
> > > maintenance and no one likes having to update them.
> >
> > I agree with the two of you. What I’m saying is that if in addition of
> > having a high maintenance cost, it’s pretty much unusable, then that’s
> > not good.
>
> I share Efraim's point — maintenance burden has never been a primary
> reason to exclude things from Guix. I think it's important to handle
> this patch in a manner that is consistent with the precedent set by
> years of Guix code review.
>
> I'm sorry, I haven't read this entire discussion closely. Tony, does
> this package seem useful for you?
>
> There is a weird gamergate-esque faction in the free software community
> who hate systemd for reasons that are basically inexplicable. It seems
> to be one of several proxy battles fought by a far-right \[0\] political
> camp in a struggle over the direction of free software (I'm not sure
> \*who\* they are fighting... most distros just ignore them). We should
> recognize their longwinded sophistry for what it is. Systemd works and
> it works very well.
>
> Maybe we \*should\* start rejecting very high-maintenance contributions if
> we do not think they will be maintained adequately. But, I do not think
> that systemd should be the package that spurs that decision, because of
> the special importance that some people have placed on systemd, which
> has nothing to do with software, either technically or in terms of
> software freedom.
>
> > Oh you’re saying that someone on a foreign distro might be interested in
> > running ‘systemctl’ from Guix’ ‘systemd’ package? That sounds like a
> > bit far-fetched to me, dunno.
>
> I use systemd extensively with Guix-on-Debian, and it's one component
> that I will probably not replace with a Guix package. It's too deeply
> integrated within Debian for me to feel confident replacing it, although
> perhaps systemctl will work fine when provided by a 3rd party. I really
> don't know.
>
> The benefits of Guix on other distros — the strong control over the
> dependency graph and ability to modify it and roll it back — do not hold
> for systemd, in my opinion. Debian's operating system integration and QA
> process is good, at this level of the system.
>
> \[0\] I know that's a gross generalization, but it just seems that way to
> me
>
Attachment: file
Attachment: signature.asc
L
L
Leo Prikler wrote on 13 Jun 2021 21:00
7a89e12d172b71e524498ddfbc8899ab2efe4f0c.camel@student.tugraz.at
Am Sonntag, den 13.06.2021, 18:54 +0000 schrieb Tony O:
Toggle quote (5 lines)
> Hi leo. As mentioned previously, I do find this useful, I'm using it
> currently in LD_PRELOAD for a nonfree package that requires systemd
> and does not function with elogind patched in instead. Other usecases
> exist but they're just speculation so far, though the package is
> otherwise fully functional.
Please describe "fully functional" in more detail. "I use it to fix
this completely borked proprietary software" is not enough grounds to
assume full feature coverage. Instead, I'd argue that the disabling of
tests without explanation kinda proves the opposite.
Toggle quote (77 lines)
> -------- Original Message --------
> On 13 Jun 2021, 19:14, Leo Famulari < leo@famulari.name> wrote:
> > On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:
> > > Efraim Flashner <efraim@flashner.co.il> skribis:
> > > > I'd also argue that some of the bioinformatics packages are
> > high
> > > > maintenance and no one likes having to update them.
> > >
> > > I agree with the two of you. What I’m saying is that if in
> > addition of
> > > having a high maintenance cost, it’s pretty much unusable, then
> > that’s
> > > not good.
> >
> > I share Efraim's point — maintenance burden has never been a
> > primary
> > reason to exclude things from Guix. I think it's important to
> > handle
> > this patch in a manner that is consistent with the precedent set by
> > years of Guix code review.
> >
> > I'm sorry, I haven't read this entire discussion closely. Tony,
> > does
> > this package seem useful for you?
> >
> > There is a weird gamergate-esque faction in the free software
> > community
> > who hate systemd for reasons that are basically inexplicable. It
> > seems
> > to be one of several proxy battles fought by a far-right [0]
> > political
> > camp in a struggle over the direction of free software (I'm not
> > sure
> > *who* they are fighting... most distros just ignore them). We
> > should
> > recognize their longwinded sophistry for what it is. Systemd works
> > and
> > it works very well.
> >
> > Maybe we *should* start rejecting very high-maintenance
> > contributions if
> > we do not think they will be maintained adequately. But, I do not
> > think
> > that systemd should be the package that spurs that decision,
> > because of
> > the special importance that some people have placed on systemd,
> > which
> > has nothing to do with software, either technically or in terms of
> > software freedom.
> >
> > > Oh you’re saying that someone on a foreign distro might be
> > interested in
> > > running ‘systemctl’ from Guix’ ‘systemd’ package? That sounds
> > like a
> > > bit far-fetched to me, dunno.
> >
> > I use systemd extensively with Guix-on-Debian, and it's one
> > component
> > that I will probably not replace with a Guix package. It's too
> > deeply
> > integrated within Debian for me to feel confident replacing it,
> > although
> > perhaps systemctl will work fine when provided by a 3rd party. I
> > really
> > don't know.
> >
> > The benefits of Guix on other distros — the strong control over the
> > dependency graph and ability to modify it and roll it back — do not
> > hold
> > for systemd, in my opinion. Debian's operating system integration
> > and QA
> > process is good, at this level of the system.
> >
> > [0] I know that's a gross generalization, but it just seems that
> > way to
> > me
> >
T
T
Tony O wrote on 13 Jun 2021 21:56
WjWOB6SEHVWj_yb7XY2hHap6RSYQCliMBzpT5GoeFwCdoYKDFRmX74U0qPRlZFOo5Z7xAsXcFPGi3bO6fYE2ng==@fron.io
\-------- Original Message --------
On 13 Jun 2021, 20:00, Leo Prikler < leo.prikler@student.tugraz.at> wrote:
Am Sonntag, den 13.06.2021, 18:54 +0000 schrieb Tony O:
Toggle quote (5 lines)
> Hi leo. As mentioned previously, I do find this useful, I'm using it
> currently in LD\_PRELOAD for a nonfree package that requires systemd
> and does not function with elogind patched in instead. Other usecases
> exist but they're just speculation so far, though the package is
> otherwise fully functional.
Please describe "fully functional" in more detail. "I use it to fix
this completely borked proprietary software" is not enough grounds to
assume full feature coverage. Instead, I'd argue that the disabling of
tests without explanation kinda proves the opposite.

Okay, I was going by the similarity to the nix package, but if you require concrete proof then I just built it without the sandbox and with my kernel supporting cgroups. Exactly 15 test fail, out of nearly 400. Each of them by best approximation due to binaries not in scope and/or systemd not being PID1 (as is repeatedly echoed on the error log).

If those 15 tests pose a concrete issue to you, I would consider fixing them, but only with the guarantee that the result end up in guix. As it stands disposition seems to be to not merge this, so I'll reserve the effort.
Attachment: file
Attachment: signature.asc
L
L
Leo Prikler wrote on 13 Jun 2021 23:44
7519d8b43228f04281990bebda04ca785563b21f.camel@student.tugraz.at
Am Sonntag, den 13.06.2021, 19:56 +0000 schrieb Tony O:
Toggle quote (11 lines)
> Okay, I was going by the similarity to the nix package, but if you
> require concrete proof then I just built it without the sandbox and
> with my kernel supporting cgroups. Exactly 15 test fail, out of
> nearly 400. Each of them by best approximation due to binaries not in
> scope and/or systemd not being PID1 (as is repeatedly echoed on the
> error log).
>
> If those 15 tests pose a concrete issue to you, I would consider
> fixing them, but only with the guarantee that the result end up in
> guix. As it stands disposition seems to be to not merge this, so I'll
> reserve the effort.
15/400 tests failing sounds somewhat reasonable, especially if we can
explain their failure modes (e.g. stuff like not being PID1). Even if
we add the other tests, that require cgroups on top, that'd be fine,
but we'd have to be able to display all that info in a meaningful
fashion like
;; these tests want systemd to be PID1
"foo" "bar" "baz"
;; these tests require cgroups
"spam" "ham" "eggs"
;; these are missing libquux
"i" "ran" "out" "of" "funny" "variable" "names"
However, this is somewhat different from the package description at
hand, which lacks those explanations.

The reference point is of course the thing that's compiled within the
sandbox, not anything without. Having most tests pass when compiling
stuff "normally" with Guix is perhaps a good indicator, that at least
compiling works, but it's really just that.

Finally – and this might be my ignorance of the systemd test suite
speaking, so ignore me if I say something stupid – just because we have
a test coverage of let's say 90% or even 100%, doesn't mean that the
installed binaries will still be able to work. There is a large
potential for bugs to sneek in, e.g. through an insufficient wrap
phase, so for software like systemd, we should be able to do some
trivial tasks, e.g. `systemctl start hello-world` with a systemd, that
has not claimed PID1.

TL;DR: the plan is to
- Get the sandboxed package to match up as closely as you can get to
the non-sandboxed one w.r.t. testing.
- Document how the remaining disabled tests fail.
- Prove, that components of systemd run when invoked directly from the
store/from within a suitable environment.

It is probably still a somewhat long and bumpy road, but in my personal
opinion one that has an end.
@lfam, ludo, efraim: WDYT?

Regards,
Leo
L
L
Leo Famulari wrote on 14 Jun 2021 00:35
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
YMaIQDhGK2B1ZDfe@jasmine.lan
On Sun, Jun 13, 2021 at 11:44:47PM +0200, Leo Prikler wrote:
Toggle quote (4 lines)
> It is probably still a somewhat long and bumpy road, but in my personal
> opinion one that has an end.
> @lfam, ludo, efraim: WDYT?

To me, it seems like we are applying a slightly higher standard to this
patch than to other submissions of complex packages whose functionality
is difficult to evaluate.
L
L
Ludovic Courtès wrote on 14 Jun 2021 14:30
(name . Leo Famulari)(address . leo@famulari.name)
877diwy6gd.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (9 lines)
> On Sun, Jun 13, 2021 at 11:44:47PM +0200, Leo Prikler wrote:
>> It is probably still a somewhat long and bumpy road, but in my personal
>> opinion one that has an end.
>> @lfam, ludo, efraim: WDYT?
>
> To me, it seems like we are applying a slightly higher standard to this
> patch than to other submissions of complex packages whose functionality
> is difficult to evaluate.

No no, I was careful to apply the same standards. :-) My main
question is whether it’s usable at all:


Tony’s use case has to do with satisfying the dependencies of a
binary-only proprietary executable:


To me, that use case alone isn’t enough to justify maintaining systemd
in Guix proper.

However, if, as Efraim suggests, a systemd package has some uses, at
least on foreign distros, then that’s fine with me. It’s a very narrow
use case (running ‘loginctl’ on a foreign distro), but why not.

Thoughts?

Ludo’.
L
L
Leo Famulari wrote on 14 Jun 2021 17:25
(name . Ludovic Courtès)(address . ludo@gnu.org)
YMd01e33raUWNh9P@jasmine.lan
On Mon, Jun 14, 2021 at 02:30:10PM +0200, Ludovic Courtès wrote:
Toggle quote (13 lines)
> No no, I was careful to apply the same standards. :-) My main
> question is whether it’s usable at all:
>
> https://issues.guix.gnu.org/48924#1
>
> Tony’s use case has to do with satisfying the dependencies of a
> binary-only proprietary executable:
>
> https://issues.guix.gnu.org/48924#2
>
> To me, that use case alone isn’t enough to justify maintaining systemd
> in Guix proper.

It's true, that's not really a good reason to add the package. There are
probably some existing Guix packages with a similar use case, but nobody
ever said it out loud. It's a lesson in the value of discretion, I
suppose.

Toggle quote (6 lines)
> However, if, as Efraim suggests, a systemd package has some uses, at
> least on foreign distros, then that’s fine with me. It’s a very narrow
> use case (running ‘loginctl’ on a foreign distro), but why not.
>
> Thoughts?

To me, it's a simple scenario: We received a contribution to add a
popular free software program.

But it has been complicated by the broader context, about which I
already shared my uncharitable interpretation, and that's a shame. Now
there is a big discussion about it.

I would add the package. We should feel free to remove packages
(especially leaf packages) that aren't building or are far behind the
upstream release schedule if nobody is trying to fix them. We don't have
to assume a burden of maintenance.
E
E
Efraim Flashner wrote on 15 Jun 2021 08:35
(name . Ludovic Courtès)(address . ludo@gnu.org)
YMhKPHvWA32LwFve@3900XT
On Mon, Jun 14, 2021 at 02:30:10PM +0200, Ludovic Courtès wrote:
Toggle quote (34 lines)
> Hi,
>
> Leo Famulari <leo@famulari.name> skribis:
>
> > On Sun, Jun 13, 2021 at 11:44:47PM +0200, Leo Prikler wrote:
> >> It is probably still a somewhat long and bumpy road, but in my personal
> >> opinion one that has an end.
> >> @lfam, ludo, efraim: WDYT?
> >
> > To me, it seems like we are applying a slightly higher standard to this
> > patch than to other submissions of complex packages whose functionality
> > is difficult to evaluate.
>
> No no, I was careful to apply the same standards. :-) My main
> question is whether it’s usable at all:
>
> https://issues.guix.gnu.org/48924#1
>
> Tony’s use case has to do with satisfying the dependencies of a
> binary-only proprietary executable:
>
> https://issues.guix.gnu.org/48924#2
>
> To me, that use case alone isn’t enough to justify maintaining systemd
> in Guix proper.
>
> However, if, as Efraim suggests, a systemd package has some uses, at
> least on foreign distros, then that’s fine with me. It’s a very narrow
> use case (running ‘loginctl’ on a foreign distro), but why not.
>
> Thoughts?
>
> Ludo’.

This actually works better for on Guix System than on a foreign distro

(ins)efraim@3900XT ~/workspace/guix$ /gnu/store/khpdv70slxmvrla1q8lnkkq1cxv9pm75-systemd-247/bin/loginctl -H g4 list-sessions
SESSION UID USER SEAT TTY
1 118 sddm seat0
12683 1000 efraim seat0 tty2
13 1000 efraim seat0 tty3
15005 1000 efraim pts/2

4 sessions listed.
(ins)efraim@3900XT ~/workspace/guix$ loginctl -H g4 list-sessions
bash: line 1: elogind-stdio-bridge: command not found

That said, the package definitely needs some work. The source URI is
autogenerated, we shouldn't need glibc as an input, and I'm guessing
that setting all the config directories to out would cause problems. Not
to mention the extra bits that don't add any value to Guix System.

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmDISjwACgkQQarn3Mo9
g1E5hBAAwm84j4ERYyWeBOP9xAG2sFyLWvkgrGzpItqCNMpLaC4nAaFVMTzXov2l
+Y0H0swS4jcM7FpnV3zr4b9weQJmbb+lJwe9/hETzTijGh4E7yXfbp0oJwl1sIKb
DxBqlAso5KjHV3xMk+3LkVq7vRYU3nWhDDMLS1N/9z9NdJmcblk8/Oh26PhPUDIe
fn7biTYYkp5pSpJfxn/7kuX5A/M6R5Qs3hbZg7WhivIUHtKYKmYgOX84nfepc7J6
BgELNQikyERPldi9bJcewLpKiZu+sG/W810Bc56ppVINnn0E5EFV6dMthbUsKH24
h58V/bXzkzQ6PXQVakUvXYTwuXAdIxdj0fQ4CfowM97YiufxT23cg6fKQ4HvC+ki
sUdsW8brqhIj/Ha2XY+HRa/rVhED55T/AwFrWHBYjP6ZH9G4B0bNpLVVxvI3uiz2
NLl8uh1I0tV8zQxf1/V+CND85U1T7BSda5JTE0ilfJmG3CuznMQDfSOT/l2kd1je
9CIJFc+oalLAZtapuVBVVj3Hwyk04e39WNekeHzzqeevpfEYOdOwvtydpDoiEseC
oeYVM34tz3/lZ2FDUbXNXYYPSuEV5JxYKPf/opjiQx0xDcjZnQZqmFmtDa9U9dXT
D2/aZfDUnSIyQq1Ppu4qqc1aQ2oRmqO8sFKwxhpR+BQ3kV5LKWQ=
=alv0
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 15 Jun 2021 11:29
(name . Efraim Flashner)(address . efraim@flashner.co.il)
87r1h3tr10.fsf@gnu.org
Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

Toggle quote (13 lines)
> This actually works better for on Guix System than on a foreign distro
>
> (ins)efraim@3900XT ~/workspace/guix$ /gnu/store/khpdv70slxmvrla1q8lnkkq1cxv9pm75-systemd-247/bin/loginctl -H g4 list-sessions
> SESSION UID USER SEAT TTY
> 1 118 sddm seat0
> 12683 1000 efraim seat0 tty2
> 13 1000 efraim seat0 tty3
> 15005 1000 efraim pts/2
>
> 4 sessions listed.
> (ins)efraim@3900XT ~/workspace/guix$ loginctl -H g4 list-sessions
> bash: line 1: elogind-stdio-bridge: command not found

D’oh! How’s that possible? We should also fix (upgrade?) elogin.

Toggle quote (5 lines)
> That said, the package definitely needs some work. The source URI is
> autogenerated, we shouldn't need glibc as an input, and I'm guessing
> that setting all the config directories to out would cause problems. Not
> to mention the extra bits that don't add any value to Guix System.

Yes, and also Marius’ copyright line should be preserved.

Tony, could you address these issues and send an updated patch?

Thanks, and sorry for the lengthy discussion. :-)

Ludo’.
L
L
Ludovic Courtès wrote on 15 Jun 2021 11:38
(name . Leo Famulari)(address . leo@famulari.name)
87h7hztqlq.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (4 lines)
> But it has been complicated by the broader context, about which I
> already shared my uncharitable interpretation, and that's a shame. Now
> there is a big discussion about it.

The “broader context” didn’t play a role in my comments, really. :-)

Tony, could you send an updated patch following the suggestions Efraim
and I made?

Thanks,
Ludo’.
L
L
Leo Famulari wrote on 15 Jun 2021 15:40
(name . Ludovic Courtès)(address . ludo@gnu.org)
YMitwaAP7F4T8WpY@jasmine.lan
On Tue, Jun 15, 2021 at 11:38:25AM +0200, Ludovic Courtès wrote:
Toggle quote (10 lines)
> Hi,
>
> Leo Famulari <leo@famulari.name> skribis:
>
> > But it has been complicated by the broader context, about which I
> > already shared my uncharitable interpretation, and that's a shame. Now
> > there is a big discussion about it.
>
> The “broader context” didn’t play a role in my comments, really. :-)

I'm sorry for suggesting it! I think I am too sensitive about these
matters.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 48924@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 48924
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch