[WIP] systemd: patch to build on musl

[dtzWill]

Patches largely from OE which just updated to 237,
few needed rebasing but nothing major.

NixOS uses systemd, and until now using musl
meant many things were not possible.

There are some org issues (I think?) to tackle
before it's possible to instantiate an NixOS config
using a custom localSystem parameter (aka using musl)
so I've yet to really test this in "action"
yet (container, VM).

Even so, this is a giant step for musl support!

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

I was unsure how to best apply all of the patches-- you can see
previous approaches in commit history for things like:

• Last time (pre-237): dtzWill@143796f
• Earlier today: https://github.com/dtzWill/nixpkgs/releases/tag/systemd-musl-237-1

To keep this less crazy-looking I've instead combined the patches
(well, github combines them for us) which we fetch and apply as a single
"musl support patch".

Note that patch is actually against v238-stable, not our fork,
to keep it orthogonal to our NixOS changes.

[dtzWill]

cc NixOS/rfcs#23 .

This targets staging since that's where the latest systemd is (v238), not because it introduces any breakage (to supported platforms or otherwise).

[GrahamcOfBorg]

No attempt on x86_64-darwin (full log)

The following builds were skipped because they don't evaluate on x86_64-darwin: systemd

Partial log (click to expand)

Cannot nix-instantiate `systemd' because:
�[31;1merror:�[0m while evaluating 'callPackageWith' at �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/lib/customisation.nix�[0m:113:35, called from �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/top-level/all-packages.nix�[0m:13859:13:
while evaluating 'makeOverridable' at �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/lib/customisation.nix�[0m:72:24, called from �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/lib/customisation.nix�[0m:117:8:
while evaluating anonymous function at �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/os-specific/linux/systemd/default.nix�[0m:1:1, called from �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/lib/customisation.nix�[0m:74:12:
assertion failed at �[1m/private/var/lib/ofborg/builds/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/os-specific/linux/systemd/default.nix�[0m:15:1

[GrahamcOfBorg]

Failure on x86_64-linux (full log)

Attempted: systemd

Partial log (click to expand)

cannot build derivation '/nix/store/dnzw1xc38f5x4qg3lafrwh25d7xygmx5-python3-3.6.4-env.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/s32ck1b0zhvlgyfyhzgpsrkpii9y06fj-ronn-gems.drv': 10 dependencies couldn't be built
cannot build derivation '/nix/store/xvnm2k2j21axqy48byviyfqwdc61d7g7-shadow-4.5.drv': 11 dependencies couldn't be built
cannot build derivation '/nix/store/6yp923mfsv2ci81bw5v6ky8alqxy9cap-gnu-efi-3.0.8.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/s5k96ax3gsfg2bm9kmfgynvchqj4cigj-ronn-0.7.3.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/ka686my2bcjd0c2c6n5sq8mgv9vsvwbg-util-linux-2.31.1.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/ghgzsrkay4p5byzgnli5v38k00ncr7qa-glib-2.56.0.drv': 11 dependencies couldn't be built
cannot build derivation '/nix/store/sysalv51awcz8kwqcnsnmb9530gv98lb-libidn2-2.0.4.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/m0l7mi8ihap8kyxcp3rfrgbz3plzacbd-systemd-238.drv': 40 dependencies couldn't be built
error: build of '/nix/store/m0l7mi8ihap8kyxcp3rfrgbz3plzacbd-systemd-238.drv' failed

[GrahamcOfBorg]

Failure on aarch64-linux (full log)

Attempted: systemd

Partial log (click to expand)

[498/1461] Compiling C object 'systemd-resolved@exe/src_resolve_resolved-link-bus.c.o'.
[499/1461] Compiling C object 'systemd-resolved@exe/src_resolve_resolved-bus.c.o'.
[500/1461] Compiling C object 'src/basic/basic@sta/strv.c.o'.
[501/1461] Compiling C object 'systemd-fstab-generator@exe/src_fstab-generator_fstab-generator.c.o'.
[502/1461] Compiling C object 'src/core/core@sta/swap.c.o'.
[503/1461] Compiling C object 'systemd-resolved@exe/src_resolve_resolved-dns-transaction.c.o'.
[504/1461] Compiling C object 'src/libsystemd/systemd@sta/sd-bus_bus-message.c.o'.
ninja: build stopped: subcommand failed.
builder for '/nix/store/f123aq93kbd547i6l7i85imkayqd4gj3-systemd-238.drv' failed with exit code 1
�[31;1merror:�[0m build of '/nix/store/f123aq93kbd547i6l7i85imkayqd4gj3-systemd-238.drv' failed

[saschagrunert]

@dtzWill May I ask you if we have any update on this? I would love to see it in.

[offlinehacker]

Any updates on this?

[arianvp]

there are some parts in musl lacking that we really need in order to make it work on NixOS as far as I know.

Most importantly; the ability to dispatch calls to nscd so that you can use nss modules. Systemd ecosystem relies heavily on nss and I don't see that working on NixOS + musl any time soon..

Systemd is heavily dependend on glibc semantics and upstream doesn't seem very warm in supporting adaptations to work around musl bugs systemd/systemd#10130

Given the systemd maintainer team on NixOS is already pretty spread thin and we can not piggyback on upstream helping with this either, I do not think we can do a good job at maintaining an alternative libc in a bug-free manner. We already have enough glibc/nscd bugs to manage today.

We have recently been trying really hard to reduce the custom amount of patches that we carry to below 10 and preferably to 0; so that we can keep up with systemd-stable better and ship updates to our users quicker. This PR introduces another 53 patches which we would have to maintain which I don't have any interest in myself.

I'm not opposed to merging this under some alternative package name; but I will not be putting time in maintaining this myself.

[Mic92]

Maybe there could be a libsystemd/libudev alternative so that more musl packages can be built at least.

[arianvp]

Hmm... and I suppose those build targets should also be easier to build than the entirety of systemd no?

I think udev currently is just an alias for the systemd package; but could just build that specific meson target instead...

[arianvp]

@Mic92 both libudev and libsystemd can be built statically I recently discovered. So they'll probably (hopefully) also be more friendly to build with musl?

[jorsn]

Maybe there could be a libsystemd/libudev alternative so that more musl packages can be built at least. – @Mic92

For packages only using libudev and not libsystemd, there is eudev (project page), the Gentoo fork of udev which is already in nixpkgs. Maybe it can be used as a drop-in for systemd-udev. The Gentoo wiki (almost?) suggests this (https://wiki.gentoo.org/wiki/Eudev#Migrating_from_udev_to_eudev), but it is unclear whether it's outdated.

From the above linked project page:

In specific it tries to avoid glibc-specific functions and gcc-specific constructs by sticking to C99 while tracking closely the systemd-udev developments.

@arianvp you said

@Mic92 both libudev and libsystemd can be built statically I recently discovered. So they'll probably (hopefully) also be more friendly to build with musl?

Can they be built statically with musl or only glibc?

[Mic92]

Maybe there could be a libsystemd/libudev alternative so that more musl packages can be built at least. – @Mic92

For packages only using libudev and not libsystemd, there is eudev (project page), the Gentoo fork of udev which is already in nixpkgs. Maybe it can be used as a drop-in for systemd-udev. The Gentoo wiki (almost?) suggests this (wiki.gentoo.org/wiki/Eudev#Migrating_from_udev_to_eudev), but it is unclear whether it's outdated.

From the above linked project page:

In specific it tries to avoid glibc-specific functions and gcc-specific constructs by sticking to C99 while tracking closely the systemd-udev developments.

@arianvp you said

@Mic92 both libudev and libsystemd can be built statically I recently discovered. So they'll probably (hopefully) also be more friendly to build with musl?

Can they be built statically with musl or only glibc?

It might be worth to set libudev = eudev on in nixpkgs for musl than.

[domenkozar]

Closing as systemd has evolved in last 2 years.