Preparing for Go 1.5
michael.hudson at canonical.com
Wed Aug 5 02:40:51 UTC 2015
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.
> I have a PPA at
> which contains a Go 1.5 snapshot package and all things that
> build-depend on golang-go.
I now have another PPA at
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.
> 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
> 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.
> There are two packages that have been fixed to work with Go 1.5
> upstream but the fixes are not yet packaged in Debian:
> golang-golang-x-net-dev and golang-x-text. We should wait for these to
> be packaged before uploading Go 1.5. The upstream version of
> golang-x-text works with Go 1.5 but not Go 1.4 (reported as
> https://github.com/golang/go/issues/11927) so perhaps that should be
> uploaded at the same time.
The change in Go 1.5 that caused the golang-golang-x-net-dev failure
was reverted so that builds now. No change in the golang-x-text
> There are four packages that fail with Go 1.5 and have not been fixed
> upstream: golang-github-jacobsa-ogletest, golang-protobuf-extensions,
> ubuntu-push (over and above the failures with 1.4), and ubuntu-snappy.
> I've filed bugs for all of these:
> * https://github.com/jacobsa/ogletest/issues/28
> * https://github.com/matttproud/golang_protobuf_extensions/issues/9
> * https://bugs.launchpad.net/ubuntu-push/+bug/1478742
> * https://bugs.launchpad.net/snappy/+bug/1478736
> The first two have few rdeps and IMO can be left alone for now. The
> latter two are seeded and we should wait for fixes before uploading
The change in Go 1.5 that caused the snappy failure was reverted. But
it still doesn't build because of the dh-golang thing.
A new failure caused by changes in Go 1.5 since the last snapshot is
A handful of packages that have appeared in the archive since my last
rebuild fail with Go 1.5: prometheus-pushgateway, prometheus,
golang-github-armon-go-metrics, golang-prometheus-client. I'll file
upstream bugs for these soon.
libguestfs now fails to build, but I don't think that's Go's fault.
> One package has a failure on armhf that I don't understand:
> golang-ginkgo (I think possibly it's just running out of RAM). As this
> only has one rdep (leveldb) that builds fine, I'm proposing to leave
> this alone.
golang-ginkgo succeeded on armhf this time but failed on arm64 and
ppc64el. I don't know what's going on there.
golang-gogoprotobuf -- which has been updated since my previous test
-- failed this time on amd64 (but not other platforms) when the build
ran out of RAM.
I think the status is not really much better or worse than before,
although the docker and snappy failures need to be fixed before we
upload Go 1.5.
I see no reason from this not to build golang-go on arm64 and ppc64el.
> Comments welcome!
More information about the ubuntu-devel