Preparing for Go 1.5

[Michael Hudson-Doyle]

On 5 August 2015 at 14:40, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> An update.
>
> On 31 July 2015 at 09:39, Michael Hudson-Doyle
> <michael.hudson at canonical.com> wrote:
>> Hi everyone,
>>
>> Go 1.5 will be released soon (target is actually August 1 but that's
>> not going to be hit). I've been doing some testing to see what will
>> break when we upload it.
>
> Still no rc, so probably no 1.5 release for at least a week, maybe two.

The rc is out now, and the release is scheduled for August 20th:
feature freeze day for wily!

The plan is to upload 1.5rc1 "soon": hopefully on Monday 17th, and 1.5
final soon after it is released.

>> I have a PPA at
>> https://launchpad.net/~mwhudson/+archive/ubuntu/go1.5-rebuild-tests/+packages
>> which contains a Go 1.5 snapshot package and all things that
>> build-depend on golang-go.
>
> I now have another PPA at
> https://launchpad.net/~mwhudson/+archive/ubuntu/go1.5-arch-tests/+packages
> that contains an golang-go snapshot which ...
>
>> As a bit of background, there is a hack in the Ubuntu packaging that
>> means that packages are magically built with gccgo on arm64, ppc64le
>> and powerpc ("gccgo platforms"). Go 1.5 actually supports arm64 and
>> ppc64le but I'm not testing that yet.
>
> ... does build 'real go' for arm64 and ppc64el.

The current plan is to build golang-go for arm64 and ppc64el, although
this is not set in stone: if you know of a reason why we shouldn't do
it for one or both of these platforms, let's talk.

>> There are a few packages that fail to build on gccgo platforms but
>> build fine with Go 1.5: account-polld, ciborium, golang-goyaml,
>> golang-log4go. As the situation is not changed by uploading a Go 1.5
>> snapshot, this doesn't require action.
>
> golang-goyaml and golang-log4go now build on arm64 and ppc64el.
> account-polld does not and ciborium builds on arm64 only. As this is a
> net improvement, I don't see any reason here to not enable 'real go'
> for arm64 and ppc64el. There is one package that builds with gccgo but
> not golang-go on ppc64el: lxd. We can fix that by tweaking the
> packaging to depend on gccgo and not golang-go on ppc64el (the problem
> is known and I'll fix it for Go 1.6).
>
>> Some binaries have moved from golang-go.tools to golang-go in this
>> release (cover, vet). This means that the golang-go 1.5 package needs
>> to Breaks/Replaces with the older go tools and we should upload a new
>> go.tools at the same time as the golang-go package. There are two
>> packages that build depend on go.tools and so failed in my builds
>> (aptly and unity-scope-snappy); these pass with the updated go.tools
>> but as they only build depend on go.tools to get access to cover, the
>> build-dep can be dropped once 1.5 has been uploaded. The newer
>> go.tools package depends on a newer dh-golang -- I haven't done a full
>> rebuild test with the newer tools/dh-golang packages yet.
>
> My new ppa gets this stuff right -- there is an updated go tools
> package that works with Go 1.5 and the golang-go package
> breaks/replaces old go tools.
>
> Rebuilding everything with the new dh-golang threw up one new failure
> in ubuntu-snappy
> (https://bugs.launchpad.net/ubuntu/+source/ubuntu-snappy/+bug/1481120).

This problem got fixed again in dh-golang.

>> There are a few packages that ftbfs in the archive already:
>> golang-doozer, golang-github-glacjay-goini, golang-gocheck, and
>> ubuntu-push. Of these only golang-gocheck has non-trivial rdepends and
>> the fix for these is to move upstream to golang-check.v1 (I haven't
>> looked into pushing upstreams into doing this yet). ubuntu-push is
>> seeded so probably should be fixed ASAP by upstream
>> (https://bugs.launchpad.net/ubuntu-push/+bug/1478741) but that's not
>> directly relevant to the 1.5 transition.
>
> ubuntu-push has been fixed to build with Go 1.4 now, but still fails
> with Go 1.5.

I have a branch that fixes ubuntu-push but it's a bit messy. Really
hoping upstream can handle this.

> A new failure caused by changes in Go 1.5 since the last snapshot is
> docker.io (https://github.com/docker/docker/issues/15279).

This is fixed upstream now, and we should backport the fix to
whichever version we have in wily by the time we do the upload.

Cheers,
mwh