I think you need to update more files than this one only, see #21978, and #21987.

Also the gccgo versions should probably be bumped then

Yep, thanks @thaJeztah!

It's green 😮

lol

@runcom will you be updating this PR with the other files to be changed as well?

Yes

@thaJeztah updated, have I updated everything now?

Hm, some more things to take into account;

The gccgo version has to be bumped (see the discussion on #22715) I already pinged @tophj-ibm @michael-holzheu there to help in getting those to the right version (and sha/hash)

Some things I'm not sure of;

Looks like there's these patches; not sure if they need to be rebased for go 1.6.2 hack/vendor.sh#L66 (https://github.com/docker/go)

Oh, and I remember @tonistiigi was doing a patch somewhere to have https://go-review.googlesource.com/#/c/21654/, but not sure if that was applied somewhere in this repository or the runc or containerd repo @tonistiigi ?

Okay, for ppc64, gccgo and s390x, looks like we need to modify things
in these areas;

ppc64le:
Dockerfile.ppc64le#L18 (but this one is funny Dockerfile.ppc64le#L90-L95)

gccgo:
Dockerfile.gccgo#L9

s390x:
Dockerfile.s390x#L18 (also Dockerfile.s390x#L99-L104)

@runcom should be safe to bump the ppc64le and gccgo dockerfiles to 6.1, there doesn't appear to be a 6.2 for gcc.

@thaJeztah for ppc64le, we have to manually make go which requires bootstrapping from go 1.4+. Because power wasn't supported in go 1.4, we have to do that from gccgo, hence the from gcc. I'm working on a pr to change this to xenial which has go for power available, but that's why that funny stuff is there 😛

@tophj-ibm fixed ppc64le, not sure what there's to do in gccgo

@runcom oh no, I meant bumping the base gcc images, because they include the gccgo versions.
Dockerfile.ppc64le#L18 to ppc64le/gcc:6.1 and Dockerfile.gccgo#L9 to gcc:6.1

seems good to me, thanks!

Thanks @tophj-ibm!

Guess we need to await input from the Windows people now (w.r.t. the 1.5.3 hack)

Nano Server TP5 is incompatible with Go 1.6.2. We have to fix that incompatibility in Windows, so until there is another release we are stuck. We could move Windows to 1.6.1 though.

Another possible workaround just occurred to me though, so give me a few hours to try it out.

I found a workaround. I can submit it as a separate PR, or you can cherry pick jstarks/docker@b7a721a as part of this.

@amitkris done - @thaJeztah @michael-holzheu not sure what's going on with notary - who can I ping for it?

ping @endophage @cyli can you have a look for the Notary problems?

@runcom @thaJeztah github.com/gorilla/context has been vendored into notary, so it should be there. I'm wondering if maybe the ln -s may be causing issues since it's actually expecting the go 1.5+ vendoring now? Does it still fail if you remove the ln -s?

Apologies, I would just test myself, but I can't seem to even build the s390x Dockerfile. I'm not sure why, but I'm getting:

...
Status: Downloaded newer image for s390x/gcc:6.1
 ---> a5f2322042ba
Step 2 : RUN apt-get update && apt-get install -y   apparmor    aufs-tools  automake    bash-completion     btrfs-toolsbuild-essential  createrepo  curl    dpkg-sig    git     iptables    jq  net-tools   libapparmor-dev     libcap-dev libltdl-dev  libsqlite3-dev  libsystemd-journal-dev  libtool     mercurial   pkg-config  python-dev  python-mock     python-pip  python-websocket    xfsprogs    tar     --no-install-recommends
 ---> Running in 0211be813cb5
Container command '/bin/sh' not found or does not exist.

ping @runcom is there anything left to be done in this PR? Do we need to revert changes for the Windows Hack, or is that taken care of?

triggered ARM and PowerPC as well, they were not running on this PR

I think we're done here afaict, I've already reverted the windows check so it should be good to go

@runcom cool. the s390x is going in a follow up?

I'm not sure what's going on there honestly - and I cannot even test it. If anyone is willing to point me in the right direction I can make the modifications needed here, otherwise, yes, I'll defer that to another PR since I have to way to try that out

@runcom sgtm; let's see if ARM and PowerPC go green, then I think we're ready 🎉

Probably safe to leave z out of this one, I know that team is testing out a gc build anyway.

This is so green 👍

Just thought of this; should we remove the GO15VENDOREXPERIMENT in the Dockerfiles as part of this PR?
https://github.com/docker/docker/search?utf8=✓&q=GO15VENDOREXPERIMENT

LGTM otherwise

@thaJeztah let's do it in separate PR
LGTM

@cyli

@runcom @thaJeztah github.com/gorilla/context has been vendored into notary, so it should be there. I'm wondering if maybe the ln -s may be causing issues since it's actually expecting the go 1.5+ vendoring now? Does it still fail if you remove the ln -s?

Looks like the softlink trick does no longer work for gcc 6.1. I also expected that with gcc 6.1 / go 1.6.1 we can remove the softlink workaround, but when I remove the softlink the build still fails. I assume gccgo has problems with vendoring? Perhaps golang/go#15814 is related?

I could compile notary when I keep the softlink and explicitly disable GO15VENDOREXPERIMENT:

diff --git a/Dockerfile.s390x b/Dockerfile.s390x
index bb7ec8b..4b8edd4 100644
--- a/Dockerfile.s390x
+++ b/Dockerfile.s390x
@@ -15,7 +15,7 @@
 # the case. Therefore, you don't have to disable it anymore.
 #

-FROM s390x/gcc:5.3
+FROM s390x/gcc:6.1

 # Packaged dependencies
 RUN apt-get update && apt-get install -y \
@@ -132,7 +132,7 @@ RUN set -x \
 # Install notary and notary-server
 ENV NOTARY_VERSION v0.3.0
 RUN set -x \
-       && export GO15VENDOREXPERIMENT=1 \
+       && export GO15VENDOREXPERIMENT=0 \
        && export GOPATH="$(mktemp -d)" \
        && git clone https://github.com/docker/notary.git "$GOPATH/src/github.com/docker/notary" \
        && (cd "$GOPATH/src/github.com/docker/notary" && git checkout -q "$NOTARY_VERSION" && ln -s . vendor/src) \
@@ -158,7 +158,7 @@ RUN useradd --create-home --gid docker unprivilegeduser

To summarize:

What about Dockerfile.gccgo on x86. Does this work with gcc 6.1?

Apologies, I would just test myself, but I can't seem to even build the s390x Dockerfile. I'm not sure why, but I'm getting:

Do you have a s390x machine for testing?

What about Dockerfile.gccgo on x86. Does this work with gcc 6.1?

Ok: Dockerfile.gccgo does not compile notary.

Thanks for figuring this out! I would have thought censoring would work
too.

And no I do not - I guess that would be why. :). I figured I'd originally
thought I'd be able to build but not run.

