[bug#48924] Add systemd

[bug#48924] Add systemd

[Tony O]

[-- Attachment #1.1.1: Type: text/plain, Size: 200 bytes --]

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 #1.1.2.1: Type: text/html, Size: 517 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-Add-systemd.patch --]
[-- Type: text/x-patch; filename="0001-gnu-Add-systemd.patch"; name="0001-gnu-Add-systemd.patch", Size: 14703 bytes --]

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(+)

diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index e4ea951c41..03db4deee8 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -24,6 +24,7 @@
 ;;; Copyright © 2020 Raghav Gururajan <raghavgururajan@disroot.org>
 ;;; Copyright © 2021 Brendan Tildesley <mail@brendan.scot>
 ;;; Copyright © 2021 pineapples <guixuser6392@protonmail.com>
+;;; Copyright © 2021 bqv <guix@fron.io>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -55,6 +56,7 @@
   #:use-module (gnu packages)
   #:use-module (gnu packages acl)
   #:use-module (gnu packages admin)
+  #:use-module (gnu packages aidc)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bash)
@@ -63,10 +65,12 @@
   #:use-module (gnu packages cmake)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages cryptsetup)
+  #:use-module (gnu packages curl)
   #:use-module (gnu packages databases)
   #:use-module (gnu packages disk)
   #:use-module (gnu packages docbook)
   #:use-module (gnu packages documentation)
+  #:use-module (gnu packages elf)
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages gawk)
   #:use-module (gnu packages gettext)
@@ -74,6 +78,8 @@
   #:use-module (gnu packages gl)
   #:use-module (gnu packages glib)                ;intltool
   #:use-module (gnu packages gnome)
+  #:use-module (gnu packages gnunet)
+  #:use-module (gnu packages gnupg)
   #:use-module (gnu packages gperf)
   #:use-module (gnu packages graphviz)
   #:use-module (gnu packages gstreamer)
@@ -81,6 +87,7 @@
   #:use-module (gnu packages image)
   #:use-module (gnu packages language)
   #:use-module (gnu packages libffi)
+  #:use-module (gnu packages libidn)
   #:use-module (gnu packages libunwind)
   #:use-module (gnu packages libusb)
   #:use-module (gnu packages linux)
@@ -89,6 +96,7 @@
   #:use-module (gnu packages networking)
   #:use-module (gnu packages nss)
   #:use-module (gnu packages package-management)
+  #:use-module (gnu packages pcre)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages perl-check)
   #:use-module (gnu packages pkg-config)
@@ -98,6 +106,7 @@
   #:use-module (gnu packages python-xyz)
   #:use-module (gnu packages samba)
   #:use-module (gnu packages sqlite)
+  #:use-module (gnu packages tls)
   #:use-module (gnu packages valgrind)
   #:use-module (gnu packages video)
   #:use-module (gnu packages w3m)
@@ -2266,6 +2275,219 @@ fallback to generic Systray support if none of those are available.")
        "libportal provides GIO-style async APIs for most Flatpak portals.")
       (license license:lgpl2.1+))))
 
