guix fails to find and use some available substitutes

  • Done
  • quality assurance status badge
Details
3 participants
  • Julien Lepiller
  • Ludovic Courtès
  • George Clemmer
Owner
unassigned
Submitted by
George Clemmer
Severity
normal
G
G
George Clemmer wrote on 5 Nov 2018 02:09
(name . Bug Guix)(address . bug-guix@gnu.org)(name . Chris Marusich)(address . cmmarusich@gmail.com)
cuco9b449ej.fsf@gmail.com
I run 'guix system vm-image' VMs on a GuixSD server (hostname g1). The
VMs are configured to get substitutes from g1 in addition to the
official Guix servers.

This works great except that the VMs are failing to find/use some of the
substitutes that are available on g1. E.g., in the attached log
(setup.log.gz) of the first 'guix package' issued on VM sysi58, curl is
built ...

building /gnu/store/24ag580271wa640529ycykdwj0lk0g6z-curl-7.61.1.tar.xz.drv...
building /gnu/store/17lw3svpjqygpj739yynyz6b8abddikx-curl-7.61.1.drv...

... when the substitute is available in the g1 store ...

/gnu/store:
-r--r--r-- 2 root root 3747 Dec 31 1969
17lw3svpjqygpj739yynyz6b8abddikx-curl-7.61.1.drv

This is "infrequent", in the sense that a high percentabe of the
substitutes available from g1 are being found and used. However, these
other packages for which substitutes are available on g1 are also built:

downloading from ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz...

Details:

Using Guix from Git:

Server g1: sys.scm v0.15.0-2913-g21c51ebd6

VM sysi58: sysi58.scm v0.15.0-3115-g7571ec357

TIA - George
Attachment: sysi58.scm
Attachment: sys.scm
Attachment: setup.log.gz
G
G
George Clemmer wrote on 5 Nov 2018 02:29
(address . 33262@debbugs.gnu.org)
cucy3a8xqg3.fsf@gmail.com
Oops, the server config attached to the previous email is incorrect,
sorry. Here is the correct one:
Attachment: sys.scm
J
J
Julien Lepiller wrote on 5 Nov 2018 09:26
5C395E1E-9E2B-4696-8FC8-9EA4046A20C3@lepiller.eu
I think guix' message is a bit confusing: the .drv file is always created by guix, it's the derivation. The derivation is built, which results in a new store path. It can be built locally or by using a substitute. What you see in your store is the derivation (.drv), not its result. You can open that file to find where the result will be stored and check if it exists on your machine.

Le 5 novembre 2018 02:09:56 GMT+01:00, George Clemmer <myglc2@gmail.com> a écrit :
Toggle quote (50 lines)
>I run 'guix system vm-image' VMs on a GuixSD server (hostname g1). The
>VMs are configured to get substitutes from g1 in addition to the
>official Guix servers.
>
>This works great except that the VMs are failing to find/use some of
>the
>substitutes that are available on g1. E.g., in the attached log
>(setup.log.gz) of the first 'guix package' issued on VM sysi58, curl is
>built ...
>
>building
>/gnu/store/24ag580271wa640529ycykdwj0lk0g6z-curl-7.61.1.tar.xz.drv...
>downloading from https://curl.haxx.se/download/curl-7.61.1.tar.xz...
>building /gnu/store/17lw3svpjqygpj739yynyz6b8abddikx-curl-7.61.1.drv...
>
>... when the substitute is available in the g1 store ...
>
> /gnu/store:
> -r--r--r-- 2 root root 3747 Dec 31 1969
> 17lw3svpjqygpj739yynyz6b8abddikx-curl-7.61.1.drv
>
>This is "infrequent", in the sense that a high percentabe of the
>substitutes available from g1 are being found and used. However, these
>other packages for which substitutes are available on g1 are also
>built:
>
>downloading from ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz...
>downloading from http://download.osgeo.org/libtiff/tiff-4.0.9.tar.gz...
>downloading from
>https://ftpmirror.gnu.org/gnu/groff/groff-1.22.3.tar.gz...
>downloading from
>https://github.com/apple/cups/releases/download/v2.2.8/cups-2.2.8-source.tar.gz...
>downloading from
>https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs924/ghostscript-9.24.tar.xz...
>downloading from
>https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2...
>downloading from
>http://www.x.org/releases/individual/lib/libX11-1.6.6.tar.bz2...
>downloading from
>http://www.x.org/releases/individual/lib/xtrans-1.3.5.tar.bz2...
>
>Details:
>
>Using Guix from Git:
>
>Server g1: sys.scm v0.15.0-2913-g21c51ebd6
>
>VM sysi58: sysi58.scm v0.15.0-3115-g7571ec357
>
>TIA - George
G
G
George Clemmer wrote on 5 Nov 2018 18:21
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 33262@debbugs.gnu.org)
cucpnvj4ez2.fsf@gmail.com
Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (7 lines)
> I think guix' message is a bit confusing: the .drv file is always
> created by guix, it's the derivation. The derivation is built, which
> results in a new store path. It can be built locally or by using a
> substitute. What you see in your store is the derivation (.drv), not
> its result. You can open that file to find where the result will be
> stored and check if it exists on your machine.

Hi Julien,

Thank you. You are right, the .drv "out" substitute is not on my
local server. So this is not a bug. SORRY for the noise ;-)

After re-reading (guix) Derivations, I see I had a wrong impression:
that the presence of a .drv indicates a successful build. But AIUI now
it only means that at some point in the past we attempted to build the
.drv. IOW, we will also have .drv files for all failed builds.

Is that correct?

Thanks! - George
J
J
Julien Lepiller wrote on 5 Nov 2018 19:45
(name . George Clemmer)(address . myglc2@gmail.com)(address . 33262@debbugs.gnu.org)
D79A075E-AB72-498C-8DFB-9BCD6B7F2C32@lepiller.eu
Exactly!

Le 5 novembre 2018 18:21:53 GMT+01:00, George Clemmer <myglc2@gmail.com> a écrit :
Toggle quote (23 lines)
>
>Julien Lepiller <julien@lepiller.eu> writes:
>
>> I think guix' message is a bit confusing: the .drv file is always
>> created by guix, it's the derivation. The derivation is built, which
>> results in a new store path. It can be built locally or by using a
>> substitute. What you see in your store is the derivation (.drv), not
>> its result. You can open that file to find where the result will be
>> stored and check if it exists on your machine.
>
>Hi Julien,
>
>Thank you. You are right, the .drv "out" substitute is not on my
>local server. So this is not a bug. SORRY for the noise ;-)
>
>After re-reading (guix) Derivations, I see I had a wrong impression:
>that the presence of a .drv indicates a successful build. But AIUI now
>it only means that at some point in the past we attempted to build the
>.drv. IOW, we will also have .drv files for all failed builds.
>
>Is that correct?
>
>Thanks! - George
L
L
Ludovic Courtès wrote on 11 Nov 2018 18:31
control message for bug #33262
(address . control@debbugs.gnu.org)
87tvknpllh.fsf@gnu.org
tags 33262 notabug
close 33262
?