Conversation
github-actions
bot
added
the
6.topic: systemd
There was a problem hiding this comment.
Note: systemd now only supports either gold or bfd as value here. We should test cross compiling.
There was a problem hiding this comment.
This definitely breaks cross-compilation without any target prefix. We might need a wrapper when systemd does support a full name here.
There was a problem hiding this comment.
Since those values are directly passed to binutils, they should not break when cross compiling: https://github.com/systemd/systemd/pull/21264/files#diff-ba74c03f6f96be2712bae81ef72761cea2ec521483d82e64e1eb174809eb84a2R259
ofborg
bot
added
11.by: package-maintainer
There was a problem hiding this comment.
Does someone still care about these?
There was a problem hiding this comment.
If this is about musl support, that was recently introduced.
We should probably highlight @yu-re-ka to take a look if things still apply, but as per #141980 (comment), it shouldn't block this PR.
There was a problem hiding this comment.
Patches no longer apply. :(
For the last major systemd release it looks like it took OpenEmbedded about a week to catch up, so hopefully we won't be waiting too long.
But again, no need to block the PR for Musl.
(Edit: here's the place to watch)
andir
force-pushed
the
systemd-250
branch
3 times, most recently
from
147d0bb to
948d620
Compare
|
Tested. Works for me on my laptop. |
We don't have to do that as we already set all the feature flags to null. Setting individual libraries to null instead of disabling their feature flag will lead with bad example that will cause each of the features to be disabled with multiple flags in the systemdMinimal variant. If a dependency is pulled in via another feature we should disable that rather than setting it to null. Overriding a given package should be the last resort.
This allows us to make test-only dependencies optional in builds that aren't running tests (sadly all of our builds).
You aren't running with systemd-boot, are you? For me this branch killed systemd-boot (it doesn't load anymore). NOTE: nvm somehow my secureboot signing key didn't sign the new bootloader. A bug but somewhere else in the stack :) |
@Mic92 one issue that I ran into: My system time gets reset to Jan 01 1980. I've seen that in random nixos tests but wasn't sure if that was a previous impurity. |
Since systemd commit ce4121c6ff92c1c368874bd451b73fa9b1ddec4a the option is no longer known and we should remove it from our expression.
This has never been a valid option as far as I can tell. I am not sure why we started adding it in the first place.
As of systemd commit add384dd4d2b96db6ace5ad9c52b1dd7553ebec2 that option doesn't have any effect anymore. Systemd defaults to calling its own systemctl instead. As of systemd commit 9a85778412fa3e3f8d4561064131ba69f3259b28 that option was finally removed from the meson_options.txt.
When initializing a system (e.g. first boot / livecd) we have no good reference source for time. systemd-timesyncd however would revert back to its configured fallback time (in our case 01.01.1980). Since we probably don't want to hardcode a specific date as fallback we are now using the current system time (wherever that might have come from) to initialize the reference clock file. The only systems that might be remotely affected by this change are machines that have highly unreliable RTCs or those where the battery that backs the RTC is running empty. Historically these systems always had a tough time with anything time related and likely required manual intervention. For stateless systems (those that wipe / between reboots or our installer CDs) this has the consequence that time will always be reset to whatever the system comes up with on boot. This is likely the correct time coming from an RTC. No harm done here the situation is likely unchanged for them. For stateful systems (those that retain the / partition across reboots) there shouldn't be a change at all. They'll provide an initial clock value once on their lifetime (during first boot / after installation). From then onwards systemd-timesyncd will update the file with the newer fallback time (that will be picked up on the next boot).
github-actions
bot
added
6.topic: nixos
|
I am tracking Meson 0.60 adoption at #153082. New meson complains about invalid options. |
|
Just see that we are building in developer mode, does that incur any implication? |
|
Linking to systemd/systemd#21964, which might cause a regression in some setups. From the linked wireguard ML PSA: |
github-actions
bot
added
8.has: changelog
ofborg
bot
added
the
2.status: merge conflict
|
@andir I suspect you are encountering this: systemd/systemd@12caf72 Might not be an actual error in the bootloader. |
|
An error is displayed during system startup: |
Reproduced locally, but it should not be executed in the first place, per #146497 |
|
I no longer experienced the DNS issues btw with resolved. |
|
While reviewing #153237 Hopefully this is also reproducible in the aesmd test. |
This feels orthogonal. Mind opening a PR for that? |
The |
|
With the 22.05 release, we should probably be seeking to get this in sooner than later. About 3 months / 6 more staging-next cycles until this will be disallowed from being merged until after 22.05 branch-off |
Sorry for the nit, but that's a bit of a strong word for a volunteer effort. I'd have appreciated if this was simply a "We should try to get this in well before the stabilization phase". Also, this should probably not only apply to systemd, but all more scary world-rebuilds with possible fallouts, such as glibc/binutils/coreutils upgrades etc… IMHO, a 3 months blocking/freeze phase is probably a bit too much for a project with a 6 months release cycle. I'm not the author of this PR, but I'm well aware @andir is doing a lot of thorough testing, even runs his own Hydra jobset (on his own Hydra instance). |
|
@andir can you upgrade this to the v250.3 systemd-stable release, and maybe target the staging branch? |
Lol. I'll just stop working in this. Thanks. |
|
I'll close this as I don't intend to continue working on this. I'm only working on Nixpkgs while the freezes aren't in place. Now asking for even tighther schedule or using strong wording like here isn't what I want to waste my time on. |
|
Is there anything else blocking this other than the sgx issue? |
|
@NickCao see above, this needs to be updated to the latest 250.x point release, and tested again. With @andir dropping this effort, there needs to be someone else taking this over, reviewing the upstream change since Running all these VM tests in a jobset is also pretty hefty on compute requirements. |
|
@jonringer if someone is willing to work on this then could you give them access to your server im sure it would be of great help |
It was meant to be a statement of fact: https://nixos.github.io/release-wiki/Release-Process-Walkthrough.html Release managers are volunteers too. I'm just saying that mid-April will be the cutoff point for release critical packages for the 22.05 release. The window will open back up in mid-may for breaking changes to unstable. If changes aren't in a good state to merge, they can always take some more time. But, forcing merges of "scary, ecosystem wide changes" right before a small stabilization window isn't really satisfactory other people's mental health either.
That's not my intended effect. The systemd bump for 20.09 was merged to master right before ZHF, and it cause a lot of issues with DE's, and getting the release in a usable state. If we get this merged in 2 months, then that gives ~4 more weeks of time for edge case failures to be sorted out on unstable. Those weeks really help with release stabilization, especially if fixes need to go through staging cycles.
My server is open to anyone with nixpkgs commit bits. |
I must have had poor wording, theres 3 months UNTIL it freezes. The freeze period is 4 weeks long for release critical packages. For the 22.05 release, this will be from mid-April to mid-May. However, additional time before then is also welcome; as it allows for more issues to be discovered on unstable before ZHF. |
|
If I offended someone, I apologize. Just wanted to avoid a situation where April comes around, and we have to say "No, this is too much risk for stabilization". @andir I really appreciate all the work you have done for nixpkgs. I can take up this PR if you're discouraged from continuing it. |
11 participants
Motivation for this change
Prepare the systemd upgrade to version 250.
Once the final release of systemd v250 has been made & our confidence in our packaging + system configuration is high enough I will rebase thos onto staging with the final version instead of the RC.
I intend to writ proper commit message for all the changes included in this WIP PR once I get to it.
Some of the changes are getting rid of rather old carried-forward bash scripts that patch various paths in the systemd expression. It turned out that a few of those are not required anymore, wouldn't match anything or were not actually catching all the cases. I've written a bit of check code for each of the cases (that we can now declare in Nix rather than Bash code) that ensures that we aren't trying to patch non-existing files or missing a newly introduced (obvious) case. This is in-line with how we deal with the shared libraries mechanism that I introduced some time ago.
As usual I've a jobset on my personal hydra instance for this PR: https://hydra.h4ck.space/jobset/nixpkgs/systemdv250-small (ipv6-only)
Instructions for the binary cache are on the front page of that instance.
The rough steps that still have to be taken are:
Things done