On 5 August 2015 at 14:40, Michael Hudson-Doyle
> An update.
> On 31 July 2015 at 09:39, Michael Hudson-Doyle
> <email@example.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
>> 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.
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
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.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel