guix-devel
[Top][All Lists]
Advanced

[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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]