bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33419: guix package is not showing that the checksum is mismatching


From: Björn Höfling
Subject: bug#33419: guix package is not showing that the checksum is mismatching
Date: Mon, 19 Nov 2018 10:13:10 +0100

Hi Leo,

On Sun, 18 Nov 2018 17:59:48 -0500
Leo Famulari <address@hidden> wrote:

> On Sun, Nov 18, 2018 at 03:04:33PM +0100, Björn Höfling wrote:
> > I updated a package-definition and forgot to update the Checksum.
> > When then updating, it just fails, and the new, nice,
> > logging-reduced UI doesn't tell:  
> 
> Yes, this is a classic "gotcha" of Guix package development.
> 
> In Guix, those "things" for which you provide a hash are called
> "fixed-output derivations":
> 
> https://www.gnu.org/software/guix/manual/en/html_node/Derivations.html
> 
> Unlike regular derivations, we know in advance what the output of the
> derivation will be. Therefore, it does not matter to us how it is
> built (from source, downloaded over HTTP, downloaded with Git, found
> in /gnu/store, etc).
> 
> When building fixed-output derivations, Guix first looks in /gnu/store
> to see if they are already built. If so, it just uses what it finds
> there.
> 
> So, if you give the wrong hash, as you did in your example, Guix will
> use that wrong source code.
> 
> This failure mode is often discovered by people who used `guix
> download` to calculate a source hash, but then put the wrong URI in
> their package definition. Because the source is already
> in /gnu/store, the URI is not tested and their package doesn't work
> for anybody else.
> 
> It may also happen when the source is only found on the
> content-addressed mirrors provided by Nix; no file-name checking is
> performed in that case.
> 
> > $ guix package -u guix-tools
> > substitute: updating list of substitutes from
> > 'https://berlin.guixsd.org'...   0 [..]
> > building 
> > /gnu/store/vy3s1y7bv1w6d8gmp5b10xppy9skbgkd-guix-tools-0.1.0-2.4f17b79-checkout.drv...
> > build
> > of 
> > /gnu/store/vy3s1y7bv1w6d8gmp5b10xppy9skbgkd-guix-tools-0.1.0-2.4f17b79-checkout.drv
> > failed View build log at
> > '/var/log/guix/drvs/vy/3s1y7bv1w6d8gmp5b10xppy9skbgkd-guix-tools-0.1.0-2.4f17b79-checkout.drv.bz2'.
> > -guix package: error: build failed: build of
> > `/gnu/store/iwma3gq778n32mqz6y7277g67nvx1abb-guix-tools-0.1.0-2.4f17b79.drv'
> > failed  
> 
> [...]
> 
> > Only when I explicitly built it, the error was shown:
> > 
> > $ guix build guix-tools
> > 
> > HEAD is now at 4f17b79 gdev: Add more package to environment.
> > environment variable `PATH' unset
> > output path
> > `/gnu/store/s399g9f1k19v01rs992w5dl6aif87har-guix-tools-0.1.0-2.4f17b79-checkout'
> > should have r:sha256 hash
> > `1j4q43hk7jrys7zsmws37g6w7babzshfdb1s5myl7qwr3mcx6hnf', instead has
> > `0b61q29915b4i6adidx3zixnx3m0zp58rjbfa9byqcz13szznc52' build
> > of 
> > /gnu/store/vy3s1y7bv1w6d8gmp5b10xppy9skbgkd-guix-tools-0.1.0-2.4f17b79-checkout.drv
> > failed View build log at
> > '/var/log/guix/drvs/vy/3s1y7bv1w6d8gmp5b10xppy9skbgkd-guix-tools-0.1.0-2.4f17b79-checkout.drv.bz2'.
> > cannot build derivation
> > `/gnu/store/iwma3gq778n32mqz6y7277g67nvx1abb-guix-tools-0.1.0-2.4f17b79.drv':
> > 1 dependencies couldn't be built guix build: error: build failed:
> > build of
> > `/gnu/store/iwma3gq778n32mqz6y7277g67nvx1abb-guix-tools-0.1.0-2.4f17b79.drv'
> > failed
> > 
> > Is it intended that this build-failure detail is not shown? I
> > suppose not. At least in a log it should be shown.  
> 
> I agree that `guix package` should print the relevant error.


thank you very much for your lengthy explanations. I'm just no longer
sure we talk about the same problem :-) 

What you described is the fact that somethings wrong in the URL from
beginning but someone seeded the store with 'guix download'. Or the URL
404s out but the sources are all available in the
Content-Addressed-Network. Then Guix  still downloads it by hash
(though it is not locally searching in the store by hash, cmp this bug
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32245).

But that's not what I was referring to here: My point was:
"guix build" failed, and it was failing because the hash of the (then
newly downloaded) sources did not match the expected ones. And "guix
build" is saying so in its output.

But: A "guix package" (with -u or -i) is of cause also failing. But it
hides the cause. And that is nice, the new UI is meant to hide all
those details and backtraces from the user. It refers to the log for
those details. But in the referenced log you cannot find the cause
either. It is not fully equivalent with the "guix build" logs.

Does that make sense?

Björn



Attachment: pgpf4PqE6yvQE.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]