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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36614 in the body.
You can then email your comments to 36614 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pierre Langlois <pierre.langlois <at> gmx.com>
To: Bug guix <bug-guix <at> gnu.org>
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>,
 Ivan Petkov <ivanppetkov <at> gmail.com>
Subject: rust <at> 1.36's hash is incorrect.
Date: Fri, 12 Jul 2019 10:41:59 +0100

Hello Guix!

It looks like the hash for the new rust 1.36 is wrong, I get the following:

~~~
$ guix build rust
building /gnu/store/37wfhzp1yqm9w4vq0dhmy6bg3ajaa9yh-rustc-1.36.0-src.tar.gz.drv...

Starting download of /gnu/store/jm9xvf6qy4zxkb7rkmpz8ygf55l8v8v5-rustc-1.36.0-src.tar.gz
From https://static.rust-lang.org/dist/rustc-1.36.0-src.tar.gz...
downloading from https://static.rust-lang.org/dist/rustc-1.36.0-src.tar.gz...
 rustc-1.36.0-src.tar.gz  147.5MiB                                                            1.6MiB/s 01:35 [##################] 100.0%
sha256 hash mismatch for /gnu/store/jm9xvf6qy4zxkb7rkmpz8ygf55l8v8v5-rustc-1.36.0-src.tar.gz:
  expected hash: 18r688ih4xi9m8gv55g1amb8inrwkdxp5fbcqb6i4gqxi90l3i0m
  actual hash:   06xv2p6zq03lidr0yaf029ii8wnjjqa894nkmrm6s0rx47by9i04
hash mismatch for store item '/gnu/store/jm9xvf6qy4zxkb7rkmpz8ygf55l8v8v5-rustc-1.36.0-src.tar.gz'
build of /gnu/store/37wfhzp1yqm9w4vq0dhmy6bg3ajaa9yh-rustc-1.36.0-src.tar.gz.drv failed
View build log at '/var/log/guix/drvs/37/wfhzp1yqm9w4vq0dhmy6bg3ajaa9yh-rustc-1.36.0-src.tar.gz.drv.bz2'.
cannot build derivation `/gnu/store/wzslkk72p8g9l5zymcb4hqfmq4zg29q7-rustc-1.36.0-src.tar.xz.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/61660f8p8xxdrhl267402yzq2d4c89ix-rust-1.36.0.drv': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/61660f8p8xxdrhl267402yzq2d4c89ix-rust-1.36.0.drv' failed
~~~

Can you also reproduce this?

Hopefully it's not unstable :-/.

Thanks,
Pierre

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

From: Pierre Langlois <pierre.langlois <at> gmx.com>
To: 36614-done <at> debbugs.gnu.org
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#36614: Acknowledgement (rust <at> 1.36's hash is incorrect.)
Date: Fri, 12 Jul 2019 14:11:37 +0100

Thanks Tobias for fixing this!

Pierre

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

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

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

Pierre, Ivan,

Pierre Langlois wrote:
> From 
> https://static.rust-lang.org/dist/rustc-1.36.0-src.tar.gz...
> downloading from 
> https://static.rust-lang.org/dist/rustc-1.36.0-src.tar.gz...
>  rustc-1.36.0-src.tar.gz  147.5MiB 
>  1.6MiB/s 01:35 [##################] 100.0%
> sha256 hash mismatch for 
> /gnu/store/jm9xvf6qy4zxkb7rkmpz8ygf55l8v8v5-rustc-1.36.0-src.tar.gz:
>   expected hash: 
>   18r688ih4xi9m8gv55g1amb8inrwkdxp5fbcqb6i4gqxi90l3i0m
>   actual hash: 
>   06xv2p6zq03lidr0yaf029ii8wnjjqa894nkmrm6s0rx47by9i04

I get that too.

> Hopefully it's not unstable :-/.

Since release archives are signed that would imply some horrible 
things about their key management, so I doubt it very much.  I 
guess we'll find out.

I've gone ahead and pushed a fix since the signature checked out. 
I'm closing this bug for now...

However, I'd be interested to know what the previous hash 
described.  Do you still have that file around, Ivan?

Thanks,

T G-R

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

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

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

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

> On Jul 12, 2019, at 6:16 AM, Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:
> 
> Since release archives are signed that would imply some horrible things about their key management, so I doubt it very much.  I guess we'll find out.
> 
> I've gone ahead and pushed a fix since the signature checked out. I'm closing this bug for now...
> 
> However, I'd be interested to know what the previous hash described.  Do you still have that file around, Ivan?

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.

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

—Ivan

[rust-src.diff (application/octet-stream, attachment)]

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

From: Leo Famulari <leo <at> famulari.name>
To: Ivan Petkov <ivanppetkov <at> gmail.com>
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, 36614-done <at> debbugs.gnu.org
Subject: Re: bug#36614: rust <at> 1.36's hash is incorrect.
Date: Fri, 12 Jul 2019 13:23:50 -0400

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

On Fri, Jul 12, 2019 at 09:33:50AM -0700, Ivan Petkov wrote:
> 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.
> 
> 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).

Right, Guix looks up the sources locally by hash. So, if you change a
URL but not the hash, and you have the old file with the same hash in
/gnu/store, Guix will use the old file and you will not notice that the
URL / hash pair is incorrect.

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

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)]

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

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

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

Ivan,

On Jul 12, 2019, at 6:16 AM, Tobias Geerinckx-Rice <me <at> tobias.gr> 
wrote:
> I've gone ahead and pushed a fix since the signature checked 
> out. I'm closing this bug for now...

Unfortunately, the build still fails for me.  See below.

Kind regards,

T G-R

--8<---------------cut here---------------start------------->8---
   | 
   ||________________________________________________________________________- 
   in this macro invocation (#5)
4   |   |      types {
...     |
7   | / |      impl_error_chain_processed ! {
8   | | |      types { $ error_name , $ error_kind_name , $ 
result_ext_name ; } $ ( $ rest )
9   | | |      * } /// Convenient wrapper around `std::Result`.
   | |_|________- in this macro invocation (#6)
...     |
91  |   |      ( ref foreign_err ) => { foreign_err . cause (  ) } 
) * _ => None } } } } }
   |   |                                             ^^^^^
...     |
154 |   |      move || { $ crate :: ChainedError :: from_kind ( 
callback (  ) . into (  ) ) }
155 |   |      ) } } } ;
   |   |              -
   |   |              |
   |   |              in this expansion of 
   `impl_error_chain_processed!` (#4)
   |   |______________in this expansion of 
   `impl_error_chain_processed!` (#5)
   |                  in this expansion of 
   `impl_error_chain_processed!` (#6)
   | 
  ::: <::error_chain::error_chain::error_chain macros>:1:1
   |
1   |        / ( $ ( $ block_name : ident { $ ( $ block_content : 
tt ) * } ) * ) => {
2   |        | error_chain_processing ! {
   |  ______|_-
3   | |      | ( {  } , {  } , {  } , {  } ) $ ( $ block_name { $ 
( $ block_content ) * } ) *
4   | |      | } } ;
   | |      |_-___- in this expansion of `error_chain!` (#1)
   | |________|
   |          in this macro invocation (#2)
   | 
  ::: src/tools/rust-installer/src/lib.rs:21:5
   |
21  | /            error_chain!{
22  | |                foreign_links {
23  | |                    Io(::std::io::Error);
24  | | 
StripPrefix(::std::path::StripPrefixError);
25  | |                    WalkDir(::walkdir::Error);
26  | |                }
27  | |            }
   | |____________- in this macro invocation (#1)

   Finished release [optimized] target(s) in 1m 36s
Error: failed to generate installer
Caused by: failed to copy 
'/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist/rust-docs-1.36.0-x86_64-unknown-linux-gnu-image/share/doc/rust/html/unstable-book/library-features/weak-counts.html' 
to 
'/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist/rust-docs-1.36.0-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html/unstable-book/library-features/weak-counts.html'
Caused by: No space left on device (os error 28)


command did not execute successfully: 
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/fabricate" 
"generate" "--product-name=Rust-Documentation" 
"--rel-manifest-dir=rustlib" 
"--success-message=Rust-documentation-is-installed." "--image-dir" 
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist/rust-docs-1.36.0-x86_64-unknown-linux-gnu-image" 
"--work-dir" 
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist" 
"--output-dir" 
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/dist" 
"--package-name=rust-docs-1.36.0-x86_64-unknown-linux-gnu" 
"--component-name=rust-docs" 
"--legacy-manifest-dirs=rustlib,cargo" 
"--bulk-dirs=share/doc/rust/html"
expected success, got: exit code: 1


failed to run: 
/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/bootstrap/debug/bootstrap 
install
Build completed unsuccessfully in 0:01:54
Backtrace:
          5 (primitive-load 
          "/gnu/store/n6nh9mqsd8grd10f532z8nswnlj…")
In ice-9/eval.scm:
  191:35  4 (_ _)
In srfi/srfi-1.scm:
  863:16  3 (every1 #<procedure a6c980 at 
  /gnu/store/cmlwy3sxnq9yf…> …)
In 
/gnu/store/cmlwy3sxnq9yfp75w80par5imvyg143f-module-import/guix/build/gnu-build-system.scm:
  799:28  2 (_ _)
In ice-9/eval.scm:
   619:8  1 (_ #(#(#<directory (guile-user) 5ce140>) (("o…" . #) 
   …)))
In 
/gnu/store/cmlwy3sxnq9yfp75w80par5imvyg143f-module-import/guix/build/utils.scm:
   616:6  0 (invoke _ . _)

/gnu/store/cmlwy3sxnq9yfp75w80par5imvyg143f-module-import/guix/build/utils.scm:616:6: 
In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error 
[program: "./x.py" arguments: ("install") exit-status: 1 
term-signal: #f stop-signal: #f] 9f04c0>)'.
note: build failure may have been caused by lack of free disk 
space
builder for 
`/gnu/store/cknk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv' 
failed with exit code 1
build of 
/gnu/store/cknk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv failed
View build log at 
'/var/log/guix/drvs/ck/nk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv.bz2'.
guix build: error: build of 
`/gnu/store/cknk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv' 
failed
~/guix ⑂nckx-master✱ λ 
--8<---------------cut here---------------end--------------->8---

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

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

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

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

Tobias Geerinckx-Rice wrote:
> Caused by: No space left on device (os error 28)

Eh, never mind, I managed to copy, paste, & send an entire e-mail 
while missing this line.

👍,

T G-R

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

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

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

> On Jul 12, 2019, at 10:26 AM, Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:
> 
> 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,

This is a wonderful explanation, thanks! Will keep this in mind for the future :)

—Ivan

Previous Next

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