Ludovic Courtès writes: >> 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. This has now happened [1], so the guix-build-coordinator package should now cross compile in a useable way. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=eec127822a74c6a1a6100b07d94c8fb275d571bf >> 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? Not through SSH at least. Someone on IRC mentioned they'd had issues running Hurd VMs without swap, so getting swap in childhurds might be something to try. I started looking at this [2]. 2: https://issues.guix.gnu.org/46726 > 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/ Isolation would be nice of course, although I'm not sure how much this will affect reproducibility, unless things are poking around in the store directly.