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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux