{"thread":{"id":"61882","subject":"[BUG] 2.46.0 t7701.09 fails on NonStop ia64","startedAt":"2024-08-01T18:03:39Z","lastAt":"2024-08-04T19:15:48Z","messageCount":12,"participants":["rsbecker@nexbridge.com","Taylor Blau"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"499883","messageId":"02d301dae43d$2202fc90$6608f5b0$@nexbridge.com","threadId":"61882","inReplyTo":null,"subject":"[BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-01T18:03:31Z","receivedAt":"2024-08-01T18:03:39Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Hi Team,\n\nI think this is low priority but would like to understand the situation. It\nonly happens on NonStop ia64 (consistently), not x86.\n\nThe t7701.09 subtest fails missing files:\n\nTotal 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)\nls: cannot access '.git/objects/pack/pack-*.mtimes': No such file or\ndirectory\ntest_line_count: line count for cruft.after != 2\nnot ok 9 - --max-cruft-size with pruning\n\nThe test directory contains:\n./.git/objects/pack\n./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n\nbut no mtimes files. I'm not sure how to proceed with this - currently\nignoring the failure but I\nthink it might be significant. This only fails on NonStop ia64 (which is\nmuch older) and passes\non NonStop x86. There is no real file system reason why this would be a\ndifference between the\ntwo platforms. There are some limit differences, but that's pretty much it.\n\nAny assistance tracking this down would be appreciated. I can set up\nbreakpoints to catch\nwhatever is needed.\n\nRegards,\nRandall\n\n"},{"id":"499897","messageId":"ZqvgmYl8BTYvsSa0@nand.local","threadId":"61882","inReplyTo":"02d301dae43d$2202fc90$6608f5b0$@nexbridge.com","subject":"Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-08-01T19:23:05Z","receivedAt":"2024-08-01T19:23:08Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, Aug 01, 2024 at 02:03:31PM -0400, rsbecker@nexbridge.com wrote:\n> Hi Team,\n>\n> I think this is low priority but would like to understand the situation. It\n> only happens on NonStop ia64 (consistently), not x86.\n>\n> The t7701.09 subtest fails missing files:\n\nHmm. Script t7701 only has 8 sub-tests, but I think you're referring to\nt7704.9\n>\n> Total 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)\n> ls: cannot access '.git/objects/pack/pack-*.mtimes': No such file or\n> directory\n> test_line_count: line count for cruft.after != 2\n> not ok 9 - --max-cruft-size with pruning\n>\n> The test directory contains:\n> ./.git/objects/pack\n> ./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n> ./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n> ./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n\nInteresting. Can you attach the full -vx output of this test, as well as\na ls -la from $GIT_DIR/objects/pack?\n\nI suspect that this is a mtime resolution issue in whatever filesystem\nis in use in your ia64 environment, but the full logs will help us\nconfirm that, or at least point is in a better direction.\n\nThanks in advance.\n\nThanks,\nTaylor\n"},{"id":"499913","messageId":"032201dae461$c7bcc9d0$57365d70$@nexbridge.com","threadId":"61882","inReplyTo":"ZqvgmYl8BTYvsSa0@nand.local","subject":"RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-01T22:25:51Z","receivedAt":"2024-08-01T22:25:59Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Thursday, August 1, 2024 3:23 PM, Taylor Blau wrote:\n>On Thu, Aug 01, 2024 at 02:03:31PM -0400, rsbecker@nexbridge.com wrote:\n>> Hi Team,\n>>\n>> I think this is low priority but would like to understand the\n>> situation. It only happens on NonStop ia64 (consistently), not x86.\n>>\n>> The t7701.09 subtest fails missing files:\n>\n>Hmm. Script t7701 only has 8 sub-tests, but I think you're referring to\n>t7704.9\n\nYes, t7704.9. Sorry.\n\n>> Total 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)\n>> ls: cannot access '.git/objects/pack/pack-*.mtimes': No such file or\n>> directory\n>> test_line_count: line count for cruft.after != 2 not ok 9 -\n>> --max-cruft-size with pruning\n>>\n>> The test directory contains:\n>> ./.git/objects/pack\n>> ./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n>> ./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n>> ./.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n>\n>Interesting. Can you attach the full -vx output of this test, as well as a ls -la from\n>$GIT_DIR/objects/pack?\n>\n>I suspect that this is a mtime resolution issue in whatever filesystem is in use in your\n>ia64 environment, but the full logs will help us confirm that, or at least point is in a\n>better direction.\n\nHere is the output as requested, with ls following. This is using OpenSSL 3.0 - OpenSSL 1.0.2 is further down with slightly different results.\n\n++ git init max-cruft-size-prune\nInitialized empty Git repository in /home/ituglib/randall/git/t/trash directory.t7704-repack-cruft/max-cruft-size-prune/.git/\n++ cd max-cruft-size-prune\n++ test_commit base\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 1 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=base.t\n++ test -n ''\n++ echo base\n++ git add -- base.t\n++ test -z ''\n++ test_tick\n++ test -z ''\n++ test_tick=1112911993\n++ GIT_COMMITTER_DATE='1112911993 -0700'\n++ GIT_AUTHOR_DATE='1112911993 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m base\n[master (root-commit) d1ff1c9] base\n Author: A U Thor <author@example.com>\n 1 file changed, 1 insertion(+)\n create mode 100644 base.t\n++ case \"$tag\" in\n++ git tag base\n+++ generate_random_blob foo 1048576\n+++ test-tool genrandom foo 1048576\n+++ git hash-object -w -t blob blob\n+++ rm blob\n++ foo=4f336f3df31054eabc05ac05f98bc024c8e05423\n+++ generate_random_blob bar 1048576\n+++ test-tool genrandom bar 1048576\n+++ git hash-object -w -t blob blob\n+++ rm blob\n++ bar=bd44d8aa2d22eb47ff70cef4b0bb45d1549ee49c\n+++ generate_random_blob baz 1048576\n+++ test-tool genrandom baz 1048576\n+++ git hash-object -w -t blob blob\n+++ rm blob\n++ baz=ad16bed54cc61cf036075879deeff95ae977514b\n+++ test_oid_to_path 4f336f3df31054eabc05ac05f98bc024c8e05423\n+++ local basename=336f3df31054eabc05ac05f98bc024c8e05423\n+++ echo 4f/336f3df31054eabc05ac05f98bc024c8e05423\n++ test-tool chmtime -10000 .git/objects/4f/336f3df31054eabc05ac05f98bc024c8e05423\n++ git repack -d --cruft --max-cruft-size=1M\nEnumerating objects: 3, done.\nCounting objects: 100% (3/3), done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nEnumerating cruft objects: 6, done.\nCounting objects: 100% (3/3), done.\nCompressing objects: 100% (3/3), done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n++ ls .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.mtimes .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.mtimes\n++ sort\n+++ cat cruft.before\n++ for cruft in $(cat cruft.before)\n+++ test-tool chmtime --get -10000 .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes\n++ mtime=1722540725\n++ echo .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes 1722540725\n++ for cruft in $(cat cruft.before)\n+++ test-tool chmtime --get -10000 .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.mtimes\n++ mtime=1722540723\n++ echo .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.mtimes 1722540723\n++ for cruft in $(cat cruft.before)\n+++ test-tool chmtime --get -10000 .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.mtimes\n++ mtime=1722540726\n++ echo .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.mtimes 1722540726\n++ git repack -d --cruft --max-cruft-size=1M --cruft-expiration=10.seconds.ago\nEnumerating objects: 3, done.\nCounting objects: 100% (3/3), done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)\n++ ls '.git/objects/pack/pack-*.mtimes'\n++ sort\nls: cannot access '.git/objects/pack/pack-*.mtimes': No such file or directory\n+++ cat cruft.after\n++ test_line_count = 3 cruft.before\n++ test 3 '!=' 3\n+++ wc -l\n++ test 3 = 3\n++ test_line_count = 2 cruft.after\n++ test 3 '!=' 3\n+++ wc -l\n++ test 0 = 2\n++ echo 'test_line_count: line count for cruft.after != 2'\ntest_line_count: line count for cruft.after != 2\n++ cat cruft.after\n++ return 1\nerror: last command exited with $?=1\nnot ok 9 - --max-cruft-size with pruning\n\nls output with second resolution is here - the file system does not have nanosecond resolution despite showing zeros:\n\n/home/ituglib/randall/git/t/trash directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack: ls -la --full-time\ntotal 11\ndrwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 16:18:55.000000000 -0600 .\ndrwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 16:18:48.000000000 -0600 ..\n-r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n-r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB  217 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n-r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB   64 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n\n\nWhen running with OpenSSL 1.0.2, the failure is different:\n++ git init max-cruft-size-prune\nInitialized empty Git repository in /home/ituglib/randall/jenkins/.jenkins/workspace/Git_Pipeline/t/trash directory.t7704-repack-cruft/max-cruft-size-prune/.git/\n++ cd max-cruft-size-prune\n++ test_commit base\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 1 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=base.t\n++ test -n ''\n++ echo base\n++ git add -- base.t\n++ test -z ''\n++ test_tick\n++ test -z ''\n++ test_tick=1112911993\n++ GIT_COMMITTER_DATE='1112911993 -0700'\n++ GIT_AUTHOR_DATE='1112911993 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m base\n[master (root-commit) d1ff1c9] base\n Author: A U Thor <author@example.com>\n 1 file changed, 1 insertion(+)\n create mode 100644 base.t\n++ case \"$tag\" in\n++ git tag base\n+++ generate_random_blob foo 1048576\n+++ test-tool genrandom foo 1048576\n+++ git hash-object -w -t blob blob\n+++ rm blob\n++ foo=4f336f3df31054eabc05ac05f98bc024c8e05423\n+++ generate_random_blob bar 1048576\n+++ test-tool genrandom bar 1048576\n+++ git hash-object -w -t blob blob\n+++ rm blob\n++ bar=bd44d8aa2d22eb47ff70cef4b0bb45d1549ee49c\n+++ generate_random_blob baz 1048576\n+++ test-tool genrandom baz 1048576\n+++ git hash-object -w -t blob blob\n+++ rm blob\n++ baz=ad16bed54cc61cf036075879deeff95ae977514b\n+++ test_oid_to_path 4f336f3df31054eabc05ac05f98bc024c8e05423\n+++ local basename=336f3df31054eabc05ac05f98bc024c8e05423\n+++ echo 4f/336f3df31054eabc05ac05f98bc024c8e05423\n++ test-tool chmtime -10000 .git/objects/4f/336f3df31054eabc05ac05f98bc024c8e05423\n++ git repack -d --cruft --max-cruft-size=1M\nEnumerating objects: 3, done.\nCounting objects: 100% (3/3), done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nEnumerating cruft objects: 6, done.\nCounting objects: 100% (3/3), done.\nCompressing objects: 100% (3/3), done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n++ ls .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.mtimes .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.mtimes\n++ sort\n+++ cat cruft.before\n++ for cruft in $(cat cruft.before)\n+++ test-tool chmtime --get -10000 .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes\n++ mtime=1722531262\n++ echo .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes 1722531262\n++ for cruft in $(cat cruft.before)\n+++ test-tool chmtime --get -10000 .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.mtimes\n++ mtime=1722531261\n++ echo .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.mtimes 1722531261\n++ for cruft in $(cat cruft.before)\n+++ test-tool chmtime --get -10000 .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.mtimes\n++ mtime=1722531263\n++ echo .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.mtimes 1722531263\n++ git repack -d --cruft --max-cruft-size=1M --cruft-expiration=10.seconds.ago\nEnumerating objects: 3, done.\nCounting objects: 100% (3/3), done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)\nEnumerating cruft objects: 1, done.\nTraversing cruft objects: 1, done.\nCounting objects: 100% (1/1), done.\nWriting objects: 100% (1/1), done.\nTotal 1 (delta 0), reused 1 (delta 0), pack-reused 0 (from 0)\n++ ls .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes\n++ sort\n+++ cat cruft.after\n++ for cruft in $(cat cruft.after)\n+++ grep .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes mtimes\n+++ cut '-d ' -f2\n++ old_mtime=1722531262\n+++ test-tool chmtime --get .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes\n++ new_mtime=1722541267\n++ test 1722531262 -lt 1722541267\n++ test_line_count = 3 cruft.before\n++ test 3 '!=' 3\n+++ wc -l\n++ test 3 = 3\n++ test_line_count = 2 cruft.after\n++ test 3 '!=' 3\n+++ wc -l\n++ test 1 = 2\n++ echo 'test_line_count: line count for cruft.after != 2'\ntest_line_count: line count for cruft.after != 2\n++ cat cruft.after\n.git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.mtimes\n++ return 1\nerror: last command exited with $?=1\nnot ok 9 - --max-cruft-size with pruning\n\n"},{"id":"499919","messageId":"ZqwvQUAqVozGHG/t@nand.local","threadId":"61882","inReplyTo":"032201dae461$c7bcc9d0$57365d70$@nexbridge.com","subject":"Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-08-02T00:58:41Z","receivedAt":"2024-08-02T00:58:44Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@nexbridge.com wrote:\n> ls output with second resolution is here - the file system does not have nanosecond resolution despite showing zeros:\n>\n> /home/ituglib/randall/git/t/trash directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack: ls -la --full-time\n> total 11\n> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 16:18:55.000000000 -0600 .\n> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 16:18:48.000000000 -0600 ..\n> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB  217 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB   64 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n\nAh, I suspect that this is even less interesting than imprecise mtime\nresolution. The test expects that the packs are larger than 1M so that\nwe can exercise writing multiple cruft packs as part of the setup.\n\nBut that pack is only 217 bytes, which wouldn't trigger the split. I'm\nsuspicious that it's even packing the cruft objects at all, so I'm\ncurious if you can find $foo, $bar, and $baz in the cruft pack's .idx\nfile(s, if multiple) after the first 'git repack -d --cruft'.\n\nAssuming they are there, it's possible that setting repack.cruftWindow\nin the test repository would do the trick.\n\nBut I'm suspicious that that's even what's going on since\ngenerate_random_blob()'s first argument is a seed, and all three objects\nhave different seeds, so I don't think they would even be considered\ngood delta candidates for one another. But it's also possible that your\ngenerate_random_blob() behaves differently from my own.\n\nThanks,\nTaylor\n"},{"id":"499921","messageId":"033801dae47e$7d3a5cc0$77af1640$@nexbridge.com","threadId":"61882","inReplyTo":"ZqwvQUAqVozGHG/t@nand.local","subject":"RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-02T01:51:21Z","receivedAt":"2024-08-02T01:51:30Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Thursday, August 1, 2024 8:59 PM, Taylor Blau wrote:\n>On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@nexbridge.com wrote:\n>> ls output with second resolution is here - the file system does not have\n>nanosecond resolution despite showing zeros:\n>>\n>> /home/ituglib/randall/git/t/trash\n>> directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack:\n>> ls -la --full-time total 11 drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-\n>01 16:18:55.000000000 -0600 .\n>> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01\n>16:18:48.000000000 -0600 ..\n>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01\n>> 16:18:52.000000000 -0600\n>> pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB  217 2024-08-01 16:18:52.000000000 -\n>0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB   64 2024-08-01 16:18:52.000000000 -\n>0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n>\n>Ah, I suspect that this is even less interesting than imprecise mtime resolution. The\n>test expects that the packs are larger than 1M so that we can exercise writing\n>multiple cruft packs as part of the setup.\n>\n>But that pack is only 217 bytes, which wouldn't trigger the split. I'm suspicious that\n>it's even packing the cruft objects at all, so I'm curious if you can find $foo, $bar,\n>and $baz in the cruft pack's .idx file(s, if multiple) after the first 'git repack -d --cruft'.\n>\n>Assuming they are there, it's possible that setting repack.cruftWindow in the test\n>repository would do the trick.\n>\n>But I'm suspicious that that's even what's going on since generate_random_blob()'s\n>first argument is a seed, and all three objects have different seeds, so I don't think\n>they would even be considered good delta candidates for one another. But it's also\n>possible that your\n>generate_random_blob() behaves differently from my own.\n\nI 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.\n\n"},{"id":"499987","messageId":"040801dae528$70966d10$51c34730$@nexbridge.com","threadId":"61882","inReplyTo":"ZqwvQUAqVozGHG/t@nand.local","subject":"RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-02T22:07:55Z","receivedAt":"2024-08-02T22:08:03Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Thursday, August 1, 2024 8:59 PM, Taylor Blau wrote:\n>On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@nexbridge.com wrote:\n>> ls output with second resolution is here - the file system does not have\n>nanosecond resolution despite showing zeros:\n>>\n>> /home/ituglib/randall/git/t/trash\n>> directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack:\n>> ls -la --full-time total 11 drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-\n>01 16:18:55.000000000 -0600 .\n>> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01\n>16:18:48.000000000 -0600 ..\n>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01\n>> 16:18:52.000000000 -0600\n>> pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB  217 2024-08-01 16:18:52.000000000 -\n>0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n>> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB   64 2024-08-01 16:18:52.000000000 -\n>0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev\n>\n>Ah, I suspect that this is even less interesting than imprecise mtime resolution. The\n>test expects that the packs are larger than 1M so that we can exercise writing\n>multiple cruft packs as part of the setup.\n>\n>But that pack is only 217 bytes, which wouldn't trigger the split. I'm suspicious that\n>it's even packing the cruft objects at all, so I'm curious if you can find $foo, $bar,\n>and $baz in the cruft pack's .idx file(s, if multiple) after the first 'git repack -d --cruft'.\n>\n>Assuming they are there, it's possible that setting repack.cruftWindow in the test\n>repository would do the trick.\n>\n>But I'm suspicious that that's even what's going on since generate_random_blob()'s\n>first argument is a seed, and all three objects have different seeds, so I don't think\n>they would even be considered good delta candidates for one another. But it's also\n>possible that your\n>generate_random_blob() behaves differently from my own.\n\nThe entire final .idx file is:\n0000000 377   t   O   c  \\0  \\0  \\0 002  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n0000020  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n*\n0001500  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 002\n0001520  \\0  \\0  \\0 002  \\0  \\0  \\0 002  \\0  \\0  \\0 002  \\0  \\0  \\0 002\n*\n0001600  \\0  \\0  \\0 002  \\0  \\0  \\0 003  \\0  \\0  \\0 003  \\0  \\0  \\0 003\n0001620  \\0  \\0  \\0 003  \\0  \\0  \\0 003  \\0  \\0  \\0 003  \\0  \\0  \\0 003\n*\n0002000  \\0  \\0  \\0 003  \\0  \\0  \\0 003 316   a   1 002   ,   :   H 241\n0002020   _   K   z   h 257 266 354 363 263 274 260 315 321 377 034 222\n0002040   $ 256   ^   X 247   e   o 271 354 311   X   e 324   . 327 036\n0002060 337 226   { 226 245   y 344   Z 030 270   % 027   2 321   h 004\n0002100 262 345   j   U 003 302 375 225   d 335   = 272 207 227   ) 265\n0002120  \\0  \\0  \\0 212  \\0  \\0  \\0  \\f  \\0  \\0  \\0 267   h 306 310 310\n0002140   S 211  \\0   i   L   2   8  \\n 301   H   B 001 310 266  \\r 215\n0002160 273   y 312 253 265   V 225 350 246 212   h   Z   d   ? 313   f\n0002200 372   Z 336   3\n0002204\n\nAfter the first repack, I have the following idx files. No foo/bar/baz inside.\nThe generate_random_blob() does generate the proper amount of bytes.\nI tried changing 0xff to 0x00ff at the putchar just in case we had bad\nsign extension - that wasn't it.\n\npack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx:\n0000000 377   t   O   c  \\0  \\0  \\0 002  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n0000020  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n*\n0001500  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 002\n0001520  \\0  \\0  \\0 002  \\0  \\0  \\0 002  \\0  \\0  \\0 002  \\0  \\0  \\0 002\n*\n0001600  \\0  \\0  \\0 002  \\0  \\0  \\0 003  \\0  \\0  \\0 003  \\0  \\0  \\0 003\n0001620  \\0  \\0  \\0 003  \\0  \\0  \\0 003  \\0  \\0  \\0 003  \\0  \\0  \\0 003\n*\n0002000  \\0  \\0  \\0 003  \\0  \\0  \\0 003 316   a   1 002   ,   :   H 241\n0002020   _   K   z   h 257 266 354 363 263 274 260 315 321 377 034 222\n0002040   $ 256   ^   X 247   e   o 271 354 311   X   e 324   . 327 036\n0002060 337 226   { 226 245   y 344   Z 030 270   % 027   2 321   h 004\n0002100 262 345   j   U 003 302 375 225   d 335   = 272 207 227   ) 265\n0002120  \\0  \\0  \\0 212  \\0  \\0  \\0  \\f  \\0  \\0  \\0 267   h 306 310 310\n0002140   S 211  \\0   i   L   2   8  \\n 301   H   B 001 310 266  \\r 215\n0002160 273   y 312 253 265   V 225 350 246 212   h   Z   d   ? 313   f\n0002200 372   Z 336   3\n0002204\n\npack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.idx:\n0000000 377   t   O   c  \\0  \\0  \\0 002  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n0000020  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n*\n0001260  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0 001\n0001300  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001\n*\n0002000  \\0  \\0  \\0 001  \\0  \\0  \\0 001 255 026 276 325   L 306 034 360\n0002020   6  \\a   X   y 336 357 371   Z 351   w   Q   K   # 236 346 377\n0002040  \\0  \\0  \\0  \\f 217   S 370   7   Y   ~ 273 337 306 370 355 027\n0002060   3   I 345 316 313 317 271   ~   9 033   9 316 363 306   G   -\n0002100 207   f 224 323   1 372 021   W 037 335 206 372\n0002114\n\npack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.idx:\n0000000 377   t   O   c  \\0  \\0  \\0 002  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n0000020  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n*\n0000500  \\0  \\0  \\0  \\0  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001\n0000520  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001\n*\n0002000  \\0  \\0  \\0 001  \\0  \\0  \\0 001   O   3   o   = 363 020   T 352\n0002020 274 005 254 005 371 213 300   $ 310 340   T   #   $ 274   l 342\n0002040  \\0  \\0  \\0  \\f 270 334 232 255 252 334 022 310   +  \\0   S 375\n0002060 356  \\0   9 256 020   % 250 370 204 242   7 033   =   0 375 207\n0002100 343 352 257 374 265 021   j 214   5 026 355 243\n0002114\n\npack-c2357b2b204fda52bc1f5515de94227e1db012af.idx:\n0000000 377   t   O   c  \\0  \\0  \\0 002  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n0000020  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0\n*\n0001360  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0  \\0 001\n0001400  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001  \\0  \\0  \\0 001\n*\n0002000  \\0  \\0  \\0 001  \\0  \\0  \\0 001 275   D 330 252   -   \" 353   G\n0002020 377   p 316 364 260 273   E 321   T 236 344 234 302 311   8   h\n0002040  \\0  \\0  \\0  \\f 302   5   {   +       O 332   R 274 037   U 025\n0002060 336 224   \"   ~ 035 260 022 257 373   U   )   - 204   \" 315   v\n0002100   /   E 272   e   7 342 261 037   6 255   < 306\n0002114\n\n--Randall\n\n"},{"id":"500026","messageId":"Zq+mF2fyL5hux+3k@nand.local","threadId":"61882","inReplyTo":"040801dae528$70966d10$51c34730$@nexbridge.com","subject":"Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-08-04T16:02:31Z","receivedAt":"2024-08-04T16:02:34Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Fri, Aug 02, 2024 at 06:07:55PM -0400, rsbecker@nexbridge.com wrote:\n> After the first repack, I have the following idx files. No foo/bar/baz inside.\n> The generate_random_blob() does generate the proper amount of bytes.\n> I tried changing 0xff to 0x00ff at the putchar just in case we had bad\n> sign extension - that wasn't it.\n\nHmm. What is in these index files if not the three randomly generated\nobjects? Can you run show-index instead and share the results of that on\nthe pack(s) in your repository after the first repack, and share the\nresults with the list?\n\nI think those would be more readable than a hexdump, especially if your\nmachine random source is different than mine (in which case I can't\nguess the values of $foo, $bar, and $baz).\n\nThanks,\nTaylor\n"},{"id":"500028","messageId":"04ee01dae689$90b0e0f0$b212a2d0$@nexbridge.com","threadId":"61882","inReplyTo":"Zq+mF2fyL5hux+3k@nand.local","subject":"RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-04T16:15:41Z","receivedAt":"2024-08-04T16:15:55Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"\n\n>-----Original Message-----\n>From: Taylor Blau <me@ttaylorr.com>\n>Sent: Sunday, August 4, 2024 12:03 PM\n>To: rsbecker@nexbridge.com\n>Cc: git@vger.kernel.org\n>Subject: Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64\n>\n>On Fri, Aug 02, 2024 at 06:07:55PM -0400, rsbecker@nexbridge.com wrote:\n>> After the first repack, I have the following idx files. No foo/bar/baz inside.\n>> The generate_random_blob() does generate the proper amount of bytes.\n>> I tried changing 0xff to 0x00ff at the putchar just in case we had bad\n>> sign extension - that wasn't it.\n>\n>Hmm. What is in these index files if not the three randomly generated objects? Can\n>you run show-index instead and share the results of that on the pack(s) in your\n>repository after the first repack, and share the results with the list?\n>\n>I think those would be more readable than a hexdump, especially if your machine\n>random source is different than mine (in which case I can't guess the values of $foo,\n>$bar, and $baz).\n\nAfter git repack -d --cruft --max-cruft-size=1M &&...\n\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\nfatal: unable to read index\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.pack\nfatal: corrupt index file\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.pack\nfatal: corrupt index file\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.pack\nfatal: corrupt index file\n\nApparently, something is wrong. This is an ia64 Big Endian. Not sure that matters.\n\n"},{"id":"500029","messageId":"Zq+qHRwHC3sD14eN@nand.local","threadId":"61882","inReplyTo":"04ee01dae689$90b0e0f0$b212a2d0$@nexbridge.com","subject":"Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-08-04T16:19:41Z","receivedAt":"2024-08-04T16:19:44Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sun, Aug 04, 2024 at 12:15:41PM -0400, rsbecker@nexbridge.com wrote:\n> After git repack -d --cruft --max-cruft-size=1M &&...\n>\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n> fatal: unable to read index\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.pack\n> fatal: corrupt index file\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.pack\n> fatal: corrupt index file\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.pack\n> fatal: corrupt index file\n>\n> Apparently, something is wrong. This is an ia64 Big Endian. Not sure that matters.\n\nshow-index expects the contents of the *.idx file on stdin, not the *.pack.\n\nThanks,\nTaylor\n"},{"id":"500031","messageId":"04f101dae68c$c57574b0$50605e10$@nexbridge.com","threadId":"61882","inReplyTo":"Zq+qHRwHC3sD14eN@nand.local","subject":"RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-04T16:38:38Z","receivedAt":"2024-08-04T16:38:46Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, August 4, 2024 12:20 PM, Taylor Blau wrote:\n>On Sun, Aug 04, 2024 at 12:15:41PM -0400, rsbecker@nexbridge.com wrote:\n>> After git repack -d --cruft --max-cruft-size=1M &&...\n>>\n>> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <\n>.git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack\n>> fatal: unable to read index\n>> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <\n>.git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.pack\n>> fatal: corrupt index file\n>> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <\n>.git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.pack\n>> fatal: corrupt index file\n>> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <\n>.git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.pack\n>> fatal: corrupt index file\n>>\n>> Apparently, something is wrong. This is an ia64 Big Endian. Not sure that matters.\n>\n>show-index expects the contents of the *.idx file on stdin, not the *.pack.\n\nThis is what I get for being 1/2 asleep on Sunday.\n\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n138 ce6131022c3a48a15f4b7a68afb6ecf3b3bcb0cd (03c2fd95)\n12 d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e (64dd3dba)\n183 df967b96a579e45a18b8251732d16804b2e56a55 (879729b5)\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.idx\n12 ad16bed54cc61cf036075879deeff95ae977514b (239ee6ff)\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.idx\n12 4f336f3df31054eabc05ac05f98bc024c8e05423 (24bc6ce2)\n./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.idx\n12 bd44d8aa2d22eb47ff70cef4b0bb45d1549ee49c (c2c93868)\n\n\n"},{"id":"500033","messageId":"Zq/ElpJpbcUqB+4e@nand.local","threadId":"61882","inReplyTo":"04f101dae68c$c57574b0$50605e10$@nexbridge.com","subject":"Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-08-04T18:12:38Z","receivedAt":"2024-08-04T18:12:45Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sun, Aug 04, 2024 at 12:38:38PM -0400, rsbecker@nexbridge.com wrote:\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n> 138 ce6131022c3a48a15f4b7a68afb6ecf3b3bcb0cd (03c2fd95)\n> 12 d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e (64dd3dba)\n> 183 df967b96a579e45a18b8251732d16804b2e56a55 (879729b5)\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.idx\n> 12 ad16bed54cc61cf036075879deeff95ae977514b (239ee6ff)\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.idx\n> 12 4f336f3df31054eabc05ac05f98bc024c8e05423 (24bc6ce2)\n> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.idx\n> 12 bd44d8aa2d22eb47ff70cef4b0bb45d1549ee49c (c2c93868)\n\nOK, so it looks like the first repack is doing what we expect:\npresumably the first pack containing three objects holds the result of\n\"test_commit base\" (and contains the blob, tree, and commit objects for\ncommit \"base\"). Then I'm assuming that the remaining three packs hold\n$foo, $bar, and $baz in some unspecified order.\n\nSo I think that everything up through the first repack is doing the\nright thing.\n\n(As an aside, it took me a while to remember what was going on with this\ntest. Since it was confusing to me as its author, I figured it may be\nhelpful to spell out some of the details. We're just making sure that\npruning a cruft object works with multiple cruft packs, and we're\nadjusting the mtimes of the *.mtimes files themselves to ensure that\nthey are rewritten during the pruning repack. Those adjustments have no\nbearing on what actually gets pruned, unlike when we update the mtime of\nthe loose copy of $foo, which does affect pruning).\n\nAnyway... in your setup it looks like all three objects are gone, and we\nexpected only $foo to be pruned. So I suspect what's going on is that\nthis test takes longer than 10 seconds to run on your machine, in which\ncase it would fail as all objects would have passed the 10-second grace\nperiod.\n\nIf you apply:\n\n--- 8< ---\ndiff --git a/t/t7704-repack-cruft.sh b/t/t7704-repack-cruft.sh\nindex 71e1ef3a10..959e6e2648 100755\n--- a/t/t7704-repack-cruft.sh\n+++ b/t/t7704-repack-cruft.sh\n@@ -330,7 +330,7 @@ test_expect_success '--max-cruft-size with pruning' '\n \t\t# repack (and prune) with a --max-cruft-size to ensure\n \t\t# that we appropriately split the resulting set of packs\n \t\tgit repack -d --cruft --max-cruft-size=1M \\\n-\t\t\t--cruft-expiration=10.seconds.ago &&\n+\t\t\t--cruft-expiration=1000.seconds.ago &&\n \t\tls $packdir/pack-*.mtimes | sort >cruft.after &&\n\n \t\tfor cruft in $(cat cruft.after)\n--- >8 ---\n\n, does it still fail?\n\n(There's really no reason to have --cruft-expiration as short as 10\nseconds here, since we backdate the cruft mtimes by 10,000 seconds.)\n\nThanks,\nTaylor\n"},{"id":"500034","messageId":"04f901dae6a2$b4e0c210$1ea24630$@nexbridge.com","threadId":"61882","inReplyTo":"Zq/ElpJpbcUqB+4e@nand.local","subject":"RE: [BUG] 2.46.0 t7701.09 fails on NonStop ia64","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-08-04T19:15:39Z","receivedAt":"2024-08-04T19:15:48Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, August 4, 2024 2:13 PM, Taylor Blau wrote:\n>On Sun, Aug 04, 2024 at 12:38:38PM -0400, rsbecker@nexbridge.com wrote:\n>> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git\n>> show-index <\n>> .git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx\n>> 138 ce6131022c3a48a15f4b7a68afb6ecf3b3bcb0cd (03c2fd95)\n>> 12 d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e (64dd3dba)\n>> 183 df967b96a579e45a18b8251732d16804b2e56a55 (879729b5) ./trash\n>> directory.t7704-repack-cruft/max-cruft-size-prune: git show-index\n>> <.git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.idx\n>> 12 ad16bed54cc61cf036075879deeff95ae977514b (239ee6ff) ./trash\n>> directory.t7704-repack-cruft/max-cruft-size-prune: git show-index\n>> <.git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.idx\n>> 12 4f336f3df31054eabc05ac05f98bc024c8e05423 (24bc6ce2) ./trash\n>> directory.t7704-repack-cruft/max-cruft-size-prune: git show-index\n>> <.git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.idx\n>> 12 bd44d8aa2d22eb47ff70cef4b0bb45d1549ee49c (c2c93868)\n>\n>OK, so it looks like the first repack is doing what we expect:\n>presumably the first pack containing three objects holds the result of \"test_commit\n>base\" (and contains the blob, tree, and commit objects for commit \"base\"). Then\n>I'm assuming that the remaining three packs hold $foo, $bar, and $baz in some\n>unspecified order.\n>\n>So I think that everything up through the first repack is doing the right thing.\n>\n>(As an aside, it took me a while to remember what was going on with this test. Since\n>it was confusing to me as its author, I figured it may be helpful to spell out some of\n>the details. We're just making sure that pruning a cruft object works with multiple\n>cruft packs, and we're adjusting the mtimes of the *.mtimes files themselves to\n>ensure that they are rewritten during the pruning repack. Those adjustments have\n>no bearing on what actually gets pruned, unlike when we update the mtime of the\n>loose copy of $foo, which does affect pruning).\n>\n>Anyway... in your setup it looks like all three objects are gone, and we expected only\n>$foo to be pruned. So I suspect what's going on is that this test takes longer than 10\n>seconds to run on your machine, in which case it would fail as all objects would\n>have passed the 10-second grace period.\n>\n>If you apply:\n>\n>--- 8< ---\n>diff --git a/t/t7704-repack-cruft.sh b/t/t7704-repack-cruft.sh index\n>71e1ef3a10..959e6e2648 100755\n>--- a/t/t7704-repack-cruft.sh\n>+++ b/t/t7704-repack-cruft.sh\n>@@ -330,7 +330,7 @@ test_expect_success '--max-cruft-size with pruning' '\n> \t\t# repack (and prune) with a --max-cruft-size to ensure\n> \t\t# that we appropriately split the resulting set of packs\n> \t\tgit repack -d --cruft --max-cruft-size=1M \\\n>-\t\t\t--cruft-expiration=10.seconds.ago &&\n>+\t\t\t--cruft-expiration=1000.seconds.ago &&\n> \t\tls $packdir/pack-*.mtimes | sort >cruft.after &&\n>\n> \t\tfor cruft in $(cat cruft.after)\n>--- >8 ---\n>\n>, does it still fail?\n>\n>(There's really no reason to have --cruft-expiration as short as 10 seconds here,\n>since we backdate the cruft mtimes by 10,000 seconds.)\n\nThis worked. Even taking it down to 100 seconds also works. I suspect that the reason this previously passed was that we have an unrelated heavy use looping process on the box right now so things are taking longer. Running verbose also takes longer.\n\n"}]}