New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch default linux package to the new LTS, 4.19 #52863
Conversation
While the upstream commit says 4.18, it builds for 4.19 and 4.20.
@GrahamcOfBorg build linuxPackages_4_4.ena linuxPackages_4_4.ndiswrapper linuxPackages_4_9.ena linuxPackages_4_9.ndiswrapper linuxPackages_4_14.ena linuxPackages_4_14.ndiswrapper linuxPackages_4_19.ena linuxPackages_4_19.ndiswrapper linuxPackages_4_20.ena linuxPackages_4_20.ndiswrapper |
Headers should be bumped too, seems silly to use headers from version older than default kernel used. |
@dtzWill I'm confused, it looks like kernel headers aren't always updated in step; is it something that we need to review so that they're updated with kernel updates? While the default kernel was at 4.14, it got updated, but not for every kernel version in-between. cc @NeQuissimus |
The only downside of headers being older than the kernel is that applications may be configured without support for the latest kernel APIs. Since it takes time for applications to make use of new APIs and this use is made optional to support older kernels the updates to kernel headers are never urgent. |
I'd recommend bumping headers in separate PR, but as it has been said, the common denominator is the app that needs the oldest headers. |
TL; DR: I believe the kernel headers should be kept rather fresh, i.e. 4.19 or 4.20 ATM. IMO reasonable SW does not count on run-time kernel providing all the features that are visible in the headers during build time. (Except for kernel modules, but those surely don't use the common BTW, I've been using 4.19 for months, but I don't really utilize anything special around the kernel. |
Not reproducible for me nor on Hydra. It seemed like timeout due to momentary system overload or something. |
That is weird, I was able to reproduce it with the nixpkgs revision that failed on hydra. I even git-bisected it to this commit. Probably something fixed it since then. Did you try to reproduce it with the revision that failed on hydra? |
EDIT: Hmm, hydra re-writing history is annoying me (if I understand this right).
EDIT2: strike-through the initial sentence, see later comment. |
I can still reproduce the bisection result as follows:
|
Aah, right, this indeed breaks the test, but it breaks all tests.
Thus this commit is broken and not failing; no tests will succeed without the patch introduced in #52942. See also: #48828 (comment) |
Not sure I understand the timeline here -- wasn't #52942 merged before this? And if this wasn't transient, why did the hydra build recover on restart? Anyway, I can confirm that the test passes on current master. |
Because I overlooked something when I initially said "includes the commit you bisected to". I was looking at another commit which I new should work. I was wrong, it does not include So, in order,
Bisecting will always fail in the range between those. b861ebb..de86af4 |
Motivation for this change
An unwritten rule, but as far as I know,
linuxPackages
always points to the most recent LTS by the time the next NixOS release is made. Let's do this, especially since 4.20 is now released.This branch also fixes the two failing modules. As far as building is concerned, nothing is broken currently. As far as testing and using things built with 4.19, I hope that those using
_latest
and_testing
got enough testing done that we won't see any issues for most commonly used packages.An additional motivation is to ensure
sd_image
won't hold back the channel when the latest kernel version is released. This ensures that, at least, the kernel won't be downgraded from the sd image. #52886 makes it use the default kernel and adds a newsd_image_new_kernel
mirroring the existingiso_minimal_new_kernel
. (Here it's not aarch64 at fault, but the fact that there's a moving target into the tested path.)Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)cc @NeQuissimus our kernel wizard
cc @vcunat who was involved in the last
linuxPackages
change.linuxPackages.ena
cc @edolstra, maintainer of it. Looks fine, but it's a major upgrade which I cannot test.