[1/1] package/go: bump to version 1.18

The latest Go release, version 1.18, is a significant release, including changes
to the language, implementation of the toolchain, runtime, and libraries.

https://go.dev/doc/go1.18

Signed-off-by: Christian Stewart <christian@paral.in>
---
 package/go/go.hash | 2 +-
 package/go/go.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Hi all,

On Mon, Mar 21, 2022 at 10:14 PM Christian Stewart <christian@paral.in> wrote:
>
> The latest Go release, version 1.18, is a significant release, including changes
> to the language, implementation of the toolchain, runtime, and libraries.
>
> https://go.dev/doc/go1.18
>

>  # From https://golang.org/dl/
> -sha256  2effcd898140da79a061f3784ca4f8d8b13d811fb2abe9dad2404442dabbdf7a  go1.17.8.src.tar.gz
> +sha256  38f423db4cc834883f2b52344282fa7a39fbb93650dc62a11fdf0be6409bdad6  go1.18.src.tar.gz
>  sha256  2d36597f7117c38b006835ae7f537487207d8ec407aa9d9980794b2030cbc067  LICENSE

I should note that this upgrade also will change a lot of the Go
package hashes...

Due to the way the "go mod vendor" step works, there's some
incompatibility with the go 1.17 vendor format:

go: inconsistent vendoring in /build/containerd-1.5.9:
        github.com/containerd/containerd: is marked as replaced in
vendor/modules.txt, but not replaced in go.mod

        To ignore the vendor directory, use -mod=readonly or -mod=mod.
        To sync the vendor directory, run:
                go mod vendor

We will need to update the hashes and the archives for these packages.

Unfortunately I don't know of any way to avoid this, other than
re-running "go mod vendor" if there's any conflict.

Thanks & best regards,
Christian Stewart

All,

On Mon, Mar 21, 2022 at 10:18 PM Christian Stewart <christian@paral.in> wrote:
> On Mon, Mar 21, 2022 at 10:14 PM Christian Stewart <christian@paral.in> wrote:
> >
> > The latest Go release, version 1.18, is a significant release, including changes
> > to the language, implementation of the toolchain, runtime, and libraries.
> >
> > https://go.dev/doc/go1.18

> I should note that this upgrade also will change a lot of the Go
> package hashes...
>
> Due to the way the "go mod vendor" step works, there's some
> incompatibility with the go 1.17 vendor format:
>
> go: inconsistent vendoring in /build/containerd-1.5.9:
>         github.com/containerd/containerd: is marked as replaced in
> vendor/modules.txt, but not replaced in go.mod
>
>         To ignore the vendor directory, use -mod=readonly or -mod=mod.
>         To sync the vendor directory, run:
>                 go mod vendor
>
> We will need to update the hashes and the archives for these packages.

Something weird is going on here...

https://asciinema.org/a/guJyOQeqbG5PIL1daVYQoyyef

With containerd checked out at v1.6.1 with Go 1.18,

"go mod vendor" -> "go build"

... always results in the error shown above, even after deleting the
vendor/ tree.

This issue might be one with Go 1.18 itself.

Thanks,
Christian Stewart

All,

On Mon, Mar 21, 2022 at 10:38 PM Christian Stewart <christian@paral.in> wrote:
> On Mon, Mar 21, 2022 at 10:18 PM Christian Stewart <christian@paral.in> wrote:
> > On Mon, Mar 21, 2022 at 10:14 PM Christian Stewart <christian@paral.in> wrote:
> > >
> > > The latest Go release, version 1.18, is a significant release, including changes
> > > to the language, implementation of the toolchain, runtime, and libraries.
> > >
> > > https://go.dev/doc/go1.18
>
> > I should note that this upgrade also will change a lot of the Go
> > package hashes...
> >
> > Due to the way the "go mod vendor" step works, there's some
> > incompatibility with the go 1.17 vendor format:
> >
> > go: inconsistent vendoring in /build/containerd-1.5.9:
> >         github.com/containerd/containerd: is marked as replaced in
> > vendor/modules.txt, but not replaced in go.mod
> >
> >         To ignore the vendor directory, use -mod=readonly or -mod=mod.
> >         To sync the vendor directory, run:
> >                 go mod vendor
> >
> > We will need to update the hashes and the archives for these packages.
>
> Something weird is going on here...
>
> https://asciinema.org/a/guJyOQeqbG5PIL1daVYQoyyef
>
> With containerd checked out at v1.6.1 with Go 1.18,

