GNU bug report logs -
#36443
Canonicalized build directory name in container leads to confusion
Previous Next
Reported by: Robert Vollmert <rob <at> vllmrt.net>
Date: Sun, 30 Jun 2019 10:25:02 UTC
Severity: normal
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 04 Jul 2019 17:12:32 +0200
with message-id <87bly93kbj.fsf <at> gnu.org>
and subject line Re: bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)
has caused the debbugs.gnu.org bug report #36443,
regarding Canonicalized build directory name in container leads to confusion
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> 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)]
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.
[Message part 3 (message/rfc822, inline)]
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’.
This bug report was last modified 5 years and 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.