> On 07 Dec 2017, at 21:50, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Todd Zullinger <tmz@xxxxxxxxx> writes: > >> Johannes Schindelin wrote: >>> 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
