Hi! Christopher Baines <m...@cbaines.net> skribis:
> Then I faced two problems with the guix-build-coordinator > package. Firstly, wrap-program picks bash for Linux for the wrapper > script, which isn't very useful. I hacked around this by setting the > PATH such that it picked bash for the Hurd. In terms of properly fixing > this, I guess that needs to somehow be able to find the right bash, I'm > not sure how though? Looks like a bug in ‘wrap-program’ that we should fix in ‘core-updates’. ‘wrap-program’ uses (which "bash"), which is wrong in a cross-compilation context. We should at least add a #:bash parameter to ‘wrap-program’, but then all callers will have to pass it. I’m not sure how to let it do the right thing by default. > The second issue is that I'm not sure capturing the build time > GUILE_LOAD_COMPILED_PATH doesn't seem to work, at least file says that > the .go files this contains are built for a 64-bit architecture. I > worked around this by constructing the GUILE_LOAD_COMPILED_PATH from the > inputs I knew should be on it. Maybe it should always have been done > this way, any ideas? Instead of capturing the build-time ‘GUILE_LOAD_COMPILED_PATH’, which doesn’t contain the target .go files, you should explicitly list the inputs as is done in the ‘guix’ package for example. That’ll ensure the binary refers to the cross-compiled .go files. > There's also one problem probably within the Guix Build Coordinator > itself, after doing a few builds, it will just stop. I've only seen this > behaviour on the Hurd, but I'm unsure how to debug it, any suggestions? > My only idea is add more logging. No idea, but I guess that could just be a crash. Can you still log in afterwards? BTW, note that builds on GNU/Hurd are currently not isolated, and thus it’s the wild west in terms of reproducibility: https://issues.guix.gnu.org/43857 There are open questions as to what to include in the build environment: https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ Ludo’.
