Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 7, 2017, 20:50 UTC
- Message-ID
- <xmqqlgiecleo.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20171207202201.GA3693@zaya.teonanacatl.net>
Todd Zullinger <tmz@pobox.com> writes:
Show 24 quoted lines
> 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...
I wouldn't be surprised if Git::Error change is causing t9001 failure, as that can explain why 'pu' is different.