Acknowledgement sent
to Simon Tournier <zimon.toutoune@gmail.com>:
New bug report received and forwarded. Copy sent to ludo@gnu.org, bug-guix@gnu.org.
(Fri, 26 Apr 2024 08:50:12 GMT) (full text, mbox, link).
Subject: Re: bug#70588: hash mismatch error and stop fallback
Date: Wed, 01 May 2024 12:36:27 +0200
Hi,
Simon Tournier <zimon.toutoune@gmail.com> skribis:
> Other said, hash mismatch should be raised and obviously the content
> must be discarded; then the hash mismatch should be considered as “not
> found” so let try the next strategy for downloading the content.
Agreed. I merged it with <https://issues.guix.gnu.org/28659>.
Thanks,
Ludo’.
Severity set to 'important' from 'normal'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Wed, 01 May 2024 10:37:03 GMT) (full text, mbox, link).
Merged 2865970588.
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Wed, 01 May 2024 10:37:04 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#70588; Package guix.
(Fri, 03 May 2024 18:33:02 GMT) (full text, mbox, link).
Subject: Re: bug#70588: hash mismatch error and stop fallback
Date: Fri, 03 May 2024 19:53:39 +0200
Hi,
On lun., 02 oct. 2017 at 17:09, ludo@gnu.org (Ludovic Courtès) wrote:
> The problem is that the hash check is performed by guix-daemon itself,
> not by “guix perform-download”. So when guix-daemon diagnoses a hash
> mismatch, it’s too late and we cannot try again and use the
> content-addressed mirror.
This quote from [1]. Well, why not run a sequence of “guix download”
then “guix build”? Ah the store item would be hashed twice. Let try to
avoid this sub-optimized behaviour.
The only way to avoid hashing twice is to extend the protocol of
guix-daemon. Because currently it reads,
/* Check the hash. */
Hash h2 = recursive ? hashPath(ht, actualPath).first : hashFile(ht, actualPath);
if (h != h2) {
if (settings.printBuildTrace)
printMsg(lvlError, format("@ hash-mismatch %1% %2% %3% %4%")
% path % i->second.hashAlgo
% printHash16or32(h) % printHash16or32(h2));
throw BuildError(format("hash mismatch for store item '%1%'") % path);
}
with the call under error catch:
/* Compute the FS closure of the outputs and register them as
being valid. */
registerOutputs();
[...]
} catch (BuildError & e) {
Thus the number of solutions is very limited. :-)
Well, from my understanding, moving elsewhere in guix-daemon the check
of the hash appears to me too cumbersome. Therefore, the only way is to
replace this ’BuildError’ by something that is not an error and do not
register the item.
Easier to say than to implement. Again from my understanding, each
strategy for downloading is seen by the daemon as an element of a list
of independent builds and these elements are tried in sequence.
Therefore, we need to special case in order to be able to distinguish
different kind of failures.
All in all, this bug (missing feature):
Other said, hash mismatch should be raised and obviously the content
must be discarded; then the hash mismatch should be considered as “not
found” so let try the next strategy for downloading the content.
is not straightforward to fix. :-) Need for more thought…
Cheers,
simon
1: bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
ludo@gnu.org (Ludovic Courtès)
Mon, 02 Oct 2017 17:09:39 +0200
id:87o9ppoabw.fsf@gnu.org
https://issues.guix.gnu.org/28659https://issues.guix.gnu.org/msgid/87o9ppoabw.fsf@gnu.orghttps://yhetil.org/guix/87o9ppoabw.fsf@gnu.org
Changed bug title to 'Content-addressed mirror is not used upon invalid hash' from 'hash mismatch error and stop fallback'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Mon, 13 May 2024 10:21:02 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.