guix: switch to 6.1 kernel headers over 5.15 #28786
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6.1 is the current longterm release: https://kernel.org/. Note that using an older version of the kernel headers inside Guix, is not a "hack" for compatibility, and is explicitly recommended against by glibc: https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F. so using the latest version of the longterm headers seems appropriate. The last time we changed this was when we consolidated all builds to 5.15, in bitcoin#25006.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
Is there a way to just use the latest headers or the latest LTS header, so that this is automatically and implicitly done in a time-machine bump? |
|
I can't see anything obvious that would do that. Currently the only non-versioned package in Guix (linux-kernel-headers), is a pinned, older version of the 5.15.x branch. |
This was referenced Nov 3, 2023
Sent a patch upstream, https://lists.gnu.org/archive/html/guix-patches/2023-11/msg00362.html, to see if we can get some unversioned pointers to stable/longterm added. |
Some hashes |
|
Guix builds (aarch64) |
TheCharlatan
approved these changes
Nov 7, 2023
There was a problem hiding this comment.
ACK 380e365
Agree that this should just be done implicitly with a time machine bump.
Yet boost doesn't make the same compatibility guarantees, and needs to be checked. |
No traction on this yet, going to move forward here.
I haven't seen anything that would cause issues, let me know / open an issue if you see otherwise. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
6.1 is the current longterm release: https://kernel.org/.
Note that using an older version of the kernel headers inside Guix, is not a "hack" for compatibility, and is explicitly recommended against by glibc:
https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F.
so using the latest version of the longterm headers seems appropriate.
The last time we changed this was when we consolidated all builds to 5.15, in #25006.