please upload 1.5 final packages

cypermox said by email:

> it seems to me like not removing the .syso files, which are both
> arch-dependent and prebuilt binaries we cannot verify have been
> built with the source provided (even if there is strong suspicion
> that they were) is the wrong approach to fixing these
> tests.

This is one of those things where you are totally correct, but this problem totally predates my changes :-) These syso files were distributed before, just harder to find:

$ mkdir /tmp/golang-race
$ cd /tmp/golang-race
$ chdist apt-get sid download golang-go-linux-amd64
Get:1 http://ftp.debian.org/debian/ unstable/main golang-go-linux-amd64 amd64 2:1.4.2-3 [8,696 kB]
Fetched 8,696 kB in 12s (724 kB/s)
$ dpkg-deb -x golang-go-linux-amd64_2%3a1.4.2-3_amd64.deb .
$ ar x usr/lib/go/pkg/linux_amd64/runtime/race.a
$ ls
_go_.6 golang-go-linux-amd64_2%3a1.4.2-3_amd64.deb __.PKGDEF race_linux_amd6 usr
$ diff race_linux_amd6 ~/go1.4/src/runtime/race/race_linux_amd64.syso && echo same
same

> Instead, I think these files should be built as part of
> the build process for golang, or the tests used to report the bug
> fixed.

The former sort of makes sense, the latter part doesn't: these are not inputs to test cases, they are required for functionality that has worked until now (Go's race detector). The process to build them is explained here: https://github.com/golang/go/blob/master/src/runtime/race/README -- it sounds like automating this enough to be done as part of a package build is feasible (but not trivial).

> Either way, I'm not familiar enough with go to have an
> opinion, but if you need help I can dig deeper :)

> Those are not
> the only files I'm wondering about, there are multiple other
> binaries that probably shouldn't be included in the upstream
> tarball... have you brought this up upstream?

All the other stuff I am aware of is things like input for the elf parser tests. Are those what you mean? If so, I don't think upstream would be terribly impressed in our suggestion that they not be included. (They are built from source in the tree, but not as part of the build process -- some of them are testing behaviour against very specific toolchain versions, for one thing).

My concern isn't so much in that these binaries come with the source -- it sounds suboptimal, but it's not quite as bad as shipping binary blobs we haven't built ourselves...

That's the main issue I have with it and with removing the line from rules which deletes .syso files (note that we probably shouldn't ship any binaries we have not built ourselves, that includes other ELF binaries packed in the source tarball). It's possibly OK to run these binaries late in the build process when running tests because we are not exposing our users to untrusted binaries directly (as long as they don't go silently change the binaries we built and are about to ship), but shipping these files to users without having built them ourselves sounds like a security accident waiting to happen.

Ah, and I almost forgot, please describe the changes since RC 1 (from the upstream changelog or wherever) since this will require a feature freeze exception.

NB: it only requires a feature freeze exception if it's a featureful upload. if the differences between rc1 and final are just bugfixes, no need to enumerate.

On 26 August 2015 at 03:15, Mathieu Trudel-Lapierre
<email address hidden> wrote:
> My concern isn't so much in that these binaries come with the source --
> it sounds suboptimal, but it's not quite as bad as shipping binary blobs
> we haven't built ourselves...

Right, but as I tried to say, this is not a new thing, we were
distributing these blobs anyway.

> That's the main issue I have with it and with removing the line from
> rules which deletes .syso files (note that we probably shouldn't ship
> any binaries we have not built ourselves, that includes other ELF
> binaries packed in the source tarball). It's possibly OK to run these
> binaries late in the build process when running tests because we are not
> exposing our users to untrusted binaries directly (as long as they don't
> go silently change the binaries we built and are about to ship), but
> shipping these files to users without having built them ourselves sounds
> like a security accident waiting to happen.

I agree that what we have here is not good. To be clear, the syso
files are nothing at all to do with running test cases during the
build.

Here's a more limited diff that retains the deletion of the syso files.

For the record here are all the changes between the rc1 release and final: https://github.com/golang/go/compare/go1.5rc1...go1.5

They are all bugfix releases, but in any case I had already talked to a release team member (steve!) about uploading rc1 before freeze and updating to the release soon after, so I think any required FFe will be granted with a minimum of fuss.

golang (2:1.5-0ubuntu1) wily; urgency=medium

  * New upstream release.
    - Drop debian/patches/disable-duffzero-ppc64el.patch
  * Breaks/Replaces: older golang-go.tools (LP: 1486560)