Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)
From: Lars Schneider <hidden>
Date: 2017-12-07 21:08:36
On 07 Dec 2017, at 21:50, Junio C Hamano [off-list ref] wrote: Todd Zullinger [off-list ref] writes:quoted
Johannes Schindelin wrote:quoted
That is not the only thing going wrong: https://travis-ci.org/git/git/builds/312551566 It would seem that t9001 is broken on Linux32, t5616 is broken on macOS, and something really kinky is going on with the GETTEXT_POISON text, as it seems to just abort while trying to run t6120.I thought the verbose logs from the test might be useful, but looking at the travis output for that job[1], there's an unrelated problem preventing the ci/print-test-failures.sh script from running properly: $ ci/print-test-failures.sh cat: t/test-results/t1304-default-acl.exit: Permission denied ------------------------------------------------------------------------ t/test-results/t1304-default-acl.out... ------------------------------------------------------------------------ cat: t/test-results/t1304-default-acl.out: Permission denied [1] https://travis-ci.org/git/git/jobs/312551595#L2185 I didn't see the same failure for other build targets at a glance, so the permission issue might only be a problem for the linux32 builds.Curious. The acl stuff hasn't changed for a long time and I do not think of a reason offhand why the test should behave differently between say 'maint' and 'pu', yet 'maint' is passing while 'pu' is not...
My recent 657343a602 (travis-ci: move Travis CI code into dedicated scripts, 2017-09-10) change might have broken that somehow... See this comment: # If this script runs inside a docker container, then all commands are # usually executed as root. Consequently, the host user might not be # able to access the test output files. # If a host user id is given, then create a user "ci" with the host user # id to make everything accessible to the host user. https://github.com/git/git/blob/95ec6b1b3393eb6e26da40c565520a8db9796e9f/ci/run-linux32-build.sh#L16-L20 - Lars