Skip to content
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

linuxHeaders: 5.5 -> 5.9.8 #103575

Merged
merged 1 commit into from Nov 19, 2020
Merged

linuxHeaders: 5.5 -> 5.9.8 #103575

merged 1 commit into from Nov 19, 2020

Conversation

TredwellGit
Copy link
Member

Motivation for this change

https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F

The headers from the most recent Linux kernel should be used. The headers used while compiling the GNU C library and the kernel binary used when using the library do not need to match. The GNU C library runs without problems on kernels that are older than the kernel headers used. The other way round (compiling the GNU C library with old kernel headers and running on a recent kernel) does not necessarily work as expected. For example you can't use new kernel features if you used old kernel headers to compile the GNU C library.

To prevent excessive mass rebuilds linux_latest.meta.branch is used instead of linux_latest.version.

Things done

@TredwellGit
Copy link
Member Author

#86084

@symphorien
Copy link
Member

This will not work, because the version can change without the hash.

@TredwellGit
Copy link
Member Author

I intend for the hash to be updated when linuxPackages_latest is updated. For example, included in #100528 but for 5.10.

@xaverdh
Copy link
Contributor

xaverdh commented Nov 13, 2020

This will not work, because the version can change without the hash.

But it could be made to work by comparing at build time (in an early phase of makeLinuxHeaders) the version of the tarball actually fetched with the one statically known?

This way the build of the headers would fail, if the version attribute and the hash of the sources diverge, so when someone updates the branch of the latest kernel, and forgets to update the hash here, they will hopefully notice, because the build fails.

@TredwellGit
Copy link
Member Author

It already does that and that is the point of using linux_latest.meta.branch instead of just "5.9". For example, if I set linuxPackages_latest = linuxPackages_5_8;:

building '/nix/store/fqpaxff37372b2ink07dmmvwg8qzm41f-linux-5.8.tar.xz.drv'...
hash mismatch in fixed-output derivation '/nix/store/iza414nkp6plgrj4chzhwhhpaikzdjpk-linux-5.8.tar.xz':
  wanted: sha256:01hsddf4sf9q5l1innyyl34b51y48v5wi34qpr421gsh2bpa8f9j
  got:    sha256:1xgibkwb1yfl6qdlbxyagai0qc1pk5ark7giz1512hh6ma353xz7

@xaverdh
Copy link
Contributor

xaverdh commented Nov 13, 2020

Ah fetchurl works differently from fetchFromGitHub and friends then? Looks like the hash depends on the value of url...

@symphorien
Copy link
Member

Please don't rely on hash mismatches. If an update is reverted without reverting the hash, then there will be no error message and the old tarball will be used.

@xaverdh
Copy link
Contributor

xaverdh commented Nov 13, 2020

Please don't rely on hash mismatches. If an update is reverted without reverting the hash, then there will be no error message and the old tarball will be used.

This would be the case with fetchFromGitHub and the likes but I just tested it, and with fetchurl as it stands changing the url appears to trigger a rebuild. Not sure if this should be relied upon though.

@gebner
Copy link
Member

gebner commented Nov 13, 2020

I don't think this change is a good idea: updates to linuxHeaders cause mass-rebuilds and need to go to staging.

If we couple the linuxHeaders version to linux_latest, this means that all linux_latest updates need to go to staging as well. This is bad because we often need to update linux_latest quickly for security patches.

My preference would be to bump linuxHeaders to 5.9 (or even 5.10rc3 if you want). And please keep the fetchurl in linuxHeaders so that it does not depend on linux_latest.

@xaverdh
Copy link
Contributor

xaverdh commented Nov 13, 2020

I don't think this change is a good idea: updates to linuxHeaders cause mass-rebuilds and need to go to staging.

If we couple the linuxHeaders version to linux_latest, this means that all linux_latest updates need to go to staging as well. This is bad because we often need to update linux_latest quickly for security patches.

But do we often need to bump it across major versions? This uses the branch name, not the precise version.

@gebner
Copy link
Member

gebner commented Nov 13, 2020

This uses the branch name, not the precise version.

Ok, that's better. But it still means that the linux_5_10 update will need to go to staging.

@TredwellGit TredwellGit changed the title linuxHeaders: 5.5 -> linux_latest.meta.branch linuxHeaders: 5.5 -> 5.9.8 Nov 13, 2020
@TredwellGit
Copy link
Member Author

The point was to ensure that this package always is updated, but not worth it for delaying updates.

@gebner
Copy link
Member

gebner commented Nov 19, 2020

Sorry, I completely lost track of this PR.

@gebner gebner merged commit 83143c4 into NixOS:staging Nov 19, 2020
@TredwellGit TredwellGit deleted the linuxHeaders branch November 19, 2020 09:11
@TredwellGit TredwellGit mentioned this pull request Dec 15, 2020
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants