bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39993: Guix report hash mismatch when underlying cause is ENOSPC


From: Maxim Cournoyer
Subject: bug#39993: Guix report hash mismatch when underlying cause is ENOSPC
Date: Sat, 18 Apr 2020 00:17:43 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Ludovic,

Ludovic Courtès <address@hidden> writes:

> Hi Maxim,
>
> Maxim Cournoyer <address@hidden> skribis:
>
>> Ludovic Courtès <address@hidden> writes:
>>
>>> Hi Maxim,
>>>
>>> Maxim Cournoyer <address@hidden> skribis:
>>>
>>>> Maxim Cournoyer <address@hidden> writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> Ludovic Courtès <address@hidden> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>> Starting download of 
>>>>>> /gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz
>>>>>> From
>>>>>> https://archive.softwareheritage.org/api/1/content/sha256:2cd47cb3d460b6ff75f4a9940f594317ad456cfbf2bd2c8e5151e16559db6410/raw/...
>>>>>> In procedure fport_write: Ne haviĝas plu da spaco sur aparato
>>>>>> failed to download
>>>>>> "/gnu/store/124q26gkdyls859sblabz3f60grfvvdl-tcpdump-4.9.3.tar.gz"
>>>>>> from "https://www.tcpdump.org/release/tcpdump-4.9.3.tar.gz";
>>>>>> warning: rewriting hashes in 
>>>>>> `/gnu/store/mv33j0si1n75q9kdimhvyrjn05pbxz5b-tcpdump-4.9.3.tar.gz'; 
>>>>>> cross fingers
>>>>>> sha256 hash mismatch for 
>>>>>> /gnu/store/mv33j0si1n75q9kdimhvyrjn05pbxz5b-tcpdump-4.9.3.tar.gz:
>>>>>>   expected hash: 0434vdcnbqaia672rggjzdn4bb8p8dchz559yiszzdk0sjrprm1c
>>>>>>   actual hash:   0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
>>>>>> hash mismatch for store item 
>>>>>> '/gnu/store/mv33j0si1n75q9kdimhvyrjn05pbxz5b-tcpdump-4.9.3.tar.gz'
>>>>>>
>>>>>>> The root cause is that ‘false-if-exception*’ as used in (guix build
>>>>>>> download) is too coarse-grain.
>>>>>>
>>>>>> I came up with a fix in 4a6ec23a9780bd75a7e527bd0dfb1943347869bb.
>>>>
>>>> I'm re-opening this issue, as it occurred again using Guix
>>>> 7ff639510096ff762b9cced5fba6db254a961af9.
>>>
>>> Yes, that’s because we need to update the ‘guix’ package.  Concretely,
>>> in this case, the code I modified in invoked via a “builtin:download”
>>> derivation, and thus running on the daemon side; that’s why.
>>>
>>> We can close once ‘guix’ is updated if you want.
>>
>> Oh! I see. Seems like an nice opportunity for me to learn about doing
>> so. I see we have a target for it in our Makefile.am.  Should I proceed?
>
> Sure, you can give it a try.  “make update-guix-package &&
> ./pre-inst-env guix build guix” basically.
>
> In general we try to do this once in a while, when several daemon-side
> changes have accumulated.

I see it's been bumped to 1.1.0 three days ago. Closing.

Maxim





reply via email to

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