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

l...@gnu.org (Ludovic Courtès) skribis: > Thinking more about it, why not simply always enable substitutes for > fixed-output derivations, like this: > > diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc > index d68e8b2bc..03a8f5080 100644 > --- a/nix/libstore/build.cc > +++

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

Leo Famulari skribis: > On Mon, Oct 02, 2017 at 10:00:33PM +0200, Ludovic Courtès wrote: >> Right. Jan suggested checking the content-addressed mirrors *before* >> the real upstream address. That would address the problem of upstream >> sources modified in-place, but at the

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

On Mon, Oct 02, 2017 at 10:00:33PM +0200, Ludovic Courtès wrote: > Right. Jan suggested checking the content-addressed mirrors *before* > the real upstream address. That would address the problem of upstream > sources modified in-place, but at the cost of privacy/self-sufficiency > as you note.

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

Maxim Cournoyer writes: > If we can trust the Homebrew list to be extensive, it seems we got > lucky; there's only one affected package that we share which is > yaml-cpp. Here's how it fails on our side: I needed to also use (ice-9 regex) and then I found these to fail antlr3 csound

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

I've modified the script to sort the packages it prints: --8<---cut here---start->8--- -(for-each (lambda (p) - (format #t "~a~%" (package-name p))) - packages))) +(for-each (lambda (name) + (format #t "~a~%"

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

Leo Famulari writes: > On Wed, Oct 04, 2017 at 12:22:34AM -0400, Maxim Cournoyer wrote: >> Here are the first 10 lines of the output: >> --8<---cut here---start->8--- >> Number of potentially problematic GitHub packages:1011 >> fdupes >>

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

On Wed, Oct 04, 2017 at 12:22:34AM -0400, Maxim Cournoyer wrote: > Here are the first 10 lines of the output: > --8<---cut here---start->8--- > Number of potentially problematic GitHub packages:1011 > fdupes > cbatticon > sedsed > cpulimit > autojump > sudo I

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

Leo Famulari writes: > On Mon, Oct 02, 2017 at 06:47:06PM -0400, Maxim Cournoyer wrote: >> Leo Famulari writes: >> > I wonder, are there really that many affected packages? >> >> There's a list here: >>

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

Leo Famulari writes: > On Mon, Oct 02, 2017 at 04:57:38PM +0200, Ludovic Courtès wrote: >> Hi! >> >> Leo Famulari skribis: >> >> > I contacted GitHub about this issue a few weeks ago and they said that: >> > >> > 1) They do not guarantee

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

On Mon, Oct 02, 2017 at 04:57:38PM +0200, Ludovic Courtès wrote: > Hi! > > Leo Famulari skribis: > > > I contacted GitHub about this issue a few weeks ago and they said that: > > > > 1) They do not guarantee bit-reproducibility of the snapshots they > > generate

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

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

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

Hello, Jan Nieuwenhuizen 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

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

Hi! Leo Famulari skribis: > I contacted GitHub about this issue a few weeks ago and they said that: > > 1) They do not guarantee bit-reproducibility of the snapshots they > generate automatically for each release tag, and they wish that people > would not rely on them as we

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

Leo Famulari transcribed 2.3K bytes: > On Sun, Oct 01, 2017 at 09:20:42PM +0200, Jan Nieuwenhuizen wrote: > > Jan Nieuwenhuizen writes: > > > > The changing of the libgit-0.26.0 checksum was already reported about 3 > > weeks ago (github seems to only show relative dates) > > > >

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

On Sun, Oct 01, 2017 at 09:20:42PM +0200, Jan Nieuwenhuizen wrote: > Jan Nieuwenhuizen writes: > > The changing of the libgit-0.26.0 checksum was already reported about 3 > weeks ago (github seems to only show relative dates) > > https://github.com/libgit2/libgit2/issues/4343 > > and the

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

Jan Nieuwenhuizen writes: The changing of the libgit-0.26.0 checksum was already reported about 3 weeks ago (github seems to only show relative dates) https://github.com/libgit2/libgit2/issues/4343 and the bug is still open. It seems to be a github thing. As I understand it, currently our

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

Hi! As reported by laertus on irc[0]: guix pull on 0.13 without substitutes fails 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