{"thread":{"id":"61729","subject":"[PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","startedAt":"2024-07-03T15:38:03Z","lastAt":"2025-10-29T03:06:02Z","messageCount":14,"participants":["Todd Zullinger","Junio C Hamano","Eric W. Biederman"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"498034","messageId":"20240703153738.916469-1-tmz@pobox.com","threadId":"61729","inReplyTo":null,"subject":"[PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2024-07-03T15:37:30Z","receivedAt":"2024-07-03T15:38:03Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Hi,\n\nWhile reviewing my local build logs, I noticed a number of tests being\nskipped unintentionally.  I had not done so with any of the 2.45.0\nreleases, unfortunately, which is when this began.\n\n92 of the 202 tests in t1016-compatObjectFormat.sh are skipped due to\nthe GNUPGHOME directory missing, e.g.:\n\n    ok 5 # SKIP create a sha1 signed commit (missing GPG2)\n    ok 6 # SKIP create a sha1 signed tag (missing GPG2)\n    ok 8 # SKIP create another sha1 signed tag (missing GPG2)\n    ok 9 # SKIP merge the sha1 branches together (missing GPG2)\n\nWith these changes, they are all run (successfully). :)\n\nI presume that they have been skipped in the Github CI runs as well,\nbut I don't know that the logs show enough detail to confirm that.\n\nThanks,\nTodd\n\n\nTodd Zullinger (2):\n  t/lib-gpg: add prepare_gnupghome() to create GNUPGHOME dir\n  t/lib-gpg: call prepare_gnupghome() in GPG2 prereq\n\n t/lib-gpg.sh | 12 ++++++++----\n 1 file changed, 8 insertions(+), 4 deletions(-)\n\n-- \n2.45.2\n\n"},{"id":"498035","messageId":"20240703153738.916469-2-tmz@pobox.com","threadId":"61729","inReplyTo":"20240703153738.916469-1-tmz@pobox.com","subject":"[PATCH 1/2] t/lib-gpg: add prepare_gnupghome() to create GNUPGHOME dir","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2024-07-03T15:37:31Z","receivedAt":"2024-07-03T15:38:07Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"We create the $GNUPGHOME directory in both the GPG and GPGSSH prereqs.\nReplace the redundancy with a function.\n\nUse `mkdir -p` to ensure we do not fail if a test includes more than one\nof these prereqs.\n\nSigned-off-by: Todd Zullinger <tmz@pobox.com>\n---\n t/lib-gpg.sh | 11 +++++++----\n 1 file changed, 7 insertions(+), 4 deletions(-)\n\ndiff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\nindex add11e88fc..4e44f182bb 100644\n--- a/t/lib-gpg.sh\n+++ b/t/lib-gpg.sh\n@@ -9,6 +9,11 @@\n GNUPGHOME=\"$PWD/gpghome\"\n export GNUPGHOME\n \n+prepare_gnupghome () {\n+\tmkdir -p \"$GNUPGHOME\" &&\n+\tchmod 0700 \"$GNUPGHOME\"\n+}\n+\n test_lazy_prereq GPG '\n \tgpg_version=$(gpg --version 2>&1)\n \ttest $? != 127 || exit 1\n@@ -38,8 +43,7 @@ test_lazy_prereq GPG '\n \t\t# To export ownertrust:\n \t\t#\tgpg --homedir /tmp/gpghome --export-ownertrust \\\n \t\t#\t\t> lib-gpg/ownertrust\n-\t\tmkdir \"$GNUPGHOME\" &&\n-\t\tchmod 0700 \"$GNUPGHOME\" &&\n+\t\tprepare_gnupghome &&\n \t\t(gpgconf --kill all || : ) &&\n \t\tgpg --homedir \"${GNUPGHOME}\" --import \\\n \t\t\t\"$TEST_DIRECTORY\"/lib-gpg/keyring.gpg &&\n@@ -132,8 +136,7 @@ test_lazy_prereq GPGSSH '\n \ttest $? = 0 || exit 1;\n \n \t# Setup some keys and an allowed signers file\n-\tmkdir -p \"${GNUPGHOME}\" &&\n-\tchmod 0700 \"${GNUPGHOME}\" &&\n+\tprepare_gnupghome &&\n \t(setfacl -k \"${GNUPGHOME}\" 2>/dev/null || true) &&\n \tssh-keygen -t ed25519 -N \"\" -C \"git ed25519 key\" -f \"${GPGSSH_KEY_PRIMARY}\" >/dev/null &&\n \tssh-keygen -t rsa -b 2048 -N \"\" -C \"git rsa2048 key\" -f \"${GPGSSH_KEY_SECONDARY}\" >/dev/null &&\n-- \n2.45.2\n\n"},{"id":"498036","messageId":"20240703153738.916469-3-tmz@pobox.com","threadId":"61729","inReplyTo":"20240703153738.916469-1-tmz@pobox.com","subject":"[PATCH 2/2] t/lib-gpg: call prepare_gnupghome() in GPG2 prereq","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2024-07-03T15:37:32Z","receivedAt":"2024-07-03T15:38:11Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"The GPG2 prereq added in 2f36339fa8 (t/lib-gpg: introduce new prereq\nGPG2, 2023-06-04) does not create the $GNUPGHOME directory.\n\nTests which use the GPG2 prereq without previously using the GPG prereq\nfail because of the missing directory.  This currently affects\nt1016-compatObjectFormat.\n\nEnsure $GNUPGHOME is created in the GPG2 prereq.\n\nSigned-off-by: Todd Zullinger <tmz@pobox.com>\n---\n t/lib-gpg.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\nindex 4e44f182bb..21666b2ab0 100644\n--- a/t/lib-gpg.sh\n+++ b/t/lib-gpg.sh\n@@ -66,6 +66,7 @@ test_lazy_prereq GPG2 '\n \t\texit 1\n \t\t;;\n \t*)\n+\t\tprepare_gnupghome &&\n \t\t(gpgconf --kill all || : ) &&\n \t\tgpg --homedir \"${GNUPGHOME}\" --import \\\n \t\t\t\"$TEST_DIRECTORY\"/lib-gpg/keyring.gpg &&\n-- \n2.45.2\n\n"},{"id":"498042","messageId":"ZoV8b2RvYxLOotSJ@teonanacatl.net","threadId":"61729","inReplyTo":"20240703153738.916469-1-tmz@pobox.com","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2024-07-03T16:29:35Z","receivedAt":"2024-07-03T16:29:43Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"I wrote:\n> 92 of the 202 tests in t1016-compatObjectFormat.sh are skipped due to\n> the GNUPGHOME directory missing, e.g.:\n> \n>     ok 5 # SKIP create a sha1 signed commit (missing GPG2)\n>     ok 6 # SKIP create a sha1 signed tag (missing GPG2)\n>     ok 8 # SKIP create another sha1 signed tag (missing GPG2)\n>     ok 9 # SKIP merge the sha1 branches together (missing GPG2)\n> \n> With these changes, they are all run (successfully). :)\n> \n> I presume that they have been skipped in the Github CI runs as well,\n> but I don't know that the logs show enough detail to confirm that.\n\nD'oh!  I spoke too soon.  I'd run the test suite on several\ndifferent rpm-based hosts (Fedora 39 and Rocky 9).  Waiting\nfor the Github actions to run is what I should have done.\n\nA number of these fail, e.g.:\n\nhttps://github.com/tmzullinger/git/actions/runs/9780387020/job/27001952643#step:4:1871\n\n    Error: failed: t1016.173 Verify commit signedcommit4's sha1 oid\n    failure: t1016.173 Verify commit signedcommit4's sha1 oid \n\t    git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n\t    test_cmp ${name}_sha1 ${name}_sha1_expected\n      \n      + git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 5d70155cc40e4c16515c89ad0b11d8c691436fc4a4d3ca246669a4c21f07e454\n      + test_cmp signedcommit4_sha1 signedcommit4_sha1_expected\n      + test 2 -ne 2\n      + eval diff -u \"$@\"\n      + diff -u signedcommit4_sha1 signedcommit4_sha1_expected\n      --- signedcommit4_sha1\t2024-07-03 15:11:05.597537579 +0000\n      +++ signedcommit4_sha1_expected\t2024-07-03 15:11:05.553537766 +0000\n      @@ -1 +1 @@\n      -9179ccc5b15588bc3a45c5cc75bdec380f8ccb86\n      +c6c46f92bc2cfda57ad6bf7981fa654825376b24\n      error: last command exited with $?=1\n      not ok 173 - Verify commit signedcommit4's sha1 oid\n      #\t\n      #\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n      #\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n      #\t\n\nThis seems like it's just exposing a pre-existing failure,\nas I can't imagine how creating GNUPGHOME would cause the\nactual and expected SHA's to differ. :)\n\nPerhaps the intended gpg wrapper script which sets\n`--faked-system-time` isn't being used?\n\nI'm not sure why that would differ in the Github actions\nfrom my local builds, but I don't know what else differs in\nthe Ubuntu images and/or environment used by the actions.\n\n-- \nTodd\n"},{"id":"513283","messageId":"Z8HVkqqD054QGPIE@teonanacatl.net","threadId":"61729","inReplyTo":"ZoV8b2RvYxLOotSJ@teonanacatl.net","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2025-02-28T15:26:10Z","receivedAt":"2025-02-28T15:26:12Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Hi,\n\nI'm following up to an old thread because this test breakage\nremains.\n\nI've intended to dig into it further over the past few\nmonths but have not managed to spend enough time to work out\nthe root of the problem.\n\nI hope that someone more familiar with these tests (or\nperhaps someone with fresh eyes) will spot the problem.\n\nI wrote:\n> I wrote:\n>> 92 of the 202 tests in t1016-compatObjectFormat.sh are skipped due to\n>> the GNUPGHOME directory missing, e.g.:\n>> \n>>     ok 5 # SKIP create a sha1 signed commit (missing GPG2)\n>>     ok 6 # SKIP create a sha1 signed tag (missing GPG2)\n>>     ok 8 # SKIP create another sha1 signed tag (missing GPG2)\n>>     ok 9 # SKIP merge the sha1 branches together (missing GPG2)\n>> \n>> With these changes, they are all run (successfully). :)\n>> \n>> I presume that they have been skipped in the Github CI runs as well,\n>> but I don't know that the logs show enough detail to confirm that.\n> \n> D'oh!  I spoke too soon.  I'd run the test suite on several\n> different rpm-based hosts (Fedora 39 and Rocky 9).  Waiting\n> for the Github actions to run is what I should have done.\n> \n> A number of these fail, e.g.:\n> \n> https://github.com/tmzullinger/git/actions/runs/9780387020/job/27001952643#step:4:1871\n> \n>     Error: failed: t1016.173 Verify commit signedcommit4's sha1 oid\n>     failure: t1016.173 Verify commit signedcommit4's sha1 oid \n> \t    git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n> \t    test_cmp ${name}_sha1 ${name}_sha1_expected\n>       \n>       + git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 5d70155cc40e4c16515c89ad0b11d8c691436fc4a4d3ca246669a4c21f07e454\n>       + test_cmp signedcommit4_sha1 signedcommit4_sha1_expected\n>       + test 2 -ne 2\n>       + eval diff -u \"$@\"\n>       + diff -u signedcommit4_sha1 signedcommit4_sha1_expected\n>       --- signedcommit4_sha1\t2024-07-03 15:11:05.597537579 +0000\n>       +++ signedcommit4_sha1_expected\t2024-07-03 15:11:05.553537766 +0000\n>       @@ -1 +1 @@\n>       -9179ccc5b15588bc3a45c5cc75bdec380f8ccb86\n>       +c6c46f92bc2cfda57ad6bf7981fa654825376b24\n>       error: last command exited with $?=1\n>       not ok 173 - Verify commit signedcommit4's sha1 oid\n>       #\t\n>       #\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n>       #\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n>       #\t\n> \n> This seems like it's just exposing a pre-existing failure,\n> as I can't imagine how creating GNUPGHOME would cause the\n> actual and expected SHA's to differ. :)\n> \n> Perhaps the intended gpg wrapper script which sets\n> `--faked-system-time` isn't being used?\n> \n> I'm not sure why that would differ in the Github actions\n> from my local builds, but I don't know what else differs in\n> the Ubuntu images and/or environment used by the actions.\n\nI have run a good number of builds with the patches applied\nand t1016-compatObjectFormat regularly fails for all of the\ntests which use the GPG2 prereq.  A recent Github CI run is\nhere:\n\n    https://github.com/tmzullinger/git/actions/runs/13570544425\n\nI think this test flakiness should be fixed so that we can\napply the patch to fix the GPG2 prereq.  As it is, we're\nskipping _all_ of the tests which require GPG2.\n\nCheers,\n\n-- \nTodd\n"},{"id":"529655","messageId":"xmqqbjlump3m.fsf@gitster.g","threadId":"61729","inReplyTo":"Z8HVkqqD054QGPIE@teonanacatl.net","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-26T01:25:01Z","receivedAt":"2025-10-26T01:25:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Todd Zullinger <tmz@pobox.com> writes:\n\n> I've intended to dig into it further over the past few\n> months but have not managed to spend enough time to work out\n> the root of the problem.\n>\n> I hope that someone more familiar with these tests (or\n> perhaps someone with fresh eyes) will spot the problem.\n>> \n>> A number of these fail, e.g.:\n>> \n>> https://github.com/tmzullinger/git/actions/runs/9780387020/job/27001952643#step:4:1871\n>> \n>>     Error: failed: t1016.173 Verify commit signedcommit4's sha1 oid\n>>     failure: t1016.173 Verify commit signedcommit4's sha1 oid \n>> \t    git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n>> \t    test_cmp ${name}_sha1 ${name}_sha1_expected\n>>       \n>>       + git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 5d70155cc40e4c16515c89ad0b11d8c691436fc4a4d3ca246669a4c21f07e454\n>>       + test_cmp signedcommit4_sha1 signedcommit4_sha1_expected\n>>       + test 2 -ne 2\n>>       + eval diff -u \"$@\"\n>>       + diff -u signedcommit4_sha1 signedcommit4_sha1_expected\n>>       --- signedcommit4_sha1\t2024-07-03 15:11:05.597537579 +0000\n>>       +++ signedcommit4_sha1_expected\t2024-07-03 15:11:05.553537766 +0000\n>>       @@ -1 +1 @@\n>>       -9179ccc5b15588bc3a45c5cc75bdec380f8ccb86\n>>       +c6c46f92bc2cfda57ad6bf7981fa654825376b24\n>>       error: last command exited with $?=1\n>>       not ok 173 - Verify commit signedcommit4's sha1 oid\n>>       #\t\n>>       #\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n>>       #\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n>>       #\t\n>> \n>> This seems like it's just exposing a pre-existing failure,\n>> as I can't imagine how creating GNUPGHOME would cause the\n>> actual and expected SHA's to differ. :)\n>> \n>> Perhaps the intended gpg wrapper script which sets\n>> `--faked-system-time` isn't being used?\n>> \n>> I'm not sure why that would differ in the Github actions\n>> from my local builds, but I don't know what else differs in\n>> the Ubuntu images and/or environment used by the actions.\n>\n> I have run a good number of builds with the patches applied\n> and t1016-compatObjectFormat regularly fails for all of the\n> tests which use the GPG2 prereq.  A recent Github CI run is\n> here:\n>\n>     https://github.com/tmzullinger/git/actions/runs/13570544425\n>\n> I think this test flakiness should be fixed so that we can\n> apply the patch to fix the GPG2 prereq.  As it is, we're\n> skipping _all_ of the tests which require GPG2.\n\nAny progress or responses?  All of these tests, that nobody seemed\nto have caught breakage of because they weren't being run anyway,\nseem to be flakey with the new GNUPGHOME set-up.\n\nI am tempted to do this in the meantime, but I'd really prefer not\nto have to do so, assuming that these tests, when fixed, would be\nmaterially contributing to the health of our codebase.\n\nThanks.\n\n t/t1016-compatObjectFormat.sh | 16 ++++++++--------\n 1 file changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/t/t1016-compatObjectFormat.sh b/t/t1016-compatObjectFormat.sh\nindex be3206a16f..0968962f1d 100755\n--- a/t/t1016-compatObjectFormat.sh\n+++ b/t/t1016-compatObjectFormat.sh\n@@ -261,21 +261,21 @@ compare_oids () {\n compare_oids 'blob' hello \"$hello_sha1_oid\" \"$hello_sha256_oid\"\n compare_oids 'tree' tree \"$tree_sha1_oid\" \"$tree_sha256_oid\"\n compare_oids 'commit' commit \"$commit_sha1_oid\" \"$commit_sha256_oid\"\n-compare_oids GPG2 'commit' signedcommit \"$signedcommit_sha1_oid\" \"$signedcommit_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'commit' signedcommit \"$signedcommit_sha1_oid\" \"$signedcommit_sha256_oid\"\n compare_oids 'tag' hellotag \"$hellotag_sha1_oid\" \"$hellotag_sha256_oid\"\n compare_oids 'tag' treetag \"$treetag_sha1_oid\" \"$treetag_sha256_oid\"\n compare_oids 'tag' committag \"$committag_sha1_oid\" \"$committag_sha256_oid\"\n-compare_oids GPG2 'tag' signedtag \"$signedtag_sha1_oid\" \"$signedtag_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'tag' signedtag \"$signedtag_sha1_oid\" \"$signedtag_sha256_oid\"\n \n compare_oids 'blob' more \"$more_sha1_oid\" \"$more_sha256_oid\"\n compare_oids 'blob' another \"$another_sha1_oid\" \"$another_sha256_oid\"\n compare_oids 'tree' tree2 \"$tree2_sha1_oid\" \"$tree2_sha256_oid\"\n compare_oids 'commit' commit2 \"$commit2_sha1_oid\" \"$commit2_sha256_oid\"\n-compare_oids GPG2 'tag' signedtag2 \"$signedtag2_sha1_oid\" \"$signedtag2_sha256_oid\"\n-compare_oids GPG2 'commit' signedcommit2 \"$signedcommit2_sha1_oid\" \"$signedcommit2_sha256_oid\"\n-compare_oids GPG2 'commit' signedcommit3 \"$signedcommit3_sha1_oid\" \"$signedcommit3_sha256_oid\"\n-compare_oids GPG2 'commit' signedcommit4 \"$signedcommit4_sha1_oid\" \"$signedcommit4_sha256_oid\"\n-compare_oids GPG2 'tag' signedtag3 \"$signedtag3_sha1_oid\" \"$signedtag3_sha256_oid\"\n-compare_oids GPG2 'tag' signedtag4 \"$signedtag4_sha1_oid\" \"$signedtag4_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'tag' signedtag2 \"$signedtag2_sha1_oid\" \"$signedtag2_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'commit' signedcommit2 \"$signedcommit2_sha1_oid\" \"$signedcommit2_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'commit' signedcommit3 \"$signedcommit3_sha1_oid\" \"$signedcommit3_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'commit' signedcommit4 \"$signedcommit4_sha1_oid\" \"$signedcommit4_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'tag' signedtag3 \"$signedtag3_sha1_oid\" \"$signedtag3_sha256_oid\"\n+compare_oids GPG2,FLAKEY 'tag' signedtag4 \"$signedtag4_sha1_oid\" \"$signedtag4_sha256_oid\"\n \n test_done\n-- \n2.51.1-691-gd530f589c3\n\n\n"},{"id":"529745","messageId":"87zf9c8glu.fsf@email.froward.int.ebiederm.org","threadId":"61729","inReplyTo":"xmqqbjlump3m.fsf@gitster.g","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2025-10-27T16:16:45Z","receivedAt":"2025-10-27T16:52:47Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Todd Zullinger <tmz@pobox.com> writes:\n>\n>> I've intended to dig into it further over the past few\n>> months but have not managed to spend enough time to work out\n>> the root of the problem.\n>>\n>> I hope that someone more familiar with these tests (or\n>> perhaps someone with fresh eyes) will spot the problem.\n>>> \n>>> A number of these fail, e.g.:\n>>> \n>>> https://github.com/tmzullinger/git/actions/runs/9780387020/job/27001952643#step:4:1871\n>>> \n>>>     Error: failed: t1016.173 Verify commit signedcommit4's sha1 oid\n>>>     failure: t1016.173 Verify commit signedcommit4's sha1 oid \n>>> \t    git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n>>> \t    test_cmp ${name}_sha1 ${name}_sha1_expected\n>>>       \n>>>       + git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 5d70155cc40e4c16515c89ad0b11d8c691436fc4a4d3ca246669a4c21f07e454\n>>>       + test_cmp signedcommit4_sha1 signedcommit4_sha1_expected\n>>>       + test 2 -ne 2\n>>>       + eval diff -u \"$@\"\n>>>       + diff -u signedcommit4_sha1 signedcommit4_sha1_expected\n>>>       --- signedcommit4_sha1\t2024-07-03 15:11:05.597537579 +0000\n>>>       +++ signedcommit4_sha1_expected\t2024-07-03 15:11:05.553537766 +0000\n>>>       @@ -1 +1 @@\n>>>       -9179ccc5b15588bc3a45c5cc75bdec380f8ccb86\n>>>       +c6c46f92bc2cfda57ad6bf7981fa654825376b24\n>>>       error: last command exited with $?=1\n>>>       not ok 173 - Verify commit signedcommit4's sha1 oid\n>>>       #\t\n>>>       #\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&\n>>>       #\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n>>>       #\t\n>>> \n>>> This seems like it's just exposing a pre-existing failure,\n>>> as I can't imagine how creating GNUPGHOME would cause the\n>>> actual and expected SHA's to differ. :)\n\nHmm. Let me see.\n\nThe test goes through and creates 2 repositories, one sha1 and the other\nsha256.\n\nIn those repositories a gpg signed commit is created.\nThat gpg signed commit should contain both the signed sha1\nand the signed sha256 gpg signatures.  As both object-format\nand compat-object-format are set in the config.\n\nThen the commit is extracted and one of the signatures removed.\n\nThen the oid of the signed commit with only a single signed gpg\nsignature is computed.\n\nIn the sha256 repository the sha256 oid is given to get the sha1 oid.\n\nThat sha1 oid is of the signed gpg commit is compared with the\npreviously computed sha1 oid.\n\nSo I think a messed up GNUPGHOME could result in the wrong signing\nkey being used.  Though how that signing key could be inconsistent\nfrom one part of the test to the other I don't know.\n\nNot seeing t/t1016/gpg as the gpg program does look like a more\nlikely cause of the error there.\n\n>>> \n>>> Perhaps the intended gpg wrapper script which sets\n>>> `--faked-system-time` isn't being used?\n>>> \n>>> I'm not sure why that would differ in the Github actions\n>>> from my local builds, but I don't know what else differs in\n>>> the Ubuntu images and/or environment used by the actions.\n>>\n>> I have run a good number of builds with the patches applied\n>> and t1016-compatObjectFormat regularly fails for all of the\n>> tests which use the GPG2 prereq.  A recent Github CI run is\n>> here:\n>>\n>>     https://github.com/tmzullinger/git/actions/runs/13570544425\n>>\n>> I think this test flakiness should be fixed so that we can\n>> apply the patch to fix the GPG2 prereq.  As it is, we're\n>> skipping _all_ of the tests which require GPG2.\n>\n> Any progress or responses?  All of these tests, that nobody seemed\n> to have caught breakage of because they weren't being run anyway,\n> seem to be flakey with the new GNUPGHOME set-up.\n>\n> I am tempted to do this in the meantime, but I'd really prefer not\n> to have to do so, assuming that these tests, when fixed, would be\n> materially contributing to the health of our codebase.\n\nI just dug into this a little and hopefully I have paged enough\nstate back to understand this.\n\nIn my testing a missing GNUPGHOME appears enough to prevent the\nprerequisite from succeeding. So let's fix that. Todd Zullinger's sent\nsome nice patches to do that (up-thread), or you can take use my minimal\nversion.\n\nThe only possible source of flakiness in the tests I can see is the\npossibility of t/t1016/gpg not getting called (which uses a fixed\ntimestamp).  It appears you just fixed that problem in commit\n516bf45749bb (\"t1016: make sure to use specified GPG\").\n\nWith that commit reverted I can reproduce the flakiness locally\nby just running the test manually a few times.\n\nI believe I used the GPG2 prereq because I don't have the older version\nof GPG to test with.  So I don't know if t1016 would work on the older\nversion of GPG or not.\n\n\ndiff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\nindex 937b876bd052..c4bbedfe081e 100644\n--- a/t/lib-gpg.sh\n+++ b/t/lib-gpg.sh\n@@ -62,6 +62,8 @@ test_lazy_prereq GPG2 '\n \t\texit 1\n \t\t;;\n \t*)\n+\t\tmkdir \"$GNUPGHOME\" &&\n+\t\tchmod 0700 \"$GNUPGHOME\" &&\n \t\t(gpgconf --kill all || : ) &&\n \t\tgpg --homedir \"${GNUPGHOME}\" --import \\\n \t\t\t\"$TEST_DIRECTORY\"/lib-gpg/keyring.gpg &&\n\n\nEric\n"},{"id":"529748","messageId":"xmqqqzuoi6sg.fsf@gitster.g","threadId":"61729","inReplyTo":"87zf9c8glu.fsf@email.froward.int.ebiederm.org","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-27T17:38:39Z","receivedAt":"2025-10-27T17:38:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n\n>> I am tempted to do this in the meantime, but I'd really prefer not\n>> to have to do so, assuming that these tests, when fixed, would be\n>> materially contributing to the health of our codebase.\n>\n> I just dug into this a little and hopefully I have paged enough\n> state back to understand this.\n>\n> In my testing a missing GNUPGHOME appears enough to prevent the\n> prerequisite from succeeding. So let's fix that. Todd Zullinger's sent\n> some nice patches to do that (up-thread), or you can take use my minimal\n> version.\n\nSorry, but I am confused.  The above \"tempted to do this\" was meant\nto come on top of Todd's patches.  IOW, I was seeing flakyness with\nTodd's patches that fixed the missing GNUPGHOME.\n\n> The only possible source of flakiness in the tests I can see is the\n> possibility of t/t1016/gpg not getting called (which uses a fixed\n> timestamp).  It appears you just fixed that problem in commit\n> 516bf45749bb (\"t1016: make sure to use specified GPG\").\n\nI think that one also is in 'seen', and yet we saw t1016 flaky X-<.\n\nLet me isolate the relevant topics and test them again, i.e.\n\n    $ git checkout --detach v2.51.0\n    $ git merge --no-ff jc/t1016-setup-fix ;# 516bf45749\n    $ git merge --no-ff tz/test-prepare-gnupghome~1 ;# 6cd8369ef3\n    $ git log --no-merges --oneline v2.51.0..\n    516bf45749 (jc/t1016-setup-fix) t1016: make sure to use specified GPG\n    6cd8369ef3 t/lib-gpg: call prepare_gnupghome() in GPG2 prereq\n    a35952b493 t/lib-gpg: add prepare_gnupghome() to create GNUPGHOME dir\n    $ make\n    $ cd t && ./t1016-*.sh --stress\n    FAIL 10.1\n    FAIL  5.1\n    FAIL 34.1\n    ...\n    ++ eval 'diff -u' '\"$@\"'\n    +++ diff -u signedcommit3_sha1 signedcommit3_sha1_expected\n    --- signedcommit3_sha1\t2025-10-27 17:34:58.237496945 +0000\n    +++ signedcommit3_sha1_expected\t2025-10-27 17:34:58.145497051 +0000\n    @@ -1 +1 @@\n    -de9cabc2419f97eb665452c198ed93e890a7ef87\n    +c87cd5157461a81b60ef6d3c47562c12b328ef54\n    error: last command exited with $?=1\n    not ok 163 - Verify commit signedcommit3's sha1 oid\n    #\t\n    #\t\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} >${name}_sha1 &&\n    #\t\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n    #\t\t\n    1..163\n\n> With that commit reverted I can reproduce the flakiness locally\n> by just running the test manually a few times.\n\nThe above is with all three patches mentioned.\nFWIW, \"gpg --version | head -2\" says\n\n    gpg (GnuPG) 2.4.8\n    libgcrypt 1.11.2\n\nHmmmm.....\n\n> I believe I used the GPG2 prereq because I don't have the older version\n> of GPG to test with.  So I don't know if t1016 would work on the older\n> version of GPG or not.\n>\n>\n> diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\n> index 937b876bd052..c4bbedfe081e 100644\n> --- a/t/lib-gpg.sh\n> +++ b/t/lib-gpg.sh\n> @@ -62,6 +62,8 @@ test_lazy_prereq GPG2 '\n>  \t\texit 1\n>  \t\t;;\n>  \t*)\n> +\t\tmkdir \"$GNUPGHOME\" &&\n> +\t\tchmod 0700 \"$GNUPGHOME\" &&\n>  \t\t(gpgconf --kill all || : ) &&\n>  \t\tgpg --homedir \"${GNUPGHOME}\" --import \\\n>  \t\t\t\"$TEST_DIRECTORY\"/lib-gpg/keyring.gpg &&\n>\n>\n> Eric\n"},{"id":"529752","messageId":"875xc02mmq.fsf@email.froward.int.ebiederm.org","threadId":"61729","inReplyTo":"xmqqqzuoi6sg.fsf@gitster.g","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2025-10-27T19:03:09Z","receivedAt":"2025-10-27T20:02:32Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> \"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n>\n>> The only possible source of flakiness in the tests I can see is the\n>> possibility of t/t1016/gpg not getting called (which uses a fixed\n>> timestamp).  It appears you just fixed that problem in commit\n>> 516bf45749bb (\"t1016: make sure to use specified GPG\").\n>\n> I think that one also is in 'seen', and yet we saw t1016 flaky X-<.\n>\n> Let me isolate the relevant topics and test them again, i.e.\n>\n>     $ git checkout --detach v2.51.0\n>     $ git merge --no-ff jc/t1016-setup-fix ;# 516bf45749\n>     $ git merge --no-ff tz/test-prepare-gnupghome~1 ;# 6cd8369ef3\n>     $ git log --no-merges --oneline v2.51.0..\n>     516bf45749 (jc/t1016-setup-fix) t1016: make sure to use specified GPG\n>     6cd8369ef3 t/lib-gpg: call prepare_gnupghome() in GPG2 prereq\n>     a35952b493 t/lib-gpg: add prepare_gnupghome() to create GNUPGHOME dir\n>     $ make\n>     $ cd t && ./t1016-*.sh --stress\n>     FAIL 10.1\n>     FAIL  5.1\n>     FAIL 34.1\n>     ...\n>     ++ eval 'diff -u' '\"$@\"'\n>     +++ diff -u signedcommit3_sha1 signedcommit3_sha1_expected\n>     --- signedcommit3_sha1\t2025-10-27 17:34:58.237496945 +0000\n>     +++ signedcommit3_sha1_expected\t2025-10-27 17:34:58.145497051 +0000\n>     @@ -1 +1 @@\n>     -de9cabc2419f97eb665452c198ed93e890a7ef87\n>     +c87cd5157461a81b60ef6d3c47562c12b328ef54\n>     error: last command exited with $?=1\n>     not ok 163 - Verify commit signedcommit3's sha1 oid\n>     #\t\n>     #\t\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} >${name}_sha1 &&\n>     #\t\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n>     #\t\t\n>     1..163\n\nInteresting.  With --stress I can reproduce the flakiness locally as\nwell.\n\nI am starting to dig any but I haven't found any smoking guns yet.  So\nfar manually running the commands that resulted in the failure are\ngiving me the same output, but I have several more to run.\n\n>> With that commit reverted I can reproduce the flakiness locally\n>> by just running the test manually a few times.\n>\n> The above is with all three patches mentioned.\n> FWIW, \"gpg --version | head -2\" says\n>\n>     gpg (GnuPG) 2.4.8\n>     libgcrypt 1.11.2\n>\n> Hmmmm.....\n\nI have gpg 2.4.7 but otherwise things are identical.\n\nEric\n"},{"id":"529754","messageId":"87o6ps16pj.fsf@email.froward.int.ebiederm.org","threadId":"61729","inReplyTo":"875xc02mmq.fsf@email.froward.int.ebiederm.org","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2025-10-27T19:32:24Z","receivedAt":"2025-10-27T20:17:35Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> \"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n>>\n>>> The only possible source of flakiness in the tests I can see is the\n>>> possibility of t/t1016/gpg not getting called (which uses a fixed\n>>> timestamp).  It appears you just fixed that problem in commit\n>>> 516bf45749bb (\"t1016: make sure to use specified GPG\").\n>>\n>> I think that one also is in 'seen', and yet we saw t1016 flaky X-<.\n>>\n>> Let me isolate the relevant topics and test them again, i.e.\n>>\n>>     $ git checkout --detach v2.51.0\n>>     $ git merge --no-ff jc/t1016-setup-fix ;# 516bf45749\n>>     $ git merge --no-ff tz/test-prepare-gnupghome~1 ;# 6cd8369ef3\n>>     $ git log --no-merges --oneline v2.51.0..\n>>     516bf45749 (jc/t1016-setup-fix) t1016: make sure to use specified GPG\n>>     6cd8369ef3 t/lib-gpg: call prepare_gnupghome() in GPG2 prereq\n>>     a35952b493 t/lib-gpg: add prepare_gnupghome() to create GNUPGHOME dir\n>>     $ make\n>>     $ cd t && ./t1016-*.sh --stress\n>>     FAIL 10.1\n>>     FAIL  5.1\n>>     FAIL 34.1\n>>     ...\n>>     ++ eval 'diff -u' '\"$@\"'\n>>     +++ diff -u signedcommit3_sha1 signedcommit3_sha1_expected\n>>     --- signedcommit3_sha1\t2025-10-27 17:34:58.237496945 +0000\n>>     +++ signedcommit3_sha1_expected\t2025-10-27 17:34:58.145497051 +0000\n>>     @@ -1 +1 @@\n>>     -de9cabc2419f97eb665452c198ed93e890a7ef87\n>>     +c87cd5157461a81b60ef6d3c47562c12b328ef54\n>>     error: last command exited with $?=1\n>>     not ok 163 - Verify commit signedcommit3's sha1 oid\n>>     #\t\n>>     #\t\t\tgit --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} >${name}_sha1 &&\n>>     #\t\t\ttest_cmp ${name}_sha1 ${name}_sha1_expected\n>>     #\t\t\n>>     1..163\n>\n> Interesting.  With --stress I can reproduce the flakiness locally as\n> well.\n>\n> I am starting to dig any but I haven't found any smoking guns yet.  So\n> far manually running the commands that resulted in the failure are\n> giving me the same output, but I have several more to run.\n\nSo far in the two should be identical sha1 and sha256 repositories\nI can confirm the failure is because the repositories are out of sync.\n\nThe sha256 gpg signatures match\nThe sha1 gpg signatures do not match\n\nWhich is very weird.  If they both didn't match it would be easy to\nexplain.\n\nThis is starting to look like this is a case of the test doing it's job\nand finding a problem, rather than a problem in the test infrastructure.\n\nI will keep digging.\n\ngit/t/trash directory.t1016-compatObjectFormat.stress-failed$ ../../git --git-dir=repo-sha256/.git cat-file tag signedtag34\nobject 94ee57ed028bc464ec9f9dc1d9c4b8c09fd89ac00e34b2bae3105803a995a6cd\ntype commit\ntag signedtag34\ntagger C O Mitter <committer@example.com> 1112354055 +0200\ngpgsig -----BEGIN PGP SIGNATURE-----\n \n iHQEABECADQWIQRz11h0S+chaY7FTocTtvUezd5DDQUCZQhxPBYcY29tbWl0dGVy\n QGV4YW1wbGUuY29tAAoJEBO29R7N3kMN3wIAoLYbVnmMIQnKqAfCDEtLGKDgH+M4\n AKDNi19wI7o7yWzThiujYZ422iMRGA==\n =lsWm\n -----END PGP SIGNATURE-----\n \nThis is an additional signed tag\n-----BEGIN PGP SIGNATURE-----\n \niHQEABECADQWIQRz11h0S+chaY7FTocTtvUezd5DDQUCZQhxPBYcY29tbWl0dGVy\nQGV4YW1wbGUuY29tAAoJEBO29R7N3kMN21sAn2RYjMjcngN6AqBeo9RmIUn7NnWY\nAJ97WUStWCcHXMkxU+HVPeuA/CvPYw==\n=7Jpz\n-----END PGP SIGNATURE-----\ngit/t/trash directory.t1016-compatObjectFormat.stress-failed$ ../../git --git-dir=repo-sha1/.git cat-file tag signedtag34\nobject 9ea30d18399b9957ce40766318510dab211d747b\ntype commit\ntag signedtag34\ntagger C O Mitter <committer@example.com> 1112354055 +0200\ngpgsig-sha256 -----BEGIN PGP SIGNATURE-----\n \n iHQEABECADQWIQRz11h0S+chaY7FTocTtvUezd5DDQUCZQhxPBYcY29tbWl0dGVy\n QGV4YW1wbGUuY29tAAoJEBO29R7N3kMN21sAn2RYjMjcngN6AqBeo9RmIUn7NnWY\n AJ97WUStWCcHXMkxU+HVPeuA/CvPYw==\n =7Jpz\n -----END PGP SIGNATURE-----\n \nThis is an additional signed tag\n-----BEGIN PGP SIGNATURE-----\n \niHQEABECADQWIQRz11h0S+chaY7FTocTtvUezd5DDQUCZQhxPRYcY29tbWl0dGVy\nQGV4YW1wbGUuY29tAAoJEBO29R7N3kMNvn4AmwRHkPsmDmKgUB6r1XP4dSzXWw+G\nAKCEzEgk2bHuKv6d2L/M0bzseGlOfA==\n=G+Gp\n-----END PGP SIGNATURE-----\n\nEric\n"},{"id":"529755","messageId":"xmqqms5chyr8.fsf@gitster.g","threadId":"61729","inReplyTo":"87o6ps16pj.fsf@email.froward.int.ebiederm.org","subject":"Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-27T20:32:11Z","receivedAt":"2025-10-27T20:32:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n\n> So far in the two should be identical sha1 and sha256 repositories\n> I can confirm the failure is because the repositories are out of sync.\n>\n> The sha256 gpg signatures match\n> The sha1 gpg signatures do not match\n>\n> Which is very weird.  If they both didn't match it would be easy to\n> explain.\n>\n> This is starting to look like this is a case of the test doing it's job\n> and finding a problem, rather than a problem in the test infrastructure.\n>\n> I will keep digging.\n\nThanks.\n"},{"id":"529795","messageId":"87frb310d2.fsf_-_@email.froward.int.ebiederm.org","threadId":"61729","inReplyTo":"xmqqms5chyr8.fsf@gitster.g","subject":"[PATCH] t1016-compatObjectFormat: Really freeze time for reproduciblity","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2025-10-28T16:01:45Z","receivedAt":"2025-10-28T16:01:51Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\nThe strategy in t1016-compatObjectFormat is to build two trees with\nidentical commits, one tree encoded in sha1 the other tree encoded\nin sha256 and to use the compatibility code to test and see if\nthe two trees are identical.\n\nGPG signatures include the current time as part of the signature.\n\nTo make gpg deterministic I forced the use of gpg --faked-system-time.\nUnfortunately I did not look closely enough.\n\nBy default gpg still allows time to move forward with --faked-system-time.\nSo in those rare instances when the system is heavily loaded an gpg runs\nslower than other times, signatures over the exact same data differ\ndue to timestamps with a minuscule difference.\n\nReading through the gpg documentation with a close eye, time can be\nfrozen by including an exclamation point at the end of the argument to\n--faked-system-time.\n\nAdd the exclamation point so gpg really runs with a fixed notion of time,\nresulting in the exact same data having identical gpg signatures.\n\nThat is enough that I can run \"t1016-compatObjectFormat.sh --stress\"\nand I don't see any failures.\n\nIt is possible a future change to gpg will make replay protection more\nrobust and not provide a way to allow two separate runs of gpg to\nproduce exactly the same signature for exactly the same data.  If that\nhappens a deeper comparison of the two repositories will need to be\nperformed.  A comparison that simply verifies the signatures and\ncompares the data for equality.  For now that is a lot of work\nfor no gain so I am just documenting the possibility.\n\nSigned-off-by: Eric W. Biederman <ebiederm@xmission.com>\n---\n t/t1016-compatObjectFormat.sh | 6 ++++++\n t/t1016/gpg                   | 2 +-\n 2 files changed, 7 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t1016-compatObjectFormat.sh b/t/t1016-compatObjectFormat.sh\nindex a9af8b239626..0efce53f3aad 100755\n--- a/t/t1016-compatObjectFormat.sh\n+++ b/t/t1016-compatObjectFormat.sh\n@@ -21,6 +21,12 @@ test_description='Test how well compatObjectFormat works'\n # different hash functions result in the same content in the commits.\n # This means that when the commit is translated between hash functions\n # the commit is identical to the commit in the other repository.\n+#\n+# Similarly this test relies on:\n+#\tgpg --faked-system-time '20230918T154812!\n+# freezing the system time from gpg perspective so that two different\n+# runs of gpg applied to the same data result in identical signatures.\n+#\n \n compat_hash () {\n \tcase \"$1\" in\ndiff --git a/t/t1016/gpg b/t/t1016/gpg\nindex 2601cb18a5b3..34d6e055fc9e 100755\n--- a/t/t1016/gpg\n+++ b/t/t1016/gpg\n@@ -1,2 +1,2 @@\n #!/bin/sh\n-exec gpg --faked-system-time \"20230918T154812\" \"$@\"\n+exec gpg --faked-system-time '20230918T154812!' \"$@\"\n-- \n2.41.0\n\n"},{"id":"529802","messageId":"xmqqv7jzc5hw.fsf@gitster.g","threadId":"61729","inReplyTo":"87frb310d2.fsf_-_@email.froward.int.ebiederm.org","subject":"Re: [PATCH] t1016-compatObjectFormat: Really freeze time for reproduciblity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-28T17:15:23Z","receivedAt":"2025-10-28T17:15:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n\n> By default gpg still allows time to move forward with --faked-system-time.\n> So in those rare instances when the system is heavily loaded an gpg runs\n> slower than other times, signatures over the exact same data differ\n> due to timestamps with a minuscule difference.\n>\n> Reading through the gpg documentation with a close eye, time can be\n> frozen by including an exclamation point at the end of the argument to\n> --faked-system-time.\n> ...\n>  t/t1016-compatObjectFormat.sh | 6 ++++++\n>  t/t1016/gpg                   | 2 +-\n>  2 files changed, 7 insertions(+), 1 deletion(-)\n\nGeez, how are we expected to find the need for '!' ourselves X-<.\n\nThanks for root causing the issue so quickly once it was raised.\n\nAnd let me drop the \"let's disable flakey ones\" band-aid patch from\nthe queue.\n\n"},{"id":"529852","messageId":"aQGEl6Y-BaHsLphW@teonanacatl.net","threadId":"61729","inReplyTo":"xmqqv7jzc5hw.fsf@gitster.g","subject":"Re: [PATCH] t1016-compatObjectFormat: Really freeze time for reproduciblity","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2025-10-29T03:05:59Z","receivedAt":"2025-10-29T03:06:02Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Junio C Hamano wrote:\n> \"Eric W. Biederman\" <ebiederm@xmission.com> writes:\n> \n>> By default gpg still allows time to move forward with --faked-system-time.\n>> So in those rare instances when the system is heavily loaded an gpg runs\n\ns/an/&d/\n\n>> slower than other times, signatures over the exact same data differ\n>> due to timestamps with a minuscule difference.\n>>\n>> Reading through the gpg documentation with a close eye, time can be\n>> frozen by including an exclamation point at the end of the argument to\n>> --faked-system-time.\n>> ...\n>>  t/t1016-compatObjectFormat.sh | 6 ++++++\n>>  t/t1016/gpg                   | 2 +-\n>>  2 files changed, 7 insertions(+), 1 deletion(-)\n> \n> Geez, how are we expected to find the need for '!' ourselves X-<.\n> \n> Thanks for root causing the issue so quickly once it was raised.\n\nI'll second that.  Nicely sleuthed and explained.\n\nIt explains why I had trouble that I thought looked like gpg\nwasn't setting the time as expected, long before the code\nchange which caused the custom gpg wrapper to not be used by\nall the tests.\n\nBack then, I went so far as to run the whole test suite with\nthe gpg wrapper setting --faked-system-time, but I didn't\nnotice the crucial lack of an exclamation point on the time\neither.\n\nI applied this and Junio's previous patch to ensure the\nwrapper is always used on top of 2.51.2¹ and ran it through\nthe Fedora build system where I consistently saw failures\nbefore.  With this patch it all worked as expected.\n\n¹ It's much easier for me to test a released tarball with\n  the existing Fedora packaging than a snapshot of next;\n  even though I know it's of *slightly* less value than\n  testing the tip of next or seen.\n\nThanks!\n\n-- \nTodd\n"}]}