GNU bug report logs - #36614
rust@1.36's hash is incorrect.

Previous Next

Full log

Message #22 received at 36614-done <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Ivan Petkov <ivanppetkov <at> gmail.com>
Cc: 36614-done <at> debbugs.gnu.org
Subject: Re: bug#36614: rust <at> 1.36's hash is incorrect.
Date: Fri, 12 Jul 2019 19:26:07 +0200

[Message part 1 (text/plain, inline)]

Ivan,

Ivan Petkov wrote:
> My apologies, this was all partly my fault. I do have the old 
> source lying
> around, diffing the two (attached) reveals that the changelog 
> and one source
> file actually changed.
>
> A bit more detailed context:
> The rust project makes pre-release sources available for testing 
> ahead of
> the formal release, and the process is meant to shake out any 
> potential bugs.
> I tested with the prerelease build originally, and after the 
> real release
> came out I updated the package URL to the formal release and 
> immediately
> rebuilt successfully.

No apologies necessary.  It's nice to know that our Rust updates 
will always follow swiftly on the heels of upstream as long as you 
take care of them.  However, please make sure to check the 
signature (.asc) once the final release is cut; one never knows...

> I'm not 100% sure if maybe guix reused the cached tarball I had 
> from earlier,
> or whether the prerelease source was immediately upgraded to the 
> formal release
> and fixed shortly after. (I did try rebuilding right before 
> pushing the change
> out which succeeded with no changes, which I'm guessing is 
> because guix did
> not redownload the tarball and why I didn't notice the hash 
> mismatch).

Yes, this is exactly what happened.  I consider this is a feature 
of Guix, even though it can feel like a gotcha sometimes.  :-)

We often tend to think of the source URL(s) as an ‘identifier’ of 
the source file.  However, it is nothing more than a hint about 
its *location*.  The only authoritative identifier of its 
*content* is the hash: to get *this file* (content hash), try 
looking *here* (location: URL).

One origin may have 0 or more source URLs: Guix will try them all 
until it downloads something matching the hash (and if even that 
fails it will try some implicit ones like tarballs.nixos.org).

   ‘Unique’ identifier (hash)
     ├ maybe you can *find* it here (URL)
     ├ or here (another URL)
     ├ hell maybe here I don't know (yet another URL)
     ⋮
     
Guix cares only about the content of the file; it doesn't care or 
even remember how it got it.  Or: if you change the download hint 
(release URL in this case), Guix won't care, because you didn't 
change the hash.

I hope that makes some sense,

T G-R

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.