Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

net/http: test failure of TestServeContent on Guix #17535

Closed
lfam opened this issue Oct 21, 2016 · 3 comments
Closed

net/http: test failure of TestServeContent on Guix #17535

lfam opened this issue Oct 21, 2016 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Unplanned

Comments

@lfam
Copy link

lfam commented Oct 21, 2016

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
Copy link
Contributor

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?

@bradfitz bradfitz added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 21, 2016
@bradfitz bradfitz added this to the Unplanned milestone Oct 21, 2016
@bradfitz bradfitz changed the title Test failure of TestServeContent net/http: test failure of TestServeContent on Guix Oct 21, 2016
@lfam
Copy link
Author

lfam commented Oct 21, 2016

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
Copy link
Contributor

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.

@golang golang locked and limited conversation to collaborators Oct 22, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@bradfitz @lfam @gopherbot