unofficial mirror of bug-guix@gnu.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

  List information: https://guix.gnu.org/

* 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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).