Please describe the problem.
While running tests on a local HPC with
(datalad) [discovery7 tmp]$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
(datalad) [discovery7 tmp]$ gpgconf --version
gpgconf (GnuPG) 2.0.22
Copyright (C) 2013 Free Software Foundation, Inc.
3 tests (also failed in another more "prolific in fails" run failed due to
(datalad) [d31548v@discovery7 tmp]$ grep -B1 FAIL annex-8.20210803-g99bb214-1.log
gpgconf: invalid option "--kill"
FAIL (18.37s)
--
gpgconf: invalid option "--kill"
FAIL (16.43s)
--
gpgconf: invalid option "--kill"
FAIL (17.07s)
Not sure if you would like to do anything on git-annex level (skip those tests on outdated etc)...
Meanwhile - adding gnupg >=2.1.1 dependency to conda build: https://github.com/conda-forge/git-annex-feedstock/pull/126
It already ignores nonzero exit status of that command, since old gpg's don't support it.
So, it must not really be the
gpgconf --killthat is causing the test failure.Please post the actual test failure message.
full log is available for another issue http://www.onerussian.com/tmp/git-annex-noretry+pidlock1-1.log which shows the same error as well.
FWIW
From the log:
That is not really be a problem with gpgconf --kill, but a problem talking to gpg-agent.
The same crypto test fails a couple more times in that log, like this:
That is also not a problem with gpgconf --kill, it's actually due to an earlier test failure, unrelated to this. That earlier failure was the one the other issue was about, which has since been fixed. So we can ignore these I think, leaving only the one above as an unexplained failure.
"gpg: can't connect to the agent: Invalid value passed to IPC" could be some kind of gpg bug. I found some other instances of gpg failing that way. One involved using --homedir (similar to the test suite's use of GNUPGHOME) but on windows. https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056817.html And here's another one, in WSL when apt runs gpg. https://github.com/microsoft/WSL/issues/5125
Perhaps this is a problem with the location of the gpg agent socket in the filesystem that git-annex test is running in. That somehow messes up not creation of that socket, but later use of it. It seems that the earlier self-test of the test harness did not trigger the problem though, which is odd because it sets up a gpg private key and I'd think would use the agent too.
In b426ff682570d8600dc8025bbcd20aa95819a7e4 I considered putting the gpg directory inside the system temp dir, which would perhaps avoid the problem here. I've made that change.
Please test a fresh build on this system again, if you can..
so I should try with outdated gpgconf on some older CentOS? ..already done - we do run annex tests daily on ndoli (part of discovery) now and apparently: tests passed, but it did have those reports
Ok, that is behaving as expected then, it ignores failure to support older gpgs. Going to close this.