Re: proposal: make build failures explicit results in the store

[Taylan Ulrich Bayırlı/Kammer]

Florian Paul Schmidt <address@hidden> writes:

> Hi,
>
> currently I'm trying my hands on building _all_ available packages on
> the x86_64 platform in a qemu-vm (with the intended aim to later
> publish them to maybe take some load off hydra), but I came across an
> issue that might have an easy solution but I'm not sure exactly what's
> the right way to proceed.
>
> Basically what I did right now was this:
>
> for n in `guix package -A | cut -f1`; do guix build --no-substitutes\
> --max-silent-time=10 "$n" || true; done
>
> Watching it run I noticed something though: Some package, let's call
> it "foo1", seemed to have package "bar" as depencency (the concrete
> example for bar was Qt5 which is probably why I noticed ;)), but the
> bar build failed. So building foo1 failed, too. So far so good, aside
> from foo1's and bar's failure everything is fine.
>
> Now another package, foo2, comes along and it, too, depends on bar.
> Since bar failed to build previously guix thinks it's a swell idea to
> retry building bar. This, of course, is silly, and in this concrete
> example, Qt5, a massive waste of cpu cycles and the only good thing it
> does is to bring the universe closer to the heat death.

Hi,

You can run the Guix daemon with the switch --cache-failures and it will
do pretty much exactly what you want. :-)

(I'm not sure whether it actually puts the failures into /gnu/store in
some format, so "pretty much.")

Don't know why this isn't enabled by default.

Taylan