guix fails to find and use some available substitutes

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

Oops, the server config attached to the previous email is incorrect,

sorry. Here is the correct one:

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 :

Julien Lepiller <julien@lepiller.eu> writes:

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

Exactly!

Le 5 novembre 2018 18:21:53 GMT+01:00, George Clemmer <myglc2@gmail.com> a écrit :

tags 33262 notabug

close 33262