all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Leo Famulari <leo@famulari.name>
Cc: 35603-done@debbugs.gnu.org
Subject: bug#35603: Go build system mishandles repetitive import paths (was [PATCH] build: go-build-system: Ensure uniform unpacking directory.)
Date: Mon, 06 May 2019 21:10:21 -0400	[thread overview]
Message-ID: <87a7fzcbnm.fsf@gmail.com> (raw)
In-Reply-To: <20190506154249.GA9060@jasmine.lan> (Leo Famulari's message of "Mon, 6 May 2019 11:42:49 -0400")

Hello Leo,

Leo Famulari <leo@famulari.name> writes:

> On Sun, Apr 14, 2019 at 12:03:05AM -0400, Maxim Cournoyer wrote:
>> From 1f7535fbe28f7ac96e824b792e9f1a140b8c54cd Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> Date: Fri, 5 Apr 2019 00:00:08 -0400
>> Subject: [PATCH 3/3] build: go-build-system: Ensure uniform unpacking
>>  directory.
>>
>> Depending on whether the source is a directory or an archive, we strip the
>> source directory or preserve it, respectively.  This change makes it so that
>> whether the type of the source, it is unpacked at the expected location given
>> by the IMPORT-PATH of the Go build system.
>>
>> * guix/build/go-build-system.scm: Add the (ice-9 ftw) module.
>> (unpack): Add inner procedure to maybe strip the top level directory of an
>> archive, document it and use it.
>
> This commit (or patch series) broke the build of Syncthing and maybe
> others.

Thanks for the heads-up!

> It seems like the the new unpacking code is stripping duplicate
> directory names?
>

It does as documented in the docstring of the unpack phase:

   If the SOURCE archive has a single top level directory,
   it is stripped so that the sources appear directly under UNPACK-PATH.

This behavior was made possible with commit
f42e4ebb56fe4f16991ca6c6e060c8f3535865cb, that made it so that:

    [...] whether the type of the source, it is unpacked at the expected
    location given by the IMPORT-PATH of the Go build system.

> It fails like this:
>
> ------
> starting phase `increase-test-timeout'
> Backtrace:
>            6 (primitive-load "/gnu/store/yfvy06fscz726da5wjvh9jxjsah…")
> In ice-9/eval.scm:
>    191:35  5 (_ _)
> In srfi/srfi-1.scm:
>    863:16  4 (every1 #<procedure 870540 at /gnu/store/zmc0hcmdfg5n4…> …)
> In /gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/gnu-build-system.scm:
>    799:28  3 (_ _)
> In ice-9/eval.scm:
>     619:8  2 (_ #(#(#<directory (guile-user) 5ce140>) (#:inputs # …)))
> In /gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:
>    635:19  1 (with-atomic-file-replacement "src/github.com/syncthin…" …)
> In unknown file:
>            0 (mkstemp! "src/github.com/syncthing/syncthing/build.go…" …)
>
> ERROR: In procedure mkstemp!:
> In procedure mkstemp!: No such file or directory
> ------
>
> And indeed, if you keep the failed build directory, you will see that
> the path 'src/github.com/syncthing/syncthing' does not exist, even
> though this corresponds to the Go import path specified in the package
> definition.
>
> Instead it is like src/github.com/syncthing' which is incorrect.

The fix was to drop the "unpack-pack" argument of the go-build-system for
syncthing, which means we want the sources unpacked at the location
specified by the "import-path".

Done with commit d879fd80c74371120a2cfa30e18a2e28dc02d31d; closing.

Thank you!

Maxim

      parent reply	other threads:[~2019-05-07  1:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-14  4:03 [bug#35263] [PATCH] build: go-build-system: Ensure uniform unpacking directory Maxim Cournoyer
2019-05-06  0:10 ` Maxim Cournoyer
2019-05-06 15:42 ` bug#35603: Go build system mishandles repetitive import paths (was [PATCH] build: go-build-system: Ensure uniform unpacking directory.) Leo Famulari
2019-05-06 15:56   ` bug#35603: Go build system mishandles repetitive import paths Leo Famulari
2019-05-07  2:42     ` Maxim Cournoyer
2019-05-07  1:10   ` Maxim Cournoyer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7fzcbnm.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=35603-done@debbugs.gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.