RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Aug 2, 2024, 01:51 UTC
Message-ID: <033801dae47e$7d3a5cc0$77af1640$@nexbridge.com>
In-Reply-To: <ZqwvQUAqVozGHG/t@nand.local>

On Thursday, August 1, 2024 8:59 PM, Taylor Blau wrote:

Show 34 quoted lines

>On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@nexbridge.com wrote:
>> ls output with second resolution is here - the file system does not have
>nanosecond resolution despite showing zeros:
>>
>> /home/ituglib/randall/git/t/trash
>> directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack:
>> ls -la --full-time total 11 drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-
>01 16:18:55.000000000 -0600 .
>> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01
>16:18:48.000000000 -0600 ..
>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01
>> 16:18:52.000000000 -0600
>> pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx
>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB  217 2024-08-01 16:18:52.000000000 -
>0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack
>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB   64 2024-08-01 16:18:52.000000000 -
>0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev
>
>Ah, I suspect that this is even less interesting than imprecise mtime resolution. The
>test expects that the packs are larger than 1M so that we can exercise writing
>multiple cruft packs as part of the setup.
>
>But that pack is only 217 bytes, which wouldn't trigger the split. I'm suspicious that
>it's even packing the cruft objects at all, so I'm curious if you can find $foo, $bar,
>and $baz in the cruft pack's .idx file(s, if multiple) after the first 'git repack -d --cruft'.
>
>Assuming they are there, it's possible that setting repack.cruftWindow in the test
>repository would do the trick.
>
>But I'm suspicious that that's even what's going on since generate_random_blob()'s
>first argument is a seed, and all three objects have different seeds, so I don't think
>they would even be considered good delta candidates for one another. But it's also
>possible that your
>generate_random_blob() behaves differently from my own.

I will try to look tomorrow for $foo, $bar, and $baz. On generate_random_blob(), from OpenSSL's standpoint, on ia64, we use PRNGD. It should be of the same order of magnitude as anywhere else, but depends on the randomness measure - we are able to start it, so randomness is proper. On my x86 machine, I use the hardware randomizer, which is better (and FIPS compatible) and might be why we don't see it there.