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’.
prev parent 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.