Subject: Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

From: Junio C Hamano <[email-masked]>
Date: Thu, 07 Dec 2017 12:50:39 -0800

Todd Zullinger <[email-masked]> 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...

I wouldn't be surprised if Git::Error change is causing t9001
failure, as that can explain why 'pu' is different.