[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#39993: Guix report hash mismatch when underlying cause is ENOSPC,
Maxim Cournoyer <=