On Monday, May 30, 2016, Michael Holzheu notifications@github.com wrote:

@cyli https://github.com/cyli

@runcom https://github.com/runcom @thaJeztah
https://github.com/thaJeztah github.com/gorilla/context has been
vendored into notary, so it should be there. I'm wondering if maybe the ln
-s may be causing issues since it's actually expecting the go 1.5+
vendoring now? Does it still fail if you remove the ln -s?

Looks like the softlink trick does no longer work for gcc 6.1. I also
expected that with gcc 6.1 / go 1.6.1 we can remove the softlink
workaround, but when I remove the softlink the build still fails. I assume
gccgo has problems with vendoring? Perhaps golang/go#15814
golang/go#15814 is related?

I could compile notary when I keep the softlink and explicitly disable
GO15VENDOREXPERIMENT:

diff --git a/Dockerfile.s390x b/Dockerfile.s390x
index bb7ec8b..4b8edd4 100644
--- a/Dockerfile.s390x
+++ b/Dockerfile.s390x
@@ -15,7 +15,7 @@

the case. Therefore, you don't have to disable it anymore.

-FROM s390x/gcc:5.3
+FROM s390x/gcc:6.1

Packaged dependencies

RUN apt-get update && apt-get install -y
@@ -132,7 +132,7 @@ RUN set -x \

Install notary and notary-server

ENV NOTARY_VERSION v0.3.0
RUN set -x \

•   && export GO15VENDOREXPERIMENT=1 \
  

•   && export GO15VENDOREXPERIMENT=0 \
  && export GOPATH="$(mktemp -d)" \
  && git clone https://github.com/docker/notary.git "$GOPATH/src/github.com/docker/notary" \
  && (cd "$GOPATH/src/github.com/docker/notary" && git checkout -q "$NOTARY_VERSION" && ln -s . vendor/src) \
  

  @@ -158,7 +158,7 @@ RUN useradd --create-home --gid docker unprivilegeduser

To summarize:
GO15VENDOREXPERIMENT Softlink Success
1 yes no
1 no no
unset yes no
unset no no
0 yes yes
0 no no

What about Dockerfile.gcc on x86. Does this work with gcc 6.1?

Apologies, I would just test myself, but I can't seem to even build the
s390x Dockerfile. I'm not sure why, but I'm getting:

Do you have a s390x machine for testing?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#22840 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AANn4BlhRQKSgioRjDya6C8pHZ0PmkYhks5qGuAQgaJpZM4IilDZ
.

So should we update Dockerfile.s390x (with the GO15VENDOREXPERIMENT=0 workaround) and Dockerfile.gccgo to gcc6.1 to be compliant to your go 1.6 build requirement?

@michael-holzheu That would be necessary if you wanted yubikey integrations in those two distributions :) Thank you!