net/http: test failure of TestServeContent on Guix

[lfam]

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

go version go1.7.1 linux/amd64

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

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/gnu/store/wwg44gpwxrrjj7f37gq9h1dz0775pz63-go-1.7.1"
GOTOOLDIR="/gnu/store/wwg44gpwxrrjj7f37gq9h1dz0775pz63-go-1.7.1/pkg/tool/linux_amd64"
CC="/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build436313756=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

I'm trying to build Go 1.7.1 or 1.7.3 using GNU Guix on x86_64.

In Guix, we have a working package of Go 1.7.1 deployed on our master branch [0]. On our core-updates branch, where we update the core packages in our distribution, I tried to build 1.7.1 and 1.7.3.

We bootstrap Go 1.7 with Go 1.4.3.

What did you expect to see?

A successful test suite, excluding tests that are known to fail [1] in the Guix build environment [2].

What did you see instead?

This test failure, when building both 1.7.1 and 1.7.3:

--- FAIL: TestServeContent (0.00s)
    fs_test.go:907: test "with_last_modified": last-modified = "", want "Thu, 01 Jan 1970 00:00:00 GMT"
    fs_test.go:901: test "not_modified_modtime": status = 200; want 304
    fs_test.go:904: test "not_modified_modtime": content-type = "text/css; charset=utf-8", want ""
    fs_test.go:901: test "not_modified_modtime_with_contenttype": status = 200; want 304
    fs_test.go:904: test "not_modified_modtime_with_contenttype": content-type = "text/css", want ""
FAIL
FAIL    net/http    9.909s

I don't know how to interpret this failure. What do you think? Does this test failure indicate a serious issue, or should we skip the test?

[0]
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/golang.scm?id=17d50dfdbb0b0b2a28d0b9f498c33ba7d920a92b#n189

[1]
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/golang.scm?id=17d50dfdbb0b0b2a28d0b9f498c33ba7d920a92b#n246

[2] There is some information about the environment in our manual, starting at "On GNU/Linux, by default, the chroot environment [...]". Please let me know if I can provide more information about the Guix chroot environment.
https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html

[bradfitz]

You should never skip a test until you understand it.

What file system is this running on? It seems like this in the test is returning a zero time:

htmlModTime := mustStat(t, "testdata/index.html").ModTime()

Is stat expected to return complete information in your environment or do you fake the modtimes?

[lfam]

You should never skip a test until you understand it.

Agreed, I always prefer to ask upstream maintainers for advice.

Is stat expected to return complete information in your environment or do you fake the modtimes?

What's happening is that I applied the fix for #17276 as a patch, and that reset the mtimes to epoch. Our build system downloads the sources, unpacks and applies the patch, repacks the tarball, and caches that for later use. This process resets the mtimes to epoch (we invoke the repack tar with '--mtime=@0').

Given this information, do you think it's safe to skip the test? If I skipped the test, the mtimes would be unmodified from the upstream tarball.

Generally, is it a bad idea to build Go with the source file mtimes set to epoch? Could something go wrong that would not be caught by the test suite?

We don't "fake" the modtimes, or do anything special to the clock in the build environment. We do set the environment variable SOURCE_DATE_EPOCH=1 [0], but how this variable is used is determined by upstream maintainers.

For reference, I saved the failed build tree, and ran stat on that file:

$ stat ./go/src/net/http/testdata/index.html
  File: './go/src/net/http/testdata/index.html'
  Size: 22              Blocks: 2          IO Block: 1024   regular file
Device: fe04h/65028d    Inode: 260273      Links: 1
Access: (0644/-rw-r--r--)  Uid: (  999/guixbuilder01)   Gid: (  999/guixbuild)
Access: 2016-10-21 17:30:58.000000000 -0400
Modify: 1969-12-31 19:00:00.000000000 -0500
Change: 2016-10-21 17:30:57.000000000 -0400
 Birth: -

Here is what I get from a freshly unpacked tarball:

$ stat ./go/src/net/http/testdata/index.html
  File: './go/src/net/http/testdata/index.html'
  Size: 22              Blocks: 8          IO Block: 4096   regular file
Device: 25h/37d Inode: 73162259    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     leo)   Gid: ( 1000/     leo)
Access: 2016-10-21 17:38:31.078167128 -0400
Modify: 2016-09-07 15:34:35.000000000 -0400
Change: 2016-10-21 17:38:31.078167128 -0400
 Birth: -

[0]
https://reproducible-builds.org/specs/source-date-epoch/

[bradfitz]

Generally, is it a bad idea to build Go with the source file mtimes set to epoch?

Yes, it makes tests fail, like this one.

Could something go wrong that would not be caught by the test suite?

No. But disabling tests only gives you a false sense of security.

Feel free to disable if you like, but we don't recommend it.

I'm closing this, because it's veering into https://golang.org/wiki/Questions territory more than a bug report.