time: TestLoadFixed failure

[lfam]

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

go version go1.4.3 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/gnu/store/avygi1jh3ki2cji6fb9i0lg1h3r2nz80-go-1.4.3"
GOTOOLDIR="/gnu/store/avygi1jh3ki2cji6fb9i0lg1h3r2nz80-go-1.4.3/pkg/tool/linux_amd64"
CC="/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="0"

What did you do?

Trying to rebuild Go 1.4.3 with tzdata 2016g, the test TestLoadFixed fails:

--- FAIL: TestLoadFixed (0.00s)
    time_test.go:929: Now().In(loc).Zone() = "-01", -3600, want "GMT+1", -3600
FAIL
FAIL    time    2.473s

This is the same underlying issue as in #17276. That is, the name of the time zone used in the test has changed in tzdata 2016g. However, the fix suggested in that ticket does not work for 1.4.3. When I apply the patch that fixes the bug for the 1.7 release series, compilation fails like this:

 # Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, linux/amd64.
lib9
go tool dist: missing file /tmp/guix-build-go-1.4.3.drv-0/go/include/fmt.h

What did you expect to see?

A successful test suite.

What did you see instead?

A failure of TestLoadFixed.

What do you suggest for distributions that use Go 1.4.3 to bootstrap later versions of Go?

[ianlancetaylor]

First, I suggest that you not care about a failure in the time package when building Go 1.4 solely in order to build a later version of Go. A test failure of that sort doesn't matter. Don't worry about it.

Second, I'm afraid that I simply don't believe that your 1.4 sources built before you applied the change in https://golang.org/cl/29995 but then failed to build in the way that you describe after you applied that change. That change could not cause that failure. Either that failure existed before you applied that change, or you changed more than just that one file.

[lfam]

First, I suggest that you not care about a failure in the time package when building Go 1.4 solely in order to build a later version of Go. A test failure of that sort doesn't matter. Don't worry about it.

Thanks for the advice. We'll skip that test.

Second, I'm afraid that I simply don't believe that your 1.4 sources built before you applied the change in https://golang.org/cl/29995 but then failed to build in the way that you describe after you applied that change. That change could not cause that failure. Either that failure existed before you applied that change, or you changed more than just that one file.

Intriguing.

Our packaging [0] alters the Go sources in these ways:

1. Delete some tests that require networking, which is not available in the Guix build environment.
2. Disable some other tests that all seem to be related to Unix shell operations. I didn't make that part of the packaging, so I don't know off-hand how they fail.
3. Patch paths to a variety of dependencies.

I'm afraid that I'm simply not a Go programmer, so I can't say if these changes would cause the failure in question when combined with the fix for #17276.

However, our 1.4.3 package does successfully bootstrap 1.7.1 and 1.7.3, which I do use to build working Go applications.

[0] If you see anything amiss, I'd be very glad if you told us.
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/golang.scm?h=core-updates&id=f08add0c5a3f1f7200b0a00e17ed880692d2244b#n47

[bradfitz]

Decision from meeting: we'll just skip this test on the Go 1.4 branch.

/cc @josharian

[gopherbot]

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

[minux]

Bootstrapping later Go versions doesn't require Go 1.4's all.bash to pass. Just do make.bash and use the tool chain to bootstrap later Go versions. Why do you want to update the timezone database in 1.4? If you're using later Go versions, the fact that Go 1.4 doesn't have the latest timezone database doesn't matter. And we certainly won't issue a new 1.4 point release to update the time tests or the bundled timezone database. Closing as nothing to do.

[josharian]

@minux when cherry-picking fixes to 1.4, it's nice to have confirmation that all.bash runs. Skipping tests on release-branch.go1.4 whose failures are known to be unimportant seems a reasonable approach to take. I'll still close this issue, though, since CL 31855 went in. (I think GitHub only auto-closes based on commit messages when commits land in the master branch.)