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

- List: git
- 2 messages, 2 authors
- Page: https://ratatoskr.run/git/2017/12/7745848/t

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

- From: Junio C Hamano \<hidden\>
- Date: 2017-12-07 20:52:41 
- Message: https://ratatoskr.run/git/2017/12/7745848.md

```text
Todd Zullinger [ref] 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.
```

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

- From: Lars Schneider \<hidden\>
- Date: 2017-12-07 21:08:36 
- Message: https://ratatoskr.run/git/2017/12/7745852.md

```text

> On 07 Dec 2017, at 21:50, Junio C Hamano [ref] wrote:
> 
> Todd Zullinger [ref] 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
```