unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Björn Höfling" <bjoern.hoefling@bjoernhoefling.de>
To: Leo Famulari <leo@famulari.name>
Cc: 33419@debbugs.gnu.org
Subject: bug#33419: guix package is not showing that the checksum is mismatching
Date: Mon, 19 Nov 2018 10:13:10 +0100	[thread overview]
Message-ID: <20181119101310.1f42d7e2@alma-ubu> (raw)
In-Reply-To: <20181118225948.GC25252@jasmine.lan>

[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

Hi Leo,

On Sun, 18 Nov 2018 17:59:48 -0500
Leo Famulari <leo@famulari.name> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2018-11-19  9:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-18 14:04 bug#33419: guix package is not showing that the checksum is mismatching Björn Höfling
2018-11-18 22:59 ` Leo Famulari
2018-11-19  9:13   ` Björn Höfling [this message]
2018-11-19 20:30 ` Ludovic Courtès
2018-11-21 20:18   ` Björn Höfling
2018-11-21 22:16     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181119101310.1f42d7e2@alma-ubu \
    --to=bjoern.hoefling@bjoernhoefling.de \
    --cc=33419@debbugs.gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).