bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail

[Jan Nieuwenhuizen <janneke@gnu.org>]

Ludovic Courtès writes:

> What’s sad here is that we do have the right tarball at:
>
>   https://mirror.hydra.gnu.org/file/libgit2-0.25.1.tar.gz/sha256/1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s

Sad indeed!

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

Why don't we try our content-addressed mirror first?

> A crude but helpful fix would be to have perform-download compute the
> hash by itself and act accordingly.  It’s crude because that means that
> we’d be computing the hash twice: once in ‘guix perform-download’ and a
> second time in guix-daemon.  For archives below ~20 MiB it’s probably OK
> though.
>
> Thoughts?

We may want more guix hackers' viewpoints here, I don't feel very
qualified...As this would be a temporary workaround only until we have

> In the future, with the daemon written in Guile, it’s one area where we
> could achieve better integration and coordination among the various
> pieces.

...it might be fine?

Do we want/need to bring out a new release for this, e.g. 0.13.1, or
even 0.14?  I'm not sure how bad it is that --no-substitutes does not
work.  I think working on guix pull to not compile everything locally
may have priority?

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com