From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: Getting the Guix Build Coordinator agent working on the Hurd
Date: Thu, 18 Feb 2021 18:35:31 +0100 [thread overview]
Message-ID: <87v9app9cs.fsf@gnu.org> (raw)
In-Reply-To: <87tuqekheb.fsf@cbaines.net> (Christopher Baines's message of "Sun, 14 Feb 2021 11:39:24 +0000")
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’.
next prev parent reply other threads:[~2021-02-18 17:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-14 11:39 Getting the Guix Build Coordinator agent working on the Hurd Christopher Baines
2021-02-15 15:12 ` Joshua Branson
2021-02-16 8:58 ` Christopher Baines
2021-02-16 8:57 ` Christopher Baines
2021-02-18 9:25 ` Christopher Baines
2021-02-18 17:35 ` Ludovic Courtès [this message]
2021-02-23 20:58 ` Christopher Baines
2021-03-10 10:10 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v9app9cs.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mail@cbaines.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).