All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Stewart <christian@paral.in>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/go: bump to version 1.12
Date: Sun, 10 Mar 2019 01:23:36 -0800	[thread overview]
Message-ID: <87sgvvccbr.fsf@paral.in> (raw)
In-Reply-To: <CA+_SqVbzRuEgvansndPeSVqOeratEK5aGc+OGTc0e6j0FeJEkw@mail.gmail.com>

Hi all,

Angelo Compagnucci <angelo@amarulasolutions.com> writes:
>> On Mon, Feb 25, 2019 at 11:24 PM Thomas Petazzoni
>> <thomas.petazzoni@bootlin.com> wrote:
>> > I am puzzled by your statement "currently undefined". Is it undefined
>> > in the sense "it is not defined yet how Buildroot will handle this" or
>> > "it is not defined in Go yet how the module compilation will work in
>> > 1.13" ?
>
> It's less of a problem with module support for go now, because the
> dependencies are proxyed and verified before being delivered to the go
> download mechanism, so the reproducibility is somewhat guaranteed.
> The problem remains for breaking the buildroot internal download
> mechanism and for not a so probably clear licensing of downloaded
> modules (I have to investigate this).

I'm beginning to work on this now, would it be acceptable if Buildroot
adopted the following approach:

 - Remove GOPATH
 - Configure Go to download module files to buildroot/dl/go-modules
 - Set GOPROXY to allow network during download step only.
 - Require go.mod and go.sum hashes for all Go packages.
 - During extract step, run "go mod vendor" to extract code to build/
 - Use vendored building mode "-mod=vendor"

This should allow Go to download and verify modules correctly during the
download step, to the Buildroot dl/ tree, as well as disallowing network
fetching during the build phase, and extracting versioned module code to
the build directory.

Best,
Christian

  reply	other threads:[~2019-03-10  9:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26  3:45 [Buildroot] [PATCH 1/1] package/go: bump to version 1.12 Christian Stewart
2019-02-26  7:24 ` Thomas Petazzoni
2019-02-26  7:46   ` Christian Stewart
2019-02-26  7:53     ` Angelo Compagnucci
2019-03-10  9:23       ` Christian Stewart [this message]
2019-03-10 10:28         ` Yann E. MORIN
2019-03-11  0:08           ` Christian Stewart
2019-03-11 23:50             ` Arnout Vandecappelle
2019-03-12  3:35               ` Christian Stewart
2019-03-12  9:28                 ` Arnout Vandecappelle

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=87sgvvccbr.fsf@paral.in \
    --to=christian@paral.in \
    --cc=buildroot@busybox.net \
    /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.
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.