all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: 33737@debbugs.gnu.org
Subject: bug#33737: do not attempt to build a package known to be broken
Date: Tue, 18 Dec 2018 11:50:01 +0100	[thread overview]
Message-ID: <87mup3hzxi.fsf@gnu.org> (raw)
In-Reply-To: <87imztw2zx.fsf@elephly.net> (Ricardo Wurmus's message of "Sun, 16 Dec 2018 22:55:30 +0100")

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Danny Milosavljevic <dannym@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’.

      reply	other threads:[~2018-12-18 10:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14  4:41 bug#33737: do not attempt to build a package known to be broken Ricardo Wurmus
2018-12-15 18:54 ` Björn Höfling
2018-12-15 19:39   ` znavko
2018-12-16 20:14 ` Danny Milosavljevic
2018-12-16 21:55   ` Ricardo Wurmus
2018-12-18 10:50     ` Ludovic Courtès [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mup3hzxi.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=33737@debbugs.gnu.org \
    --cc=rekado@elephly.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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.