Control: reassign -1 gpg 2.2.45-1 Control: affects -1 + src:ostree On Sun, 27 Oct 2024 at 18:08:16 +0100, Andreas Metzler wrote: > On 2024-10-27 Simon McVittie <s...@debian.org> wrote: > [...] > > I can reproduce [a FTBFS in src:ostree]. > > Is it intentional that importing a revocation certificate, apparently > > successfully (or at least there are no obvious error/warning messages), > > is now exiting with status 2? > > > The failing test script is: > > https://sources.debian.org/src/ostree/2024.8-1/tests/test-remote-gpg-list-keys.sh/ > > and the test keys and revoation certificate can be found in: > > https://sources.debian.org/src/ostree/2024.8-1/tests/gpghome/ > > The minimal test case seems to be to expire a key and then import its > revocation certificate. .45 exits with 2 instead of success. > > -------------------- > #!/bin/sh > > MYGPGHOME=`mktemp -d` > > cp -a /tmp/ostree-2024.8/tests/gpghome/* ${MYGPGHOME}/ > gpg --homedir=${MYGPGHOME} --version > gpg --homedir=${MYGPGHOME} -K > /dev/null > > gpg --verbose --homedir=${MYGPGHOME} \ > --quick-set-expire 5E65DE75AB1C501862D476347FCA23D8472CDAFA seconds=1 > echo DEBUG quick-expire exit status $? > sleep 2 > gpg --verbose --homedir=${MYGPGHOME} --import \ > /tmp/ostree-2024.8/tests/gpghome/revocations/key1.rev > echo DEBUG import rev exit status $? > rm -rf ${MYGPGHOME} > -------------------- > > Given that gpg 2.4 does not behave this way I think this is probably not > intended.
Reassigning this to gpg on that basis. Please let me know (or report a bug upstream to https://github.com/ostreedev/ostree/issues/) if there is a workaround that ostree's test suite should be using, or if there is something that ostree should be doing differently. Thanks, smcv
