guix: Pin kernel-header version, time-machine to upstream 1.3.0 commit #22465
Conversation
- Use 4.19 for riscv64 (earliest LTS release w/ riscv64 support) - Use 4.9 for all others (second-oldest LTS release, released in combination with glibc glibc 2.24 in Debian stretch)
The chosen commit is the HEAD of Guix's version-1.3.0 branch as of July 15th, 2021. Also fix visual indenting.
dongcarl
force-pushed
the
2021-07-guix-kernel-old
branch
from
4350a43 to
e6a94d4
Compare
|
Concept ACK - moving back to vanilla / upstream Guix is good. I take that all of your patches have now made it back to upstream? |
Yes, the outstanding ones in 490e39f have made it upstream as of version-1.3.0. Note that there are also a few other changes that made it in after version-1.3.0 that would remove some of our custom patching in |
|
Guix builds (x86_64): 9dce51ed2539581adf2b14c66f5945827b3b0b78760f5f8e74c45e86ca231aec guix-build-e6a94d44469f/output/aarch64-linux-gnu/SHA256SUMS.part
f7048fd647c75fdf0dfbaa1929627d66cad904e4e4d756f621e1479b6bf68030 guix-build-e6a94d44469f/output/aarch64-linux-gnu/bitcoin-e6a94d44469f-aarch64-linux-gnu-debug.tar.gz
ab72c7d0d457bfb0a87a7dd434049c98c16b0e1be4b31bdf116c6a56140e6bcc guix-build-e6a94d44469f/output/aarch64-linux-gnu/bitcoin-e6a94d44469f-aarch64-linux-gnu.tar.gz
f0e9ee9c3918814f519f53270486961d9b39f5c7bea0b26f25a305cfa86e1c24 guix-build-e6a94d44469f/output/arm-linux-gnueabihf/SHA256SUMS.part
9b252c04c9d8f877ac71a5594bf35356a114ac2f46b405ff6bc8c8e8ccd48ce1 guix-build-e6a94d44469f/output/arm-linux-gnueabihf/bitcoin-e6a94d44469f-arm-linux-gnueabihf-debug.tar.gz
b3dce015e8782f58abf205fa144f22bf4f65b83724b530ab66af02f75029bede guix-build-e6a94d44469f/output/arm-linux-gnueabihf/bitcoin-e6a94d44469f-arm-linux-gnueabihf.tar.gz
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 guix-build-e6a94d44469f/output/dist-archive/SKIPATTEST.TAG
d5d334a5954d43eba87799efe55098009717af5a835c1ff9744c3277463ca016 guix-build-e6a94d44469f/output/dist-archive/bitcoin-e6a94d44469f.tar.gz
30595847afdd72ac5e536676dbb20dbb2ce1798e79f89b1488919514eeb4a8b4 guix-build-e6a94d44469f/output/powerpc64-linux-gnu/SHA256SUMS.part
60bffc9b3b3f4510d1914510e06601064d85d7d16cb7a3f5b1bc568184ecb42c guix-build-e6a94d44469f/output/powerpc64-linux-gnu/bitcoin-e6a94d44469f-powerpc64-linux-gnu-debug.tar.gz
613fdafe98a28e8a9c5edd502f2d7248942f7d5ec21a81a5ddfe38915b66e1ae guix-build-e6a94d44469f/output/powerpc64-linux-gnu/bitcoin-e6a94d44469f-powerpc64-linux-gnu.tar.gz
c4ddf6060aec6afaa6a525b8a12879331096da77abf946250ee1ab662148e9f9 guix-build-e6a94d44469f/output/powerpc64le-linux-gnu/SHA256SUMS.part
969edc3927653f5f36578e40e2701dd64f015fbca58a51169415e98473aa1bba guix-build-e6a94d44469f/output/powerpc64le-linux-gnu/bitcoin-e6a94d44469f-powerpc64le-linux-gnu-debug.tar.gz
bf5684eee37f042886949342a63c54d75682704b104812c12742de43cef7f368 guix-build-e6a94d44469f/output/powerpc64le-linux-gnu/bitcoin-e6a94d44469f-powerpc64le-linux-gnu.tar.gz
5853c08d84c220f1f5190e8660c2d2b9c2dac34c4031e51854147727b755a980 guix-build-e6a94d44469f/output/riscv64-linux-gnu/SHA256SUMS.part
8841c324a89381e0b49172ce54fc0a03e8d2c3164bec967feb5a2d36696c2163 guix-build-e6a94d44469f/output/riscv64-linux-gnu/bitcoin-e6a94d44469f-riscv64-linux-gnu-debug.tar.gz
09c3e0497f782598d09975c42a12c8f87328c18661bf932f53d388d81ef206f3 guix-build-e6a94d44469f/output/riscv64-linux-gnu/bitcoin-e6a94d44469f-riscv64-linux-gnu.tar.gz
5f09a945771806ebab34cf9373867d81ce0d9852bd3bc04fbed70c85a12b3a3c guix-build-e6a94d44469f/output/x86_64-apple-darwin18/SHA256SUMS.part
c652df8757db78736164a5f011e764013c391cba981a5e26d560025aa64234db guix-build-e6a94d44469f/output/x86_64-apple-darwin18/bitcoin-e6a94d44469f-osx-unsigned.dmg
a0cdbf06390a01ec23d9c67873fe1af33d151ef3f1e46e57330f612605ef1c72 guix-build-e6a94d44469f/output/x86_64-apple-darwin18/bitcoin-e6a94d44469f-osx-unsigned.tar.gz
c0feb3b1b35f71724fe1b2cb83e2d3440f14ca789e9911aec09f695f0ddb832b guix-build-e6a94d44469f/output/x86_64-apple-darwin18/bitcoin-e6a94d44469f-osx64.tar.gz
fb4188b145a82f367b153d475a65740b19e51ba99ae7e6cbfca94575e5ba68b9 guix-build-e6a94d44469f/output/x86_64-linux-gnu/SHA256SUMS.part
3a198a2aa7f57154ac855c5fe6cc08d49cdee817bf3b6bb34aa2a37084dda1b8 guix-build-e6a94d44469f/output/x86_64-linux-gnu/bitcoin-e6a94d44469f-x86_64-linux-gnu-debug.tar.gz
f86cf1dba7aa85f4628589e0a1b84a69c1809674ab1ef67ae8b8674978de06c9 guix-build-e6a94d44469f/output/x86_64-linux-gnu/bitcoin-e6a94d44469f-x86_64-linux-gnu.tar.gz
fdd72a3ea5e04181b82fb28b34a2d64a7891ebfb0e0dd3422c2ec564a3497995 guix-build-e6a94d44469f/output/x86_64-w64-mingw32/SHA256SUMS.part
05a9b4a5a7dfde164379bec3f5a139568363ab9294a330173a4ebef601a91d5b guix-build-e6a94d44469f/output/x86_64-w64-mingw32/bitcoin-e6a94d44469f-win-unsigned.tar.gz
ecbcffddfa144f180a7dfdee40a14845465e938e7fc682fa0796b559cae44918 guix-build-e6a94d44469f/output/x86_64-w64-mingw32/bitcoin-e6a94d44469f-win64-debug.zip
86804458e7340b18c55adc715ffe282cd60f25b8b712be91593bcf8033049dab guix-build-e6a94d44469f/output/x86_64-w64-mingw32/bitcoin-e6a94d44469f-win64-setup-unsigned.exe
14d1bb8430a549baa789531e4cf8e4b2679100b3b0b05afde8a59a57819974fc guix-build-e6a94d44469f/output/x86_64-w64-mingw32/bitcoin-e6a94d44469f-win64.zip |
|
Concept ACK. |
|
Matching! |
Guix builds: |
But we support back to glibc 2.17...? (And it supports much older kernels) |
|
Kernel 4.19 for RISC-V 64 bit and 4.9 for the rest SGTM. |
|
review ACK e6a94d4 to change to vanilla guix. Did not review the kernel change. |
With Gitian builds on Focal, we were building against kernel header version 5.4: https://packages.ubuntu.com/focal/linux-libc-dev, https://packages.ubuntu.com/focal/linux-libc-dev-riscv64-cross I believe his change would be a strict improvement w/re compatibility. |
|
0.21.1 used bionic, not focal. It appears to have Linux 4.15, so yes, it is still a compat improvement to use 4.9. I don't care strongly either way, just making an observation. |
|
As said in #bitcoin-core-dev I don't think it should matter much (for backwards compatibility) what version of the kernel we build against as long as libc is linked dynamically. That said it's good to settle on a version to build against, just to avoid variability that causes unpredictable issues. The syscalls we use directly are:
So no problems there. I did a build and get the same output as @hebasto. ACK e6a94d4 |
fanquake
left a comment
fanquake
left a comment
There was a problem hiding this comment.
ACK e6a94d4
I don't think it should matter much (for backwards compatibility) what version of the kernel we build against as long as libc is linked dynamically.
This seems to match my understanding, as well as the advice provided by the glibc docs for when you compiling glibc:
What version of the Linux kernel headers should be used?
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.
Even if you are using an older kernel on your machine, we recommend you compile GNU libc with the most current kernel headers.
The key point being that you should be free to compile glibc against the latest kernel headers, even when targeting machines that are running older kernels.
The idea of compiling glibc against old kernel headers, as some sort of compatibility hack, is explicitly advised against, as then you might run into issues with machines running newer kernels. So, if anything, we could actually be building against even newer headers than what we are using here (maybe something to revisit later).
In any case, this clearly isn't any sort of regression in compatibility (if it even makes sense to call it that), so I think this change is ok as-is.
Unfortunately, Boost explicitly doesn't support running with kernels older than the one used to build. There is an actual bug of this nature that affects Bitcoin Core in some unusual cases. #21550 (However, the version we use in depends should be unaffected anyway - though I can't say I've looked into every potential kernel-header use) |
7 participants
This + the documentation PR should make our Guix system ready for release!