GNU bug report logs - #22078
failed builds due to exceeding max-silent-time not marked as failed in db

Previous Next

Package: guix;

Reported by: Florian Paul Schmidt <mista.tapas <at> gmx.net>

Date: Wed, 2 Dec 2015 22:04:02 UTC

Severity: normal

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

Full log


Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Florian Paul Schmidt <mista.tapas <at> gmx.net>
To: bug-guix <at> gnu.org
Subject: Re: bug#22078: failed builds due to exceeding max-silent-time not
 marked as failed in db
Date: Fri, 4 Dec 2015 23:40:35 +0100
[Message part 1 (text/plain, inline)]
Attached is a first stab at fixing this. There are additional options to 
guix-daemons now:

      --cache-failures       cache build failures
      --cache-hook-failures  cache build failures due to hook failures 
(depends
                             on cache-failures)
      --cache-timeout-failures   cache build failures due to timeouts 
(depends
                             on cache-failures)

Patch compiles, but is yet untested since the system I need it has gone 
away for the time being..

Flo

On 12/02/2015 11:03 PM, Florian Paul Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> Hi,
>
> on my system bulding the derivation for the package tbb (version
> 4.3.2) does not complete due to exceeding the max-silent-time default
> value of 3600 seconds (one hour).
>
> It seems that in this case the path is not marked as failed in the
> sqlite3 db
>
> /var/guix/db/db.sqlite
>
> in the table FailedPaths. This is quite annoying since it seems that
> several packages depend on it causing the derivation to be built
> several times (each taking over an hour to fail).
>
> The guix daemon is running with the --cache-failures option and I
> would expect the second run of
>
> for n in `guix package -A | cut -f1`; do guix build --no-substitutes
> "$n" || true; done
>
> to be mostly a NOOP, since all failures from the first run should be
> cached. And even in the first run I wouldn't expect failed
> dependencies to be tried to build again. Contrary to this on this box
> even the second run of this takes about half a day or so to complete ;)
>
> Flo
>
> P.S.: FYI: The thing that takes over an hour to run is
>
> ./test_atomic.exe
>
>
> - -- 
> https://fps.io
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
> TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
> Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
> l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
> VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
> DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
> =Hivd
> -----END PGP SIGNATURE-----
>
>
>

[0001-guix-daemon-cache-more-failures-if-requested.patch (text/plain, attachment)]

This bug report was last modified 9 years and 198 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.