1.0.2-1ubuntu1~14.04.1 in trusty-proposed needs to depend on gccgo-go not gccgo

[Michael Hudson-Doyle]

[Impact]
This package does not currently build on architectures that do not support golang, but do have gccgo support. Since this package is a build-dependency for docker.io, docker.io is also not available.

[Test Case]
Build docker.io in trusty on an impacted architecture (I'm using arm64).

[Regression Risk]
The changes to enable gccgo are restricted to architectures that currently do not build.

[Robie Basak (racb)]

OK, but this is a new package in Trusty and docker.io in Trusty has never built against arm64, powerpc or ppc64el. So this isn't an SRU regression.

I guess we could fix this in the backport, although it's a bit awkward since we're using a script to generate the backports and I'd prefer to not have to special case this one. But does it gain anything if we're not aiming to enable extra architectures for Docker in Trusty anyway?

[Michael Hudson-Doyle (mwhudson)]

You're right this is not a regression. I didn't know if we are *trying* to fix the failure to build of docker on arm64 etc though -- if we are, this should be fixed (and it's possible that fixing this and getting finally getting bug 1361940 SRUed is enough, although I haven't verified that). If not, then sure, feel free to leave this.

[dann frazier (dannf)]

Though I agree this is not a regression, it does fall under hardware enablement IMO. The attached patch resolves this by allowing gccgo-go fulfill the build-dep if gccgo > 5 is not available.

Could we avoid future special casing by adding the same to wily iff it is ever updated? If so - maybe we could add a reminder in your backport script so it isn't forgotten.

[dann frazier (dannf)]

We also need to disable stripping of the resulting gccgo binaries. Updated patch attached.

[dann frazier (dannf)]

I prepared a docker PPA with this update and asked our QA team to run some tests on it. Even though the binary builds and runs, we're still seeing docker crashes based on the older version of gccgo in trusty, so it still doesn't make sense to enable docker for gccgo in trusty at this time.

This upload is pending in the SRU queue for trusty but, since docker.io is the only package that build-depends upon go-md2man, I'll ask an SRU team member to reject.

[Chris J Arges (arges)]

To confirm you want go-md2man (1.0.2-1ubuntu1~14.04.2) in trusty rejected?

[dann frazier (dannf)]

On Wed, Mar 23, 2016 at 6:02 AM, Chris J Arges
<email address hidden> wrote:
> To confirm you want go-md2man (1.0.2-1ubuntu1~14.04.2) in trusty
> rejected?

Yes, please and thank you! :)