From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Vollmert Subject: bug#36443: guix build mixes build dirs? Date: Sun, 30 Jun 2019 12:24:16 +0200 Message-ID: <4C8D1EC5-8E39-4595-BFD0-0033C39C6740@vllmrt.net> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47573) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhX1A-0004xP-4f for bug-guix@gnu.org; Sun, 30 Jun 2019 06:25:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhX15-0007dy-N0 for bug-guix@gnu.org; Sun, 30 Jun 2019 06:25:08 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:60092) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhX14-0007d0-Kv for bug-guix@gnu.org; Sun, 30 Jun 2019 06:25:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hhX14-0004of-EQ for bug-guix@gnu.org; Sun, 30 Jun 2019 06:25:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:470:142:3::10]:47432) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhX0S-0004ef-VW for bug-guix@gnu.org; Sun, 30 Jun 2019 06:24:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhX0S-0006z3-1w for bug-guix@gnu.org; Sun, 30 Jun 2019 06:24:24 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:27156) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hhX0R-0006uX-RZ for bug-guix@gnu.org; Sun, 30 Jun 2019 06:24:23 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id AF70BA104B for ; Sun, 30 Jun 2019 12:24:18 +0200 (CEST) Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id TBCo7px0OAqv for ; Sun, 30 Jun 2019 12:24:17 +0200 (CEST) List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 36443@debbugs.gnu.org So this is pretty bizarre, and I haven=E2=80=99t 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=E2=80=99 $ 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=E2=80=99 My concrete packaging setup is a bit more complicated. I=E2=80=99m = 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/v= ersions.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 =E2=80=A6 (setenv "HOME" (getcwd)) (setenv "HTTP_PROXY" ".=E2=80=9D) ; break http access (copy-recursively (assoc-ref %build-inputs "source") "src") (with-directory-excursion =E2=80=9Csrc" =E2=80=A6 (invoke elm "make" "--output=3D../all.js" = "src/All.elm=E2=80=9D))) The path in the error above comes from $HOME =E2=80=94 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=E2=80=99m 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.