systemd: 251.5 -> 251.7 #199618
systemd: 251.5 -> 251.7 #199618
Conversation
systemd 251.6 added support for libbpf 1.0.0, so use new libbpf version.
|
I'd prefer 252, but depending on the work required, 251 is also fine. |
happy to give that a try. I've just rebased patches and currently building to check but ofborg will probably beat my slow computer to it. I've kept it as a separate commit to revert if required, happy to squash once this passes reviews. Note I didn't look at musl patches -- this most definitely breaks pkgsMusl.systemd. I can eventually take a look at it if required but upstream openembedded-core does not have patches for systemd >251.4 yet so I'm not sure how you usually proceed with it -- is it ok to break? |
|
I remember musl support breaking multiple times in the history and there was little complaint, but would be happy to see it thrive. FYI, we are currently in the process of releasing 22.11 thus breaking changes (major version bump is certainly one) to systemd (as a release critical package) are restricted until at least 11/14, in other words: we still have plenty of time to get it right. Regarding the lengthy builds, you may ask for a hydra jobset dedicated to this pr from whoever have the privilege to do so. |
Sorry for the double work, but 252 is something that'd need to wait a bit until the 22.11 branch-off has happened. 251.x is just a new point release, and something that should be easier to land. I'd propose dropping the 252 bump from this PR, and leaving it for a later one. |
|
hah! Thanks for the info, I've dropped the 252 patch again (it's still accessible in https://github.com/martinetd/nixpkgs/commits/systemd_252 for later/if required) Regarding build time, it's just my computer, I don't think this is too bad. I ran some nixosTests.systemd* with 251.7 and didn't run in any troubles, but let's let ofborg check again. |
|
I'll run some tests on my side as well. |
|
I ran the following tests:
|
|
Thanks! |
In systemd < 252 there is a regression that makes expired timers not run after resume from suspend: Fixed with a revert: |
|
OTOH, there was a v251.8 tagged a couple of days ago that contains other fixes we might want, I guess we can upgrade at some point... |
Yes please :-) can you open a PR against staging? |
|
I just opened #200745, will test. |
Version 251.6 of systemd introduced a small change[1] that now checks whether the fsck command is available in *addition* to the filesystem specific fsck.$fsname executable. When bumping systemd to version 251.7 on our side[2], we introduced that change. This subsequently caused our "fsck" test to fail and it looks like this was an oversight during the pull request[3] introducing the bump. Since the fsck wrapper binary is in util-linux, I decided to address this by adding util-linux to fsPackages because util-linux is already part of the closure of any NixOS system so the impact should be pretty low. [1]: systemd/systemd-stable@73db7d9 [2]: 844a08c [3]: #199618 Signed-off-by: aszlig <aszlig@nix.build>
Version 251.6 of systemd introduced a small change[1] that now checks whether the fsck command is available in *addition* to the filesystem specific fsck.$fsname executable. When bumping systemd to version 251.7 on our side[2], we introduced that change. This subsequently caused our "fsck" test to fail and it looks like this was an oversight during the pull request[3] introducing the bump. Since the fsck wrapper binary is in util-linux, I decided to address this by adding util-linux to fsPackages because util-linux is already part of the closure of any NixOS system so the impact should be pretty low. [1]: systemd/systemd-stable@73db7d9 [2]: NixOS@844a08c [3]: NixOS#199618 Signed-off-by: aszlig <aszlig@nix.build>
Version 251.6 of systemd introduced a small change[1] that now checks whether the fsck command is available in *addition* to the filesystem specific fsck.$fsname executable. When bumping systemd to version 251.7 on our side[2], we introduced that change. This subsequently caused our "fsck" test to fail and it looks like this was an oversight during the pull request[3] introducing the bump. Since the fsck wrapper binary is in util-linux, I decided to address this by adding util-linux to fsPackages because util-linux is already part of the closure of any NixOS system so the impact should be pretty low. [1]: systemd/systemd-stable@73db7d9 [2]: NixOS@844a08c [3]: NixOS#199618 Signed-off-by: aszlig <aszlig@nix.build>
Description of changes
systemd 251.6 added support for libbpf 1.0.0, so use new libbpf version.
(Note there's also systemd 252 that got released recently, not sure which version we want)I intend to change the default version of libbpf after this and the bcc/bpftrace update get merged in master; there's no real hurry.
I'm never sure if I should target staging or master, systemd is a core component so staging is probably better? happy to retarget if appropriate.Things done