GNU bug report logs - #41878
'guix substitute' and 'guix pull' fail gracelessly on flaky networks

Previous Next

Full log

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Brendan Tildesley <mail <at> brendan.scot>
Cc: 41878 <at> debbugs.gnu.org
Subject: Re: bug#41878: 'guix substitute' and 'guix pull' fail gracelessly
 on flaky networks
Date: Fri, 11 Sep 2020 16:17:05 +0200

Dear,

On Sun, 30 Aug 2020 at 20:06, Brendan Tildesley <mail <at> brendan.scot> wrote:
> I have not looked closely but from observation I think currently guix first
> decides if it is going to commit to using a substitute, or falling back to
> building locally, by checking if substitutes are available then committing to
> a method. This differs from the concept of a fallback in my head, which would
> involve trying option B only after option A has been tried and failed. guix's
> way means there are a class of failures where guix simply gives up and stops
> instead of falling back.

What do you mean?

> In my experience, probably 10% of the time I try a guix pull; guix package -u
> ., there is some weird network error that doesn't happen the second time I run
> it. Perhaps it would be sufficient to simply try twice for every substitute;
> accumulate a list of failed substitutes and retry them after iterating through
> the list of substitutes to download, then if that fails try building from
> source. only then are we allowed to give up.

It rings a bell to me.  Something about the configuration of Cuirass and
the build farm serving the substitutes; related to caching.  But I am
not able to find the relevant pointer.


All the best,
simon

Previous Next

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