systemd: 243.7 -> 245

[flokli]

Motivation for this change

This bumps systemd to its latest stable release.

As explained in #80038, we moved away from a custom systemd fork in the NixOS organization to some NixOS-specific patches inside nixpkgs.

Maintaining custom branches in a fork turned out to be very error-prone. Obsolete patches accidentially got re-introduced, maintaining things in the custom fork required write access to that repo, syncing back and forth with a corresponding nixpkgs PR, and the patches themselves became very unmanage-able as well. For example, some of the patches were partial reverts of earlier patches, not improving in getting the total patch count down ;-)

This PR intentionally isn't squashed together, as it makes it understandable how patches were folded together / became obsolete. I removed the comments originally introduced in 0e66f6b - these comments should still be acted upon in a followup PR.

I ran quite some VM tests, and switched systemd.package on my laptop to 90f9b47 (a version of this against master). So far, this seems to work, and should probably receive some broader testing :-)

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• 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 nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[flokli]

Note that a lot of stuff currently doesn't build on staging - I see gstreamer as a qemu dependency failing on some bash completions… Until this is sorted out, I propose testing this against master.

[andir]

Did some testing in the past days based on these changes. So far no regression that I could find. 👍

[Mic92]

Sorry if I cannot use git anymore for patch management I don't want to maintain this anymore as it is too much work to fix those patches manually.

[flokli]

Sorry if I cannot use git anymore for patch management I don't want to maintain this anymore as it is too much work to fix those patches manually.

The patches are ordered alphabetically.

The idea is that you can still git am /nixpkgs/pkgs/os-specific/systemd/*.patch to import all these patches at once into git, then take care of rebasing, reordering, squashing etc, and replay back via git format-patch. This might produce some renaming noise if the gaps in the patch numbers are closed, but this should be fine.

I didn't do that while folding patches together, as in fact I mostly dropped patches and it made the diffs more readable, and for the bump from 244 to 245, touching the patches at all wasn't required, as the (reduced amount of) patches just applied.

#80038 explains why using patches instead of "magic git revs pushed somewhere" makes things easier".

On top of that, the amount of patches is only going to get down - there's quite some comments about ways to upstream more of these patches on the original wip branch (flokli@90f9b47)

I had some similar discussions with @andir who also didn't really like the patches at first, but I could convince him as long as the "import and export from and to git" stays a simple git am path/to/*.patch. 😃

[worldofpeace]

Note that a lot of stuff currently doesn't build on staging - I see gstreamer as a qemu dependency failing on some bash completions… Until this is sorted out, I propose testing this against master.

Hmm, I should probably look into that. cc @jtojnar wasn't there a bash completions update?

[jtojnar]

Opened few upstream MRs for the bash-completion issue:

• https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1194
• https://gitlab.gnome.org/GNOME/dconf/merge_requests/58
• https://gitlab.freedesktop.org/gstreamer/gstreamer/merge_requests/436
• build: Install bash-completion relative to datadir fwupd/fwupd#2014

[andir]

Here is what I've come up with as things we still have to figure out before merging this:

• networkd does not support networkctl reconfigure, is that sufficient for config changes to networkd? When do we still have to restart it?
• how does the new homed work? Can/Should we disable it when we do not properly use it?

[Mic92]

Sorry if I cannot use git anymore for patch management I don't want to maintain this anymore as it is too much work to fix those patches manually.

The patches are ordered alphabetically.

The idea is that you can still git am /nixpkgs/pkgs/os-specific/systemd/*.patch to import all these patches at once into git, then take care of rebasing, reordering, squashing etc, and replay back via git format-patch. This might produce some renaming noise if the gaps in the patch numbers are closed, but this should be fine.

Fair enough. I feel that I am a bit out of the loop with systemd updates. As we seem to have active group carrying about systemd I will probably step back from this one and focus on other areas.

[flokli]

@andir

• I assume this should have been a "does support" - I wouldn't want to start using networkctl reconfigure just now, but leave that to a future PR
• good point, we might want to disable homed in meson until someone checked if it works and wrote a VM test for it, to ensure it keeps working

@Mic92 fair enough. Take care, and thanks for your work so far :-)

[arianvp]

On a similar note portabled should probably be disabled for now. I can confirm it has not worked in v243 on NixOS

However i'm also open for just keeping them both there; so people can experiment with it and break things with a low barrier :)

[flokli]

I rebased on top of latest staging (hoping staging has been fixed in the meantime).

Bumped to 245.3 and explicitly disabled homed and portabled. Let's re-enable this once we have tests and can ensure it works, instead of shipping halfway broken pieces.

[flokli]

I added some more comments on the commit message and the DESTDIR=/ thingie, to make it more understandable by just looking at the commit messages in nixpkgs.

[Ma27]

First of all thanks a lot for the hard work! I just updated my local systemd to v245 by setting systemd.package to pkgs.systemd from this PR's base branch.

I didn't have any issues when switching to the new configuration, systemd re-execed itself without any problems. Also (re)booting into a NixOS configuration with systemd v245 worked perfectly fine.

I'll keep using this systemd version for at least a few days now to ensure that I don't stumble upon any issues.

---

However I guess I found some kind of regression:

in my sway config I run systemctl --user import-environment and systemctl --user start graphical-session.target after that.

However, the nextcloud-client.service from home-manager (which is triggered by the graphical-session.target that is started from the sway-config) breaks since it's missing needed env-vars like $WAYLAND_DISPLAY.

As an ugly, temporary workaround, I'm now running exec systemctl --user import-environment && sleep 2 before starting the graphical-session.target which appears to fix the issue. Unfortunately this isn't an issue that just happened to occur once, I rebooted several times and the issue was completely reproducible.

Is this explanation sufficient for you or do you need e.g. a VM declaration to reproduce this? :)

[flokli]

I'm currently not using sway, still on X :-)

Reading up on https://wiki.archlinux.org/index.php/Systemd/User#Environment_variables, I'd assume this might be some sort of racyness, nextcloud-client.service starting before the environment was imported. Could it be systemctl --user import-environment forks into the background? Does systemctl --user --wait import-environment work?

I don't really understand why it works in my X setup - network-manager-applet.service starts, so I assume something sets DISPLAY… In my case, it might be the login manager setting this even before invoking the systemd user session…

[Ma27]

Hmm, didn't know about the --wait flag. Will try this out tomorrow, thanks! :)

[Ma27]

So long story short, after posting my last comment I realized that I had to reboot for a kernel update anyway and I decided to try using systemctl --user --wait import-environment which is working perfectly fine now -> big 👍 from my side :)

[arianvp]

All my points were mostly bikesheds. which shouldn't be adressed now. From my point this seems ready to merge

[flokli]

Hmm, didn't know about the --wait flag.

Maybe worth updating the archlinux wiki to include a note like that, if sway with a systemd user session is usually run like this.

[picnoir]

I've been running 245.3 for 3 days on my main system without running into any problems.

LGTM.

[Ma27]

Decided in #nixos-systemd that this is good to go now 👍