failed to compute derivation

  • Done
  • quality assurance status badge
Details
2 participants
  • Marco van Hulten
  • Marius Bakke
Owner
unassigned
Submitted by
Marco van Hulten
Severity
normal
M
M
Marco van Hulten wrote on 25 May 2020 17:53
(address . bug-guix@gnu.org)
20200525175343.3bcc6d6b@hulten.org
Hi—

I did a 'guix pull && guix package -u' today, but something went wrong,
tail follows:

...
./guix/store.scm:1363:15: Throw to key `srfi-34' with args `(#<condition &store-protocol-error [message: "build of `/gnu/store/gv21jfvr92p2rqwjp7idv7q1if44q5wl-openldap-2.4.50.drv' failed" status: 100] 7f9b9a5b3e40>)'.
guix pull: error: You found a bug: the program '/gnu/store/6naagkv776pp47zk9blnnrjwhzyq5k4b-compute-guix-derivation'
failed to compute the derivation for Guix (version: "8c42a25b77e5cb8c97dacfdd552811a820d674eb"; system: "x86_64-linux";
host version: "545e12f40dcd8cfc779e8802dadead7a7cdc8364"; pull-version: 1).
Please report it by email to <bug-guix@gnu.org>.



—Marco
M
M
Marius Bakke wrote on 25 May 2020 23:54
874ks37k9d.fsf@gnu.org
Marco van Hulten <marco@hulten.org> writes:

Toggle quote (15 lines)
> Hi—
>
> I did a 'guix pull && guix package -u' today, but something went wrong,
> tail follows:
>
> ...
> ./guix/store.scm:1363:15: Throw to key `srfi-34' with args `(#<condition &store-protocol-error [message: "build of `/gnu/store/gv21jfvr92p2rqwjp7idv7q1if44q5wl-openldap-2.4.50.drv' failed" status: 100] 7f9b9a5b3e40>)'.
> guix pull: error: You found a bug: the program '/gnu/store/6naagkv776pp47zk9blnnrjwhzyq5k4b-compute-guix-derivation'
> failed to compute the derivation for Guix (version: "8c42a25b77e5cb8c97dacfdd552811a820d674eb"; system: "x86_64-linux";
> host version: "545e12f40dcd8cfc779e8802dadead7a7cdc8364"; pull-version: 1).
> Please report it by email to <bug-guix@gnu.org>.
>
>
> Longer tail: http://paste.debian.net/1148762/

One libpng test is failing. Full log included here for posterity:

Toggle snippet (39 lines)
FAIL: tests/pngtest ===================

[46/1810]
Testing libpng version 1.6.37
with zlib version 1.2.11
libpng version 1.6.37
Copyright (c) 2018-2019 Cosmin Truta
Copyright (c) 1998-2002,2004,2006-2018 Glenn Randers-Pehrson
Copyright (c) 1996-1997 Andreas Dilger
Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc.
library (10637): libpng version 1.6.37 - April 14, 2019
pngtest (10637): libpng version 1.6.37 - April 14, 2019
Testing ./pngtest.png:
Text compression[0]=-1
stereo mode = 1
vpAg = 100 x 100, units = 0
Text compression[0]=0
eXIf type MM, 52 bytes
Image width = 91, height = 69
Files ./pngtest.png and pngout.png are different
Was ./pngtest.png written with the same maximum IDAT chunk size (8192 bytes),
filtering heuristic (libpng default), compression level (zlib default),
and zlib version (1.2.11)?
FAIL
libpng FAILS test
Default limits:
width_max = 1000000
height_max = 1000000
cache_max = 1000
malloc_max = 8000000
FAIL tests/pngtest (exit status: 1)

Is this error consistent for you, or could it have been an
indeterministic failure?

Also, did you intentionally disable binary substitutes?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl7MPq4ACgkQoqBt8qM6
VPrMmAf7Bai2TShNKKnCWlgCdUiIpRyW1ZpWSwxaL/Z0/inabM8xMfsyySJwNqPT
Uk0EKnxOvVIbgYpReA06Al03jXWG5zZWTAHWemLgB9+UKNV1MKJglrDC2RSPwV19
GBjmA8eFU9lfbQ/xGlByV81DtCHaimx8/Npw90gHQm3Ch+DiBmYy9bfE/buoYgaW
PrFXd5jvq3ZkxSKf2k3Z8oeSK4Nee4fXggWv20RzA6ZZmERD0IQX0n87XUaaR1Ok
M+u7ZHsooUwxdD1iTlbwS5/eqIbNtwkjuAVGDdvt16myMUSyyBs4w7A6zlZPCE7u
nX2qA73cunq+Z7ZFC0Y5JfOmUShbRA==
=7xb2
-----END PGP SIGNATURE-----

M
M
Marco van Hulten wrote on 26 May 2020 10:13
(name . Marius Bakke)(address . marius@gnu.org)(address . 41528@debbugs.gnu.org)
20200526101327.66e5e9c7@gfi063209.klientdrift.uib.no
Marius—

On 25 May 23:54 Marius Bakke wrote:
Toggle quote (3 lines)
> Is this error consistent for you, or could it have been an
> indeterministic failure?

It happened yesterday morning and then again in the evening, so I'd
carefully suggest it is deterministic failure.

Toggle quote (2 lines)
> Also, did you intentionally disable binary substitutes?

Not that I know of (did just 'guix pull'), but I had been messing more
than a month ago with 'staging' or 'core-updates' because I wanted to
have a recent TeX Live. I remember "core-updates" being printed when
doing the 'guix pull' in question yesterday.

Tonight I may be more precise or test more when I have access to the
machine again.

—Marco
M
M
Marius Bakke wrote on 27 May 2020 00:39
(name . Marco van Hulten)(address . marco@hulten.org)(address . 41528@debbugs.gnu.org)
874ks25ni9.fsf@gnu.org
Marco van Hulten <marco@hulten.org> writes:

Toggle quote (19 lines)
> Marius—
>
> On 25 May 23:54 Marius Bakke wrote:
>> Is this error consistent for you, or could it have been an
>> indeterministic failure?
>
> It happened yesterday morning and then again in the evening, so I'd
> carefully suggest it is deterministic failure.
>
>> Also, did you intentionally disable binary substitutes?
>
> Not that I know of (did just 'guix pull'), but I had been messing more
> than a month ago with 'staging' or 'core-updates' because I wanted to
> have a recent TeX Live. I remember "core-updates" being printed when
> doing the 'guix pull' in question yesterday.
>
> Tonight I may be more precise or test more when I have access to the
> machine again.

What does 'guix describe' say?

I guess you are on a snapshot of core-updates for which substitutes are
no longer available (or never were), and Guix needs to build all the
things needed for 'guix pull' to work.

You may have earlier revisions of Guix installed that are able to 'guix
pull' without having to build the world. Check with 'guix pull -l':
the preceding revision is likely to work since it was able to pull your
current revision.

You can then try running
'/var/guix/profiles/per-user/you/current-guix-NN-link/bin/guix pull'
directly and see if the NN generation fares better. You might also be
able to use '/run/current-system/profile/bin/guix pull', or any other
guixen found in "/var/guix/profiles/system-*/profile/bin/guix".

This only papers over the fact that libpng fails to build on your
machine though. It would be good to verify whether it still fails with
'guix build --no-grafts --check libpng' once you have recovered your
Guix, and try to figure out what the problem is.

Hope this helps & good luck! :-)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl7Nmr4ACgkQoqBt8qM6
VPozRgf+PfsrwaDUwHqtzb3zJruEYTjKekwpsxa4czZWkGdrT0Yzh5TlGrZxStxl
mUkZPRJMEHXO1kGl7NPt5rm778+iUimn3JOa2muS5j1Bd9dN4peVtIqLK+/+RkS/
CRW9mkuzh+NrM13A8auEADspa4N0l3BvLNLly39ZrC6j/DoE66Rt3JaN1ky5Lttb
g/5mD1HoX9k4CkyN4BTcxkkqXL6pqcD58rB/uxp6pR2uZ3ZV8RorQCCXE2Anf5PY
hG1Dq1A4m/EU4O9QU3pQGphh9OwGTKjLm6f70jFSX9sRQihsWvqHIpe/uE0OzOM6
JX2Lb1QqaTxfHK68XIgYlHWXg4iSLQ==
=DIdt
-----END PGP SIGNATURE-----

M
M
Marco van Hulten wrote on 27 May 2020 22:11
failed to compute derivation
(address . control@debbugs.gnu.org)(name . Marius Bakke)(address . marius@gnu.org)
20200527221125.7bbc26d3@hulten.org
close 41528
stop

Thanks for the help, Marius. It was solved by

1. removing channels.scm that contained "core-updates";
2. calling 'guix pull' from a different profile (otherwise it
surprisingly still used "core-updates".

The 'guix build --no-grafts --check libpng' did not give any errors.

Cheers,

—Marco
?