GNU bug report logs - #33737
do not attempt to build a package known to be broken

Previous Next

To reply to this bug, email your comments to 33737 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Ricardo Wurmus <rekado <at> elephly.net>
To: bug-guix <at> gnu.org
Subject: do not attempt to build a package known to be broken
Date: Fri, 14 Dec 2018 05:41:37 +0100

The default use case is for users to have substitutes enabled and to
fetch binaries from a build farm.  The build farm tries to build all
packages, but not all builds succeed.  The daemon caches build failures.

This information, however, is not available for users.  The default
behaviour of Guix is to attempt building the package locally.  This is
fine for packages that the build farm hasn’t attempted yet, but it is a
waste of time when the build has already been attempted without success.

I propose that “guix publish” should also convey information about
failed builds.  The Guix client can then abort right away without
wasting time and power to attempt a doomed build.  Users may override
this with “--fallback” or a new option.

--
Ricardo

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

From: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 33737 <at> debbugs.gnu.org
Subject: Re: bug#33737: do not attempt to build a package known to be broken
Date: Sat, 15 Dec 2018 19:54:37 +0100

[Message part 1 (text/plain, inline)]

On Fri, 14 Dec 2018 05:41:37 +0100
Ricardo Wurmus <rekado <at> elephly.net> wrote:

> The default use case is for users to have substitutes enabled and to
> fetch binaries from a build farm.  The build farm tries to build all
> packages, but not all builds succeed.  The daemon caches build
> failures.
> 
> This information, however, is not available for users.  The default
> behaviour of Guix is to attempt building the package locally.  This is
> fine for packages that the build farm hasn’t attempted yet, but it is
> a waste of time when the build has already been attempted without
> success.

+1

Very good idea.

Björn

[Message part 2 (application/pgp-signature, inline)]

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

From: <znavko <at> tutanota.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33737 <at> debbugs.gnu.org
Subject: Re: bug#33737: do not attempt to build a package known to be broken
Date: Sat, 15 Dec 2018 20:39:21 +0100 (CET)

[Message part 1 (text/plain, inline)]

Package can have additional fields in guix repository, like
architecture, version, buid_status, source_type
build_status may contain such info. 
source_type could show if the package source url is one of those public git services (thus, user could enable proxy first).


Dec 15, 2018, 6:54 PM by bjoern.hoefling <at> bjoernhoefling.de:

> On Fri, 14 Dec 2018 05:41:37 +0100
> Ricardo Wurmus <> rekado <at> elephly.net <mailto:rekado <at> elephly.net>> > wrote:
>
>> The default use case is for users to have substitutes enabled and to
>> fetch binaries from a build farm.  The build farm tries to build all
>> packages, but not all builds succeed.  The daemon caches build
>> failures.
>>
>> This information, however, is not available for users.  The default
>> behaviour of Guix is to attempt building the package locally.  This is
>> fine for packages that the build farm hasn’t attempted yet, but it is
>> a waste of time when the build has already been attempted without
>> success.
>>
>
> +1
>
> Very good idea.
>
> Björn
>

[Message part 2 (text/html, inline)]

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 33737 <at> debbugs.gnu.org
Subject: Re: bug#33737: do not attempt to build a package known to be broken
Date: Sun, 16 Dec 2018 21:14:51 +0100

[Message part 1 (text/plain, inline)]

On Fri, 14 Dec 2018 05:41:37 +0100
Ricardo Wurmus <rekado <at> elephly.net> wrote:

> The default use case is for users to have substitutes enabled and to
> fetch binaries from a build farm.  The build farm tries to build all
> packages, but not all builds succeed.  The daemon caches build failures.
> 
> This information, however, is not available for users.  The default
> behaviour of Guix is to attempt building the package locally.  This is
> fine for packages that the build farm hasn’t attempted yet, but it is a
> waste of time when the build has already been attempted without success.
> 
> I propose that “guix publish” should also convey information about
> failed builds.  The Guix client can then abort right away without
> wasting time and power to attempt a doomed build.  Users may override
> this with “--fallback” or a new option.

As long as we distinguish transient build machine errors (disk full, can't
resolve hostname, too many names in directory, no inodes left etc) from actual
errors in the source code, +1.

[Message part 2 (application/pgp-signature, inline)]

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

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 33737 <at> debbugs.gnu.org
Subject: Re: bug#33737: do not attempt to build a package known to be broken
Date: Sun, 16 Dec 2018 22:55:30 +0100

Danny Milosavljevic <dannym <at> scratchpost.org> writes:

>> I propose that “guix publish” should also convey information about
>> failed builds.  The Guix client can then abort right away without
>> wasting time and power to attempt a doomed build.  Users may override
>> this with “--fallback” or a new option.
>
> As long as we distinguish transient build machine errors (disk full, can't
> resolve hostname, too many names in directory, no inodes left etc) from actual
> errors in the source code, +1.

I was thinking of something very simple.  The daemon is already capable
of caching build failures; I think it may be good to simply pass that
information on to clients.

I don’t know how we could distinguish different kinds of build failures
with the current daemon.

--
Ricardo

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 33737 <at> debbugs.gnu.org, Danny Milosavljevic <dannym <at> scratchpost.org>
Subject: Re: bug#33737: do not attempt to build a package known to be broken
Date: Tue, 18 Dec 2018 11:50:01 +0100

Hello!

Ricardo Wurmus <rekado <at> elephly.net> skribis:

> Danny Milosavljevic <dannym <at> scratchpost.org> writes:
>
>>> I propose that “guix publish” should also convey information about
>>> failed builds.  The Guix client can then abort right away without
>>> wasting time and power to attempt a doomed build.  Users may override
>>> this with “--fallback” or a new option.

Good idea!

The difficulty is that the protocol between ‘guix substitute --query’
and the daemon is currently very much Boolean: either ‘guix substitute’
provides the binary or it doesn’t.  We’d have to adjust it.

>> As long as we distinguish transient build machine errors (disk full, can't
>> resolve hostname, too many names in directory, no inodes left etc) from actual
>> errors in the source code, +1.
>
> I was thinking of something very simple.  The daemon is already capable
> of caching build failures; I think it may be good to simply pass that
> information on to clients.

The daemon tries to cache only “persistent” failures.  In particular,
local failures likely due to lack of space are not cached.

However, the daemon currently doesn’t distinguish between ENOSPC and
actual failures for offloaded builds.  We may be able to fix this by
having ‘guix offload’ check the available disk space upon failure.

Then there’s the problem of non-deterministic failures.  For these it
would be nicer to let the user build stuff anyway.  There’s no good
solution here.

Ludo’.

Previous Next

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