[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting the Guix Build Coordinator agent working on the Hurd
From: |
Ludovic Courtès |
Subject: |
Re: Getting the Guix Build Coordinator agent working on the Hurd |
Date: |
Thu, 18 Feb 2021 18:35:31 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi!
Christopher Baines <mail@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’.