From: Fabian Stelzer <fs@gigacodes.de>
Date: Wed, 28 Jul 2021 08:18:59 GMT
Subject: Re: [PATCH v3 4/5] Use a better name for the function interpolating paths
Message-ID: <6fdc3b2f-6135-d540-1868-080a423af0e8@gigacodes.de>
In-Reply-To: <xmqqczr3at7n.fsf@gitster.g>

On 28.07.21 07:43, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Fabian Stelzer <fs@gigacodes.de> writes:
>>>>
>>>>>> I think Fabian's "ssh signing" is not as ready as this topic, and it
>>>>>> can afford to wait by rebasing on top of this topic.  By the time
>>>>>> "ssh signing" gets into testable shape (right now, it does not pass
>>>>>> tests when merged to 'seen'), hopefully the "expand install-prefix"
>>>>>> topic may already be in 'next' if not in 'master'.
>>>>> I think the test problem is not due to my patch.
>>>> I've been seeing these test failers locally, every time
>>>> fs/ssh-signing topic is merged to 'seen' (without the reftable
>>>> thing).
>>>> ...
>>> Interesting.  It seems that the failure has some correlation with
>>> the use of --root=<trash directory> option.
>>>
>>>      $ sh t5534-push-signed.sh -i
>> And 7528 fails with --root set to a /dev/shm/ trash directory.
> An update.  The same failure can be seen _without_ merging the topic
> to 'seen'.  The topic by itself will fail t5534 and t7528 when run
> with --root= set to somewhere:
>
>      $ make
>      $ testpen=/dev/shm/testpen.$$
>      $ rm -fr "$testpen" && mkdir "$testpen"
>      $ cd t
>      $ sh t5534-*.sh --root=$testpen -i
>      $ sh t7528-*.sh --root=$testpen -i
>
> on the branch itself, without getting interference by any other
> topic, should hopefully be an easy enough way to reproduce the
> problem.
>
> Thanks.


ok, funny issue. in the ssh test setup i generated a few ssh keys for 
testing and (wanting to be clever) concatenated them with a prefixed 
principal into an allowedSigners file using find & awk.

Turns out the directory entries in /dev/shm are the other way around.

touch ./t1 ./t2 /dev/shm/t1 /dev/shm/t2

find ./ -name 't[0-9]' results in:
./t1
./t2

a find /dev/shm -name 't[0-9]' returns:
/dev/shm/t2
/dev/shm/t1

I'll change the test setup code to do this statically for each key. Not 
such a good idea to rely on the file order in the dir anyway.

Thanks