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

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?

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.

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.

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

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.

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

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! :)