Hello, Jan Nieuwenhuizen <jann...@gnu.org> skribis:
> As reported by laertus on irc[0]: guix pull on 0.13 without substitutes fails I just checked and we do have substitutes, but I understand it doesn’t help here. > guix pull > > Starting download of /tmp/guix-file.3r6cH0 > From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz... > ….tar.gz 5.7MiB/s 00:02 | 13.6MiB > transferred > unpacking > '/gnu/store/sginfwnrcfqn1far31gmzlaffd8xlxyy-guix-latest.tar.gz'... > > Starting download of > /gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz > From https://github.com/libgit2/libgit2/archive/v0.25.1.tar.gz... > following redirection to > `https://codeload.github.com/libgit2/libgit2/tar.gz/v0.25.1'... > v0.25.1 6.1MiB/s 00:01 | 4.1MiB > transferred > output path > `/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz' should > have sha256 hash `1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s', > instead has `0ywcxw1mwd56c8qc14hbx31bf198gxck3nja3laxyglv7l57qp26' 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 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. 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? 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. Ludo’.
