compress/gzip: test fails with "go1.8rc1.linux-amd64.tar.gz has non-zero mtime"

[evverx]

What version of Go are you using (go version)?

go version devel +ac05542 Wed Jan 11 01:39:54 2017 +0000 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/tmp/gopath/"
GORACE=""
GOROOT="/home/vagrant/go-repo"
GOTOOLDIR="/home/vagrant/go-repo/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build740621882=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

go get -u -v golang.org/x/build/version/go1.8rc1
go1.8rc1 download
go1.8rc1 test compress/gzip

What did you expect to see?

ok      compress/gzip   0.062s

What did you see instead?

--- FAIL: TestGZIPFilesHaveZeroMTimes (0.03s)
        issue14937_test.go:60: gzip file /home/vagrant/sdk/go1.8rc1/go1.8rc1.linux-amd64.tar.gz has non-zero mtime (2042-07-14 01:04:00 +0000 UTC)
FAIL
FAIL    compress/gzip   0.044s

[dsnet]

Ha. Interesting failure. The TestGZIPFilesHaveZeroMTimes test is already a shady test...

The ways I see to fix this:

1. Only have TestGZIPFilesHaveZeroMTimes scan files that are checked into the tree, but I don't see an easy way for the function to know what's tracked by git or not.
2. Only have TestGZIPFilesHaveZeroMTimes run when testing on the build bots.
3. Have golang.org/x/build/version not put the .tar.gz file inside the GOROOT.
4. Make the release archives have properly zeroed times. The zero ModTime field in gzip was fixed in Go1.8... Whatever is generating the release is probably not running on Go 1.8.

I vote that we either fix 2 or 3 (or both). We should also address 4, by explicitly setting the gzip.Header.ModTime field to be time.Unix(0, 0).

\cc @bradfitz Thoughts?

[bradfitz]

(2) is easy.

I don't know what (3) means, and I don't want to mess with release infrastructure (4) at this point in the release.

[bradfitz]

Feel free to send a CL for (2) for Go 1.8 at least. We can keep this bug open to fix it more properly for Go 1.9.

[gopherbot]

CL https://golang.org/cl/35111 mentions this issue.