all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Jonathan Brielmaier <jonathan.brielmaier@web.de>
Cc: 43079@debbugs.gnu.org
Subject: bug#43079: guix ignores available substitutes
Date: Mon, 31 Aug 2020 22:54:40 +0200	[thread overview]
Message-ID: <87imcybkof.fsf@gnu.org> (raw)
In-Reply-To: <f766036e-9cff-3bb8-9ad6-0bfb8e920608@web.de> (Jonathan Brielmaier's message of "Mon, 31 Aug 2020 17:59:42 +0200")

Hi Jonathan,

Jonathan Brielmaier <jonathan.brielmaier@web.de> skribis:

> On 28.08.20 16:23, Ludovic Courtès wrote:
>> I’m not sure what conclusions you’re drawing here?  :-)
>
> That my laptop doesn't really get substitutes...
>
>> As you found, each entry in /var/guix/substitute/cache has a TTL,
>> including for negative lookups.  This is why one can observe different
>> behaviors on different machines: one machine can think the substitute is
>> unavailable (cached negative entry not yet expired), while the other got
>> a positive lookup soon after the substitute had been “baked” on the
>> server.
>>
>> TTLs vary.  For successful lookups, this is usually a long TTL (see
>> ‘guix publish --ttl’).  For negative lookups, there are two cases: a
>> 1h-or-so TTL for “absolute no”, and a 5mn TTL for
>> “substitute-being-baked no”.
>
> So my question is how I can influence/change that behaviour for my
> client? Because the current situation on my laptop is awful. And if it
> doesn't get better I will move away that system from Guix System...

I understand and sympathize with your frustration.  The issue is that
the build farm has been lagging behind: some substitutes tend to not be
available quickly enough, and in some cases it’s particularly annoying
(icecat, libreoffice, you name it.)

Before running ‘guix upgrade’, you can try:

  guix weather $(guix package -I | cut -f1)

That’ll show you whether now is a good time to upgrade, or whether you
should wait a little longer to do that.

As you know, there’s work to improve the situation on the build farm
(and perhaps with the tools themselves), but until that happens, this is
what I’d recommend.

HTH!

Ludo’.




      reply	other threads:[~2020-08-31 20:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 23:39 bug#43079: guix ignores available substitutes Jonathan Brielmaier
2020-08-28  0:04 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-08-28 14:23 ` Ludovic Courtès
2020-08-31 15:59   ` Jonathan Brielmaier
2020-08-31 20:54     ` 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=87imcybkof.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=43079@debbugs.gnu.org \
    --cc=jonathan.brielmaier@web.de \
    /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.