Conversation
…stsuite argp-standalone pass1 builds in a separate build directory. Its testsuite compiles sources that include <argp.h>, but without an explicit include path the header in the source root is not found and build fails. Set: - CPPFLAGS=-I/Users/luoyanpan/CLionProjects/guix/live-bootstrap/.. in src_configure so testsuite objects can resolve argp.h during the normal phase.
…olchain instead of relying on make install
…generation and fts/argp env wiring
…al LIBS and setting host/build + kernel-toolchain env
…ied sha256 and wire it before elfutils
…hs, and disable unused-but-set-variable as error
…compress, and debuginfod client
…mpile via rpath-link and explicit LIBS
feat(steps-guix): add libgcrypt-1.12.1 default build with gcc-detected host and pkg-config path feat(steps-guix): add guile-gcrypt-0.5.0 with dynamic libgcrypt prefix and ld library path
…and end with shared after
… out-of-tree build
…IR for libgcrypt lookup
So, has this issue been resolved or not? |
|
Resolved, yes. Now, there's a new issue: one of the tests for util-linux, related to user namespace handling, is failing. The cause: CONFIG_USER_NS disabled in the kernel configuration. I'm gonna set it to Y, and try again. |
…ing, readablity improvements(src_dir -> channel_repo)
|
With CONFIG_USER_NS=y in kconfig, util-linux's tests now pass, and Guix moves on to building Valgrind. |
Wait, what stage are you at right now? Are you on |
|
|
|
Ran into and debugged another issue: when building guix-manual, I get the following error: The cause: when this call is executed, However, Fix, option 1: in Fix, option 2: Use a clone or snapshot of the Guix Git repository, rather than a release tarball intended for human use, to prepare the local channel. (Preferably I would also switch the actual build of the Guix package to be based on a Git repository, although live-bootstrap has a preference for release tarballs.) For now, I have locally implemented option 1, and |
|
Successful guix pull - moving on to ISO build. EDIT: "disable-authentication: unrecognized option" - See Googulator/guix@ca0114e for a workaround; unfortunately this causes it to rerun the entire bootstrap :( |
|
Before the ISO build, one also needs to |
just to make sure, what I need to do is add this before iso build in |
|
Yes, exactly. One more thing: "--disable-authentication" on "guix system image" is invalid, and will error out unless removed. |
|
During the ISO build, I got an error complaining about a missing aux-files/logo.txt file. It's in gnu/installer in the tarball & channel repo, so before building the ISO, one needs to |
|
In the "build-native-utils-earlier" patch, the procedure It might also be necessary to change the target in the guix pull script to x86_64-linux, to avoid running the Guix bootstrap twice. EDIT: Oops... |
|
And... bitrot strikes. Guix tries to download 0001-unordered-fix-copy-assign.patch from boost.org, and then check it against a specific hash. But Boost decided to "clean up" their copy of this patch, removing trailing whitespace - breaking the hash. The original one with the right hash can still be found @ https://cdn.jsdelivr.net/npm/@openziti/ziti-sdk-nodejs@0.14.2/vcpkg/ports/boost-unordered/0001-unordered-fix-copy-assign.patch - manually copying it to /gnu/store/chzch29xi2gzdxbzk77sb432klkddra1-boost-0001-unordered-fix-copy-assign.patch seems to work (EDIT: it doesn't). |
Should we patch Guix to fix this problem? Just like the bootstrap binary, use a local web server to serve this file |
|
A local web server is probably a good idea, yes. |
|
Wait a minute, what do you mean by "it doesn't", you mean, the file didn't match or we can't copy it to |
|
Copying to the store directly didn't work. Modifying the package definition to use the alternative URL did. But now, I'm facing a new problem, where one of the "module-import-compiled" packages fails to build, apparently because contents of the host Guile (3.0.11) leak into the Guix environment, where the local Guile (3.0.9) can't execute them. I'm still working on solving this. |
What's the status of this issue? One thing that puzzles me is, aren't all Guix builds supposed to run in a chroot or namespace environment? |
No description provided.