+(define-public systemd
+  (package
+    (name "systemd")
+    (version "247")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://github.com/systemd/systemd/archive/v"
+                                  version ".tar.gz"))
+              (file-name (string-append name "-" version ".tar.gz"))
+              (sha256
+               (base32
+                 "0h66cq7ymm419cjyg0gla18ni4y8qf9fsav9ysgacjik4xxny53p"))))
+    (build-system meson-build-system)
+    (arguments
+     `(#:tests? #f             ;FIXME: The disable-broken-tests phase is ineffective.
+       #:configure-flags
+       (let ((bash            (assoc-ref %build-inputs "bash"))
+             (coreutils       (assoc-ref %build-inputs "coreutils"))
+             (kbd             (assoc-ref %build-inputs "kbd"))
+             (kmod            (assoc-ref %build-inputs "kmod"))
+             (util-linux      (assoc-ref %build-inputs "util-linux"))
+
+             (out (assoc-ref %outputs "out")))
+         (list (string-append "-Dkill-path=" coreutils "/bin/kill")
+               (string-append "-Dkmod-path=" kmod "/bin/kmod")
+               (string-append "-Dsulogin-path=" util-linux "/bin/sulogin")
+               (string-append "-Dmount-path=" util-linux "/bin/mount")
+               (string-append "-Dumount-path=" util-linux "/bin/umount")
+               (string-append "-Dloadkeys-path=" kbd "/bin/loadkeys")
+               (string-append "-Dsetfont-path=" kbd "/bin/setfont")
+               (string-append "-Ddebug-shell=" bash "/bin/sh")
+
+               ;; XXX: Can we reuse %ntp-servers here?
+               (string-append "-Dntp-servers="
+                              (string-join (map (lambda (n)
+                                                  (string-append (number->string n)
+                                                                 ".guix.pool.ntp.org"))
+                                                '(0 1 2 3))
+                                           ","))
+
+               ;; Use localhost for DNS with fallback to Quad9 (instead of Google).
+               "-Ddns-servers=127.0.0.1,::1,9.9.9.10,2620:fe::10"
+
+               ;; FIXME: "Attempt to load external entity http://docbook.sf.net".
+               "-Dman=false"
+
+               ;; Don't install SysV compatibility scripts.
+               "-Dsysvinit-path="
+               "-Dsysvrcnd-path="
+
+               (string-append "-Dbashcompletiondir=" out "/etc/bash_completion.d")
+               (string-append "-Dsysconfdir=" out "/etc")
+               (string-append "-Drootprefix=" out)
+               (string-append "-Drootlibdir=" out "/lib")
+               (string-append "-Ddbuspolicydir=" out "/etc/dbus-1/system.d")
+               (string-append "-Dpamconfdir=" out "/etc/pam.d")))
+       #:phases (modify-phases %standard-phases
+                  (add-after 'unpack 'patch-paths
+                    (lambda* (#:key inputs outputs #:allow-other-keys)
+                      (let ((bash            (assoc-ref inputs "bash"))
+                            (coreutils       (assoc-ref inputs "coreutils"))
+                            (glibc           (assoc-ref inputs "glibc"))
+                            (util-linux      (assoc-ref inputs "util-linux"))
+
+                            (out (assoc-ref outputs "out")))
+
+                        (substitute* '("src/core/swap.c"
+                                       "src/fsck/fsck.c"
+                                       "src/journal/cat.c"
+                                       "src/nspawn/nspawn.c"
+                                       "src/nspawn/nspawn-setuid.c")
+                          (("/bin/sh") (string-append bash "/bin/sh"))
+                          (("/bin/bash") (string-append bash "/bin/bash"))
+                          (("/bin/cat") (string-append coreutils "/bin/cat"))
+                          (("/bin/echo") (string-append coreutils "/bin/echo"))
+                          (("/bin/getent") (string-append glibc "/bin/getent"))
+                          (("/sbin/fsck") (string-append util-linux "/sbin/fsck"))
+                          (("/sbin/swapon") (string-append util-linux "/sbin/swapon"))
+                          (("/sbin/swapoff") (string-append util-linux "/sbin/swapoff")))
+                        (substitute* "src/journal/catalog.c"
+                          (("/usr/lib/systemd/catalog")
+                           (string-append out "/lib/systemd/catalog")))
+                        #t)))
+                  (add-after 'patch-paths 'fix-install
+                    (lambda* (#:key outputs #:allow-other-keys)
+                      (let ((out (assoc-ref outputs "out")))
+                        ;; Don't create /var/lib/systemd during install.
+                        (substitute* "meson.build"
+                          ((".*mkdir_p\\.format\\(systemdstatedir\\)\\)") ""))
+                        ;; Nor /var/lib/systemd/catalog.
+                        (substitute* "catalog/meson.build"
+                          (("journalctl --update-catalog") "journalctl --version"))
+                        ;; Likewise for /var/log/journal.
+                        (substitute* '("src/journal/meson.build"
+                                       "src/journal-remote/meson.build")
+                          (("/var/log/journal") "/tmp/journal"))
+                        ;; Create the hwdb in out/etc/udev/hwdb.d, not /etc/udev.
+                        (substitute* "hwdb.d/meson.build"
+                          (("systemd-hwdb update")
+                           (string-append "systemd-hwdb -r " out
+                                          "/etc/udev/hwdb.d update")))
+                        #t)))
+                  (add-before 'configure 'set-runpath
+                    (lambda* (#:key outputs #:allow-other-keys)
+                      (let ((out (assoc-ref outputs "out")))
+                        ;; We need out/lib and out/lib/systemd in RUNPATH.
+                        (setenv "LDFLAGS" (string-append "-Wl,-rpath=" out "/lib,"
+                                                         "-rpath=" out "/lib/systemd"))
+                        #t)))
+                  (add-before 'check 'disable-broken-tests
+                    (lambda _
+                      (delete-file "test-network")           ;requires loopback
+                      (delete-file "test-engine")            ;requires cgroups
+                      (delete-file "test-unit-name")         ;likewise
+                      (delete-file "test-unit-file")         ;likewise
+                      (delete-file "test-copy")              ;FIXME
+                      (delete-file "test-condition")         ;requires containers
+                      (delete-file "test-mount-util")        ;requires /sys
+                      (delete-file "test-exec-util")         ;FIXME
+                      (delete-file "test-xattr-util")        ;FIXME
+                      (delete-file "test-fs-util")           ;requires /var/tmp
+                      (delete-file "test-stat-util")         ;FIXME
+                      (delete-file "test-user-util")         ;needs "root" user
+                      (delete-file "test-path-lookup")       ;expects systemd paths
+                      (delete-file "test-namespace")         ;requires containers
+                     ;(delete-file "test-bpf")               ;requires cgroups
+                      (delete-file "test-fileio")            ;FIXME
+                      (delete-file "test-time-util")         ;FIXME tzdata
+                      (delete-file "test-date")              ;likewise
+                      (delete-file "test-calendarspec")      ;likewise
+                      (delete-file "test-cgroup-util")       ;requires cgroup (duh)
+                      (delete-file "test-strv")              ;FIXME
+                      (delete-file "test-path-util")         ;FIXME /bin/sh
+                      (delete-file "test-path")              ;requires cgroup
+                      (delete-file "test-sched-prio")        ;requires cgroup
+                      (delete-file "test-id128")             ;FIXME
+                      (delete-file "test-journal-flush")     ;FIXME
+                      (delete-file "test-bus-creds")         ;requires cgroup
+                      (delete-file "test-login")             ;FIXME
+                      (delete-file "test-dhcp-client")       ;requires network
+                      (delete-file "test-dhcp6-client")      ;likewise
+                      #t))
+                  (add-before 'install 'fix-install
+                    (lambda _
+                      (setenv "DESTDIR" "/")
+                      #t))
+                  (add-after 'install 'fix-environment-symlink
+                    (lambda* (#:key outputs #:allow-other-keys)
+                      ;; The install phase creates this dangling symlink:
+                      ;; lib/environment.d/00-environment.conf -> ../../etc/environment
+                      ;; ...which causes the 'fix-runpath' phase to error out.
+                      ;; XXX: This should probably use /etc/environment instead.
+                      (mkdir-p (string-append (assoc-ref outputs "out")
+                                              "/etc/environment"))
+                      #t))
+                  (add-before 'strip 'add-shared-lib
+                    (lambda* (#:key outputs #:allow-other-keys)
+                      (link (string-append (assoc-ref outputs "out")
+                                           "/lib/systemd/libsystemd-shared-247.so")
+                            (string-append (assoc-ref outputs "out")
+                                           "/lib/libsystemd-shared-247.so"))
+                      #t)))))
+    (native-inputs
+     `(("docbook-xml" ,docbook-xml)
+       ("docbook-xsl" ,docbook-xsl)
+       ("gettext" ,gettext-minimal)
+       ("gperf" ,gperf)
+       ("lxml" ,python-lxml)
+       ("m4" ,m4)
+       ("pkg-config" ,pkg-config)
+       ("xsltproc" ,libxslt)))
+    (inputs
+     `(("acl" ,acl)
+       ("audit" ,audit)
+       ("bash" ,bash)
+       ("bzip2" ,bzip2)
+       ("coreutils" ,coreutils)
+       ("cryptsetup" ,cryptsetup)
+       ("curl" ,curl)
+       ("dbus" ,dbus)
+       ;; TODO: Add gnu-efi for bootloader functionality.
+       ("elfutils" ,elfutils)
+       ("glib" ,glib)
+       ("glibc" ,glibc)
+       ("gnutls" ,gnutls)
+       ("kbd" ,kbd)
+       ("kmod" ,kmod)
+       ("libcap" ,libcap)
+       ("libgcrypt" ,libgcrypt)
+       ("libidn2" ,libidn2)
+       ("libmicrohttpd" ,libmicrohttpd)
+       ("libseccomp" ,libseccomp)
+       ("libxkbcommon" ,libxkbcommon)
+       ("linux-pam" ,linux-pam)
+       ("lz4" ,lz4)
+       ("pcre2" ,pcre2)
+       ("python" ,python)
+       ("qrencode" ,qrencode)
+       ("util-linux" ,util-linux)
+       ("xz" ,xz)
+       ("zlib" ,zlib)))
+    (home-page "https://www.freedesktop.org/wiki/Software/systemd/")
+    (synopsis "System and service manager")
+    (description
+     "@code{systemd} is a suite of basic building blocks for a Linux system.
+It provides a system and service manager that runs as PID 1 and starts the
+rest of the system.  systemd provides aggressive parallelization capabilities,
+uses socket and D-Bus activation for starting services, offers on-demand
+starting of daemons, keeps track of processes using Linux control groups,
+maintains mount and automount points, and implements an elaborate transactional
+dependency-based service control logic.")
+    (license license:lgpl2.1+)))
+
 (define-public xdg-desktop-portal
   (package
     (name "xdg-desktop-portal")
-- 
2.32.0


[-- Attachment #1.3: publickey - me@fron.io - 0x3026807C.asc --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

[bug#48924] Add systemd

[Ludovic Courtès]

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

[bug#48924] Add systemd

[Tony O]

[-- Attachment #1.1.1: Type: text/plain, Size: 1649 bytes --]

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:

>
>
>
> 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 #1.1.2.1: Type: text/html, Size: 1974 bytes --]

[-- Attachment #1.2: publickey - EmailAddress(s=me@fron.io) - 0x3026807C.asc --]
[-- Type: application/pgp-keys, Size: 616 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

[bug#48924] Add systemd

[Ludovic Courtès]

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

[bug#48924] Add systemd

[Tony O]

[-- Attachment #1.1.1: Type: text/plain, Size: 1573 bytes --]

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,
>
> 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 #1.1.2.1: Type: text/html, Size: 1847 bytes --]

[-- Attachment #1.2: publickey - EmailAddress(s=me@fron.io) - 0x3026807C.asc --]
[-- Type: application/pgp-keys, Size: 616 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

[bug#48924] Add systemd

[Leo Prikler]

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

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

> 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

[bug#48924] Add systemd

[Ludovic Courtès]

Hi,

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

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

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

[bug#48924] Add systemd

[Leo Prikler]

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

[bug#48924] Add systemd

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]

On Fri, Jun 11, 2021 at 07:11:18PM +0200, Leo Prikler wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#48924] Add systemd

[Ludovic Courtès]

Hi!

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

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

[...]

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

[...]

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

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

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

[bug#48924] Add systemd

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

On Sun, Jun 13, 2021 at 11:36:14AM +0200, Ludovic Courtès wrote:
> 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)

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#48924] Add systemd

[Leo Famulari]

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

[bug#48924] Add systemd

[Tony O]

[-- Attachment #1.1.1: Type: text/plain, Size: 2958 bytes --]

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:

>
>
>
> 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 #1.1.2.1: Type: text/html, Size: 3218 bytes --]

[-- Attachment #1.2: publickey - EmailAddress(s=me@fron.io) - 0x3026807C.asc --]
[-- Type: application/pgp-keys, Size: 616 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

[bug#48924] Add systemd

[Leo Prikler]

Am Sonntag, den 13.06.2021, 18:54 +0000 schrieb Tony O:
> 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.
> -------- 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
> > 

[bug#48924] Add systemd

[Tony O]

[-- Attachment #1.1.1: Type: text/plain, Size: 1331 bytes --]



\-------- 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:
> 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 #1.1.2.1: Type: text/html, Size: 1384 bytes --]

[-- Attachment #1.2: publickey - EmailAddress(s=me@fron.io) - 0x3026807C.asc --]
[-- Type: application/pgp-keys, Size: 616 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

[bug#48924] Add systemd

[Leo Prikler]

Am Sonntag, den 13.06.2021, 19:56 +0000 schrieb Tony O:
> 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

[bug#48924] Add systemd

[Leo Famulari]

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.

[bug#48924] Add systemd

[Ludovic Courtès]

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

[bug#48924] Add systemd

[Leo Famulari]

On Mon, Jun 14, 2021 at 02:30:10PM +0200, Ludovic Courtès wrote:
> 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.

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

[bug#48924] Add systemd

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

On Mon, Jun 14, 2021 at 02:30:10PM +0200, Ludovic Courtès wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#48924] Add systemd

[Ludovic Courtès]

Hi,

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

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

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

[bug#48924] Add systemd

[Ludovic Courtès]

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

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

Thanks,
Ludo’.

[bug#48924] Add systemd

[Leo Famulari]

On Tue, Jun 15, 2021 at 11:38:25AM +0200, Ludovic Courtès wrote:
> 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.