GNU bug report logs - #36443
Canonicalized build directory name in container leads to confusion

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Robert Vollmert <rob <at> vllmrt.net>
Subject: bug#36443: closed (Re: bug#36443: Canonicalized build directory
 name in container leads to confusion (was guix build mixes build dirs?))
Date: Thu, 04 Jul 2019 15:13:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#36443: Canonicalized build directory name in container leads to confusion

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 36443 <at> debbugs.gnu.org.

-- 
36443: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36443
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: Mark H Weaver <mhw <at> netris.org>, 36443-done <at> debbugs.gnu.org
Subject: Re: bug#36443: Canonicalized build directory name in container leads
 to confusion (was guix build mixes build dirs?)
Date: Thu, 04 Jul 2019 17:12:32 +0200

Hello,

Robert Vollmert <rob <at> vllmrt.net> skribis:

>> On 4. Jul 2019, at 09:59, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> 
>> Hi,
>> 
>> “Impossible” is an exaggeration, but when you source the
>> ‘environment-variables’ file, for example, PWD and other variables will
>> refer to /tmp/guix-build-….drv, which won’t exist.  Likewise, generated
>> files such as Makefiles would have captured the ….drv name.
>
> But, wait, won’t they refer to /tmp/guix-build-0.drv? So debugging a build
> from /tmp/guix-build-1.drv will use a mix of both directories?

As the manual explains, the name inside the container is fixed, it’s
always .drv-0; the name outside may vary to avoid naming collisions or
as a consequence of setting TMPDIR.

>> Like Mark writes, it’s not the end of the world: you can simply rename
>> /tmp/guix-build-….drv-0 to /tmp/guix-build-….drv.  However, it means
>> that things would be inconvenient by default, which doesn’t sound great
>> to me.
>> 
>> WDYT?
>
> I don't particularly care anymore. I think it’s a confusing mess, but for
> myself I’ve learnt this wart and won’t run into the problem anymore.

I understand this has been a confusing experience, but I can’t really
think of any other sensible way to approach it.

Anyway, closing it now.  Thank you!

Ludo’.

[Message part 3 (message/rfc822, inline)]

From: Robert Vollmert <rob <at> vllmrt.net>
To: bug-guix <at> gnu.org
Subject: guix build mixes build dirs?
Date: Sun, 30 Jun 2019 12:24:16 +0200

So this is pretty bizarre, and I haven’t managed to cut it down
to a smaller example yet, but it seems pretty clear that something
is broken:

$ guix build -K some-package
-> error, referencing /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0
note: keeping build directory `/tmp/guix-build-puzzledb-frontend-20190625-git.drv-0’
$ guix build -K some-package
-> same error, again referencing /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0
note: keeping build directory `/tmp/guix-build-puzzledb-frontend-20190625-git.drv-1’

My concrete packaging setup is a bit more complicated. I’m working with elm, and
faking the build directory as the home directory. The error message mentioned above
is

> The binary data at
> /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0/.elm/0.19.0/package/versions.dat
> is corrupt.

Elm caches build artifacts in the following directories:

    /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0/.elm
    elm-stuff/

while the package definition uses the trivial build system as such:

    (arguments
     `(#:modules ((guix build utils) (build-elm) (json parser) (versions))
       #:builder
         (begin
             …
             (setenv "HOME" (getcwd))
             (setenv "HTTP_PROXY" ".”) ; break http access
             (copy-recursively (assoc-ref %build-inputs "source") "src")
             (with-directory-excursion “src"
               …
               (invoke elm "make" "--output=../all.js" "src/All.elm”)))

The path in the error above comes from $HOME — is there a chance that this gets saved
somewhere? Other parts of the build script appear to work with the -1 directory as
expected.

I’m not at all sure that my package definition is even close to correct, but as far
as I can tell, a mix-up as above should be impossible.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.