Re: t4216-log-bloom.sh broken ?

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

 



Torsten Bögershausen <tboegi@xxxxxx> writes:

> []
>
> Highjacking the Git v2.45.0 announcement:

I am not sure why you want to do so.  You are perfectly capable of
sending a new message to the list (and I know you have done so in
the past).  Why would linux-kernel@ list want to hear about the
macOS issues?

> There are 4 test cases in t4216-log-bloom.sh, that do not pass on one
> Mac here (they pass on another machine)

Another machine being another mac?

> expecting success of 4216.141 'Bloom reader notices too-small data chunk':
> 	check_corrupt_graph BDAT clear 00000000 &&
> 	echo "warning: ignoring too-small changed-path chunk" \
> 		"(4 < 12) in commit-graph file" >expect.err &&
> 	test_cmp expect.err err
>
> ++ check_corrupt_graph BDAT clear 00000000
> ++ corrupt_graph BDAT clear 00000000
> ++ graph=.git/objects/info/commit-graph
> ++ test_when_finished 'rm -rf .git/objects/info/commit-graph'
> ++ test 0 = 0
> ++ test_cleanup='{ rm -rf .git/objects/info/commit-graph
> 		} && (exit "$eval_ret"); eval_ret=$?; :'
> ++ git commit-graph write --reachable --changed-paths
> ++ corrupt_chunk_file .git/objects/info/commit-graph BDAT clear 00000000
> ++ fn=.git/objects/info/commit-graph
> ++ shift
> ++ perl /Users/tb/NoBackup/projects/git/git.pu/t/lib-chunk/corrupt-chunk-file.pl BDAT clear 00000000
> ++ command /usr/bin/perl /Users/tb/NoBackup/projects/git/git.pu/t/lib-chunk/corrupt-chunk-file.pl BDAT clear 00000000
> ++ /usr/bin/perl /Users/tb/NoBackup/projects/git/git.pu/t/lib-chunk/corrupt-chunk-file.pl BDAT clear 00000000
> ++ mv .git/objects/info/commit-graph.tmp .git/objects/info/commit-graph
> override r--r--r--  tb/staff for .git/objects/info/commit-graph? (y/n [n]) not overwritten

Is this failure preventing the later steps of the test work as
expected, I wonder.  Is there something curious with the permission
bits of /Users/tb/NoBackup/projects/git/git.pu/ directory or its t/
subdirectory?  Is there something curious with the "umask" of the
user running the test?  Are they different from what you see on your
other mac that does not exhibit the problems?

Thanks.







[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