Add systemd

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

Hi Tony!

Tony O <me@fron.io> skribis:

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

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:

Hello,

Tony O <me@fron.io> skribis:

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

Sure, it’s a good idea in general!

So what’s your use case?

Specifically, what’s the answer to this question:

By knowing the answer and understanding potential use cases, we can make

more informed decisions.

TIA,

Ludo’.

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:

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:

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.

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.

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

Hi,

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

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

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

Hi,

Am Freitag, den 11.06.2021, 18:39 +0200 schrieb Ludovic Courtès:

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

On Fri, Jun 11, 2021 at 07:11:18PM +0200, Leo Prikler wrote:

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

Hi!

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

[...]

[...]

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.

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.

Good question, no idea.

Thanks,

Ludo’.

On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:

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)

--

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

On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:

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.

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

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:

Am Sonntag, den 13.06.2021, 18:54 +0000 schrieb Tony O:

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.

\-------- 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:

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.

Am Sonntag, den 13.06.2021, 19:56 +0000 schrieb Tony O:

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

On Sun, Jun 13, 2021 at 11:44:47PM +0200, Leo Prikler wrote:

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.

Hi,

Leo Famulari <leo@famulari.name> skribis:

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

On Mon, Jun 14, 2021 at 02:30:10PM +0200, Ludovic Courtès wrote:

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.

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.

On Mon, Jun 14, 2021 at 02:30:10PM +0200, Ludovic Courtès wrote:

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

Hi,

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

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

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

Hi,

Leo Famulari <leo@famulari.name> skribis:

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

On Tue, Jun 15, 2021 at 11:38:25AM +0200, Ludovic Courtès wrote:

I'm sorry for suggesting it! I think I am too sensitive about these

matters.