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

[armel] "go test" fails at TestTplGoFuzzReports #1771

Closed
anthonyfok opened this Issue Jan 12, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@anthonyfok
Contributor

anthonyfok commented Jan 12, 2016

According to the Debian armel (soft-float ARM platform) build daemon build log, go test fails at TestTplGoFuzzReports:

=== RUN   TestTplGoFuzzReports
--- FAIL: TestTplGoFuzzReports (0.05s)
    template_test.go:141: #2 Test 1 should have errored
FAIL
FAIL    github.com/spf13/hugo/tpl   0.310s

I was able to reproduce this on Debian armel developer machine abel.debian.org, but I need more time to investigate the cause.

Note that this problem does not affect armhf (ARM hard-float).

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jan 13, 2016

Member

What Go version is this? (these tests are real corner cases, and issues with Go stdlib more than Hugo).

Member

bep commented Jan 13, 2016

What Go version is this? (these tests are real corner cases, and issues with Go stdlib more than Hugo).

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 13, 2016

Contributor

It is with go version go1.5.1 linux/arm, or, more specifically, 1.5.1-4, that was compiled from source by Debian.

I am glad that you wrote these corner tests, and I am happy to keep the TestTplGoFuzzReports around even for Debian's armel build until the said problem is solved by the Go team. I suppose the Debian armel people won't mind, as I suspect few people would actually run Hugo on armel machines.

If any armel people complains, I could always disable the go test line altogether, or just add a || : at the end to let the go test passes regardless of the actual test result. ;-)

Contributor

anthonyfok commented Jan 13, 2016

It is with go version go1.5.1 linux/arm, or, more specifically, 1.5.1-4, that was compiled from source by Debian.

I am glad that you wrote these corner tests, and I am happy to keep the TestTplGoFuzzReports around even for Debian's armel build until the said problem is solved by the Go team. I suppose the Debian armel people won't mind, as I suspect few people would actually run Hugo on armel machines.

If any armel people complains, I could always disable the go test line altogether, or just add a || : at the end to let the go test passes regardless of the actual test result. ;-)

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jan 13, 2016

Member

I'm pretty impressed by the Debian test setup.

Member

bep commented Jan 13, 2016

I'm pretty impressed by the Debian test setup.

bep added a commit that referenced this issue Jan 13, 2016

bep added a commit that referenced this issue Jan 13, 2016

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 13, 2016

Contributor

I'm pretty impressed by the Debian test setup.

Me too! 😉 Though at times I took it for granted, and mistakenly thought some Debian infrastructures as antiquated. But indeed, Debian does cover a lot of architectures, and its build farms not only bring as many software as possible to lesser-used platforms, but also provide a great testing infrastructure for free!

Here is the current cross-platform support status for Hugo:

I wonder if I could use gccgo (instead of golang-go) to get Hugo on more platforms (such as alpha, mips, s390x, sparc64, etc.), see https://bugs.debian.org/785649 for go-md2man as an example. The go-md2man package itself has been patched to allow gccgo, but not its dependencies (see https://buildd.debian.org/status/package.php?p=go-md2man), so that is what I will try next. :-)

Contributor

anthonyfok commented Jan 13, 2016

I'm pretty impressed by the Debian test setup.

Me too! 😉 Though at times I took it for granted, and mistakenly thought some Debian infrastructures as antiquated. But indeed, Debian does cover a lot of architectures, and its build farms not only bring as many software as possible to lesser-used platforms, but also provide a great testing infrastructure for free!

Here is the current cross-platform support status for Hugo:

I wonder if I could use gccgo (instead of golang-go) to get Hugo on more platforms (such as alpha, mips, s390x, sparc64, etc.), see https://bugs.debian.org/785649 for go-md2man as an example. The go-md2man package itself has been patched to allow gccgo, but not its dependencies (see https://buildd.debian.org/status/package.php?p=go-md2man), so that is what I will try next. :-)

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jun 12, 2016

Contributor

Update for v0.16:

=== RUN   TestTplGoFuzzReports
--- FAIL: TestTplGoFuzzReports (0.05s)
    template_test.go:274: #2 Test 1 should have errored
FAIL
FAIL    github.com/spf13/hugo/tpl   0.658s

Full build log at https://buildd.debian.org/status/fetch.php?pkg=hugo&arch=armel&ver=0.16-1&stamp=1465729600

Contributor

anthonyfok commented Jun 12, 2016

Update for v0.16:

=== RUN   TestTplGoFuzzReports
--- FAIL: TestTplGoFuzzReports (0.05s)
    template_test.go:274: #2 Test 1 should have errored
FAIL
FAIL    github.com/spf13/hugo/tpl   0.658s

Full build log at https://buildd.debian.org/status/fetch.php?pkg=hugo&arch=armel&ver=0.16-1&stamp=1465729600

@anthonyfok anthonyfok changed the title from On armel, "go test" fails at TestTplGoFuzzReports to [armel] "go test" fails at TestTplGoFuzzReports Jun 13, 2016

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jul 1, 2017

Member

This issue has been automatically marked as stale because it has not been commented on for at least six months.

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

Member

bep commented Jul 1, 2017

This issue has been automatically marked as stale because it has not been commented on for at least six months.

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

@bep bep added the Stale label Jul 1, 2017

@bep bep closed this Jul 1, 2017

tychoish added a commit to tychoish/hugo that referenced this issue Aug 13, 2017

tychoish added a commit to tychoish/hugo that referenced this issue Aug 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment