[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
narinfo/nar mismatch on nginx caches
From: |
Ludovic Courtès |
Subject: |
narinfo/nar mismatch on nginx caches |
Date: |
Thu, 11 May 2017 10:48:47 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Hi Konrad,
Konrad Hinsen <address@hidden> 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’.