bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45826: SBCL / Common Lisp packages fail to build on aarch64


From: Christopher Baines
Subject: bug#45826: SBCL / Common Lisp packages fail to build on aarch64
Date: Sun, 17 Jan 2021 11:35:49 +0000
User-agent: mu4e 1.4.14; emacs 27.1

Mathieu Othacehe <othacehe@gnu.org> writes:

> Hello Leo & Guillaume,
>
>> That's a good observation. I hadn't thought of it.
>>
>> I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable
>> these builds until we can fix the bug for real. Mathieu: this might
>> explain why the build farm is spending all its effort on aarch64.
>
> If we want to disable SBCL builds temporarily we can do something
> similar to what I did to disable Rust builds on non-x86_64 architectures
> here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.
>
> Regarding the rebuilding that is a limitation of the new Cuirass remote
> building mechanism I am aware of and I need to solve. As build failures
> are only cached of the machine performing the build and the builds are
> now distributed to all the machines across the build farm, we need to
> find a way to centralize the builds failure cache.
>
> It would also be nice to optionally publish the build failures cache so
> that the user doesn't try to build a package that is known to be failing
> on the build farm. Chris, have you encountered this issue with the Build
> Coordinator?

Not really. The first thing to note is that I'm running the Guix Build
Coordinator currently without the guix-daemon --cache-failures option,
in fact it's probably unwise to do so, as it would mean that rather than
some builds taking place, the guix-daemon could just return a cached
failure. I should probably mention this in the README.

The way this situation is dealt with in the Guix Build Coordinator is
simplified by the agents not attempting builds where the derivation
inputs aren't present. If an agent is unable to ensure all the inputs
are present, it just reports this to the coordinator.

The behaviour is configurable, but the default missing inputs hook will
submit a new build for a missing input, but only if one doesn't already
exist. Because of this, you don't get the behaviour where some missing
prerequisite that fails to built is built over and over again, every
time you try and build a derivation that uses it.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]