Subject: bug#36443: closed (Re: bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?))

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 04 Jul 2019 15:13:02 +0000

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 [email-masked].

-- 
36443: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36443
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)
From: Ludovic Courtès <[email-masked]>
To: Robert Vollmert <[email-masked]>
Cc: Mark H Weaver <[email-masked]>, [email-masked]
Date: Thu, 04 Jul 2019 17:12:32 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

Robert Vollmert <[email-masked]> skribis:

>> On 4. Jul 2019, at 09:59, Ludovic Courtès <[email-masked]> 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’.

Subject: guix build mixes build dirs?
From: Robert Vollmert <[email-masked]>
To: [email-masked]
Date: Sun, 30 Jun 2019 12:24:16 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.