On 28.07.21 07:43, Junio C Hamano wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:
Junio C Hamano <gitster@xxxxxxxxx> writes:
Junio C Hamano <gitster@xxxxxxxxx> writes:
Fabian Stelzer <fs@xxxxxxxxxxxx> 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
