all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Konrad Hinsen <konrad.hinsen@fastmail.net>
Cc: guix-devel@gnu.org, guix-sysadmin@gnu.org
Subject: narinfo/nar mismatch on nginx caches
Date: Thu, 11 May 2017 10:48:47 +0200	[thread overview]
Message-ID: <87y3u3vkwg.fsf_-_@gnu.org> (raw)
In-Reply-To: <74534164-70c1-d331-78aa-a92c11dd7b6f@fastmail.net> (Konrad Hinsen's message of "Wed, 10 May 2017 15:31:56 +0200")

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> On 07/05/2017 11:36, Ludovic Courtès wrote:
>
>>> guix pull: error: build failed: some substitutes for the outputs of derivation `/gnu/store/d1qkv7x8ayi75qjlg7d5j5g1h7y4fl5p-make-boot0-4.2.1.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
>>
>> I fixed it yesterday, let me know how that goes.
>
> There seems to be a reservoir of similar bugs.

Looks like it.  :-/  The hope with the new ‘guix publish --cache’ is
that these issues will vanish over time; the 404s that were reported are
for older store items for which we still had old entries in cache.

> Here is the one I just ran into:
>
> hash mismatch in downloaded path
> `/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.12': expected
> aea4335a5e6d65a36ed74561b15f8242773c49110be30d8ab7b43590f0568e60, got
> 49b3fc5b436309b4d097ed3c84946d5cab742db6159d76f5ad7a1d7896a2760f
> fetching path `/gnu/store/9761yfpvyr1fcpjhry8pgb3f0k6kj8n4-sed-4.2.2'...
> killing process 3685
> guix pull: error: build failed: some substitutes for the outputs of
> derivation
> `/gnu/store/wn2068qzbyh1v64dxxwbfjik7cjq0sji-python-2.7.12.drv' failed
> (usually happens due to networking issues); try `--fallback' to build
> derivation from source

This hash mismatch is a different story: this package did not build
deterministically, caches have kept the data (the nar) but they have
updated the meta-data (narinfo), which now advertises a different hash.
IOW, the cached data no longer matches the meta-data.

If we were not running nginx caches in front of ‘guix publish --cache’,
we would not have these problems.  However, we need those caches to
distribute the load.

Long-term the best option of course is to have all packages be
bit-reproducible, but until we get there, I’m not sure how to address
it.  Thoughts anyone?

Thanks for your report,
Ludo’.

      reply	other threads:[~2017-05-11  8:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 12:30 I can not run 'guix pull', how to deal with tumashu
2017-05-05 13:07 ` ng0
2017-05-05 13:23   ` ng0
2017-05-05 16:15 ` Ludovic Courtès
2017-05-06 10:13   ` tumashu
2017-05-07  9:36     ` Ludovic Courtès
2017-05-10 13:31       ` Konrad Hinsen
2017-05-11  8:48         ` 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=87y3u3vkwg.fsf_-_@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=guix-sysadmin@gnu.org \
    --cc=konrad.hinsen@fastmail.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.