This was indeed an incompatibility between containerd 1.6.1 and go 1.18:

 - https://github.com/golang/go/issues/51285
 - https://github.com/containerd/containerd/pull/6605

The fix has not yet been released (for containerd).

... so we should delay updating Go to 1.18 until all the packages in
the tree support it w/ tagged releases.

Thanks & best,
Christian Stewart

On 2022-03-21 22:18 -0700, Christian Stewart spake thusly:
> On Mon, Mar 21, 2022 at 10:14 PM Christian Stewart <christian@paral.in> wrote:
> > The latest Go release, version 1.18, is a significant release, including changes
> > to the language, implementation of the toolchain, runtime, and libraries.
> I should note that this upgrade also will change a lot of the Go
> package hashes...
> 
> Due to the way the "go mod vendor" step works, there's some
> incompatibility with the go 1.17 vendor format:
> 
> go: inconsistent vendoring in /build/containerd-1.5.9:
>         github.com/containerd/containerd: is marked as replaced in
> vendor/modules.txt, but not replaced in go.mod
> 
>         To ignore the vendor directory, use -mod=readonly or -mod=mod.
>         To sync the vendor directory, run:
>                 go mod vendor
> 
> We will need to update the hashes and the archives for these packages.

This is a no-go. We can't change hashes, otherwise there will be a
conflict with the hashes of the backup download we store on
sources.buildroot.org.

Probably, the best solution forward would be to introduce a version
suffix for the post-process. I quickly hacked something around:

    diff --git a/package/pkg-download.mk b/package/pkg-download.mk
    index a15e21e110..74369fc946 100644
    --- a/package/pkg-download.mk
    +++ b/package/pkg-download.mk
    @@ -22,6 +22,7 @@ export LOCALFILES := $(call qstrip,$(BR2_LOCALFILES))
     # download backend:
     BR_FMT_VERSION_git = -br1
     BR_FMT_VERSION_svn = -br2
    +BR_FMT_POST_PROCESS_go = -brgo1
     
     DL_WRAPPER = support/download/dl-wrapper
     
    diff --git a/package/pkg-utils.mk b/package/pkg-utils.mk
    index 7d1aea7710..e317750967 100644
    --- a/package/pkg-utils.mk
    +++ b/package/pkg-utils.mk
    @@ -43,7 +43,7 @@ pkgname = $(lastword $(subst /, ,$(pkgdir)))
     # Helper to build the extension for a package archive, based on various
     # conditions.
     # $(1): upper-case package name
    -pkg_source_ext = $(BR_FMT_VERSION_$($(1)_SITE_METHOD)).tar.gz
    +pkg_source_ext = $(BR_FMT_VERSION_$($(1)_SITE_METHOD))$(BR_FMT_POST_PROCESS_$($(1)_DOWNLOAD_POST_PROCESS)).tar.gz
     
     # Define extractors for different archive suffixes
     INFLATE.bz2  = $(BZCAT)

So, basically, we would need a series that does:

 1. introduces the post-process versionning as shown above, and update
    the hashes accordingly

 2. update go to 1.18, which at the same time updates the newly
    introduced post-process versionning, and update the hashes yet
    again.

Regards,
Yann E. MORIN.

> Unfortunately I don't know of any way to avoid this, other than
> re-running "go mod vendor" if there's any conflict.
> 
> Thanks & best regards,
> Christian Stewart