Fixed in 348da58fe0c3656e6177c98fef6b4c4331326c8e.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 30 2017
Well, if you ask *this* nicely, then I will most certainly get *right* to it.
You know what I find annoying? Me writing tests, and then on the first sight of
trouble, we back them out or disable them.
Then please fix that. TBH I find it annoying that you did not check that your
commit actually solves the problem. I mean just using the "stable" branch would
have been enough to see that.
It's important that GPGME builds / runs against all versions of GnuPG and most
distros treat test failures as build failures. Now 1.9 will again need patches
or the python bindings disabled which is creating unnecessary work downstream
which already had enough work with the recent releases.
Indeed. We did not address the issues at all, we decided to skip all tests and
some fell through the cracks.
Unfortunately 1.9.0 doesn't address fully the issues:
[ 108s] Traceback (most recent call last):
[ 108s] File "./t-protocol-assuan.py", line 27, in <module>
[ 108s] err = c.assuan_transact('nop')
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/core.py", line 790, in assuan_transact
[ 108s] errorcheck(err)
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/errors.py", line 62, in errorcheck
[ 108s] raise GPGMEError(retval, extradata)
[ 108s] gpg.errors.GPGMEError: GPGME: IPC connect call failed
Two tests fail.
Mar 29 2017
gnupg2-2.1.19-1.fc27.x86_64
libgpg-error-1.27-1.fc27.x86_64
libassuan-2.4.3-2.fc26.x86_64
Which version of _GnUPG_ are you using?
Mar 28 2017
Yep
Andre, can we close this bug?
1.9.0 has been released.
I have noced that you added the C++ interface. Thanks.
I see. Let's get back to this after the release of 1.9
What about gpgme_get_dirinfo ("agent-socket")?
I did not know about that, and that helps a bit, but has the downside that it
uses the GNUPGHOME from the process' environment.
I'm thinking about the following use case. I have created an ephemeral home
directory to contain the results or side-effects of some operation, and now I
want to talk to the agent that serves that particularly home directory. I
cannot use gpgme_get_dirinfo because that uses GNUPGHOME, and I don't want to
change the environment variable because that is a process-global thing and I
don't want to interfere with other threads.
Mar 27 2017
What about
gpgme_get_dirinfo ("agent-socket")
? For testing you can use
GNUPGHOME=/foo/bar gpgme/tests/t-engine-info 2>&1 | grep agent-info
As of 348da58fe0c3656e6177c98fef6b4c4331326c8e all Python tests are skipped with
GnuPG < 2.1.12.
Mar 24 2017
I concur. We should disable the Python tests for gnupg versions < 2.1.12 (which
is about a year old)
I've rebased the patches against 1.8.0 but I still saw 22 failing python tests
with 2.0.26
Master fails for me even harder with 36 tests failing.
The gpg-connect-agent call's fail because --agent-program is not supported. In
master we even have --debug-quick-random which is even more recent (but which we
would also need in random starved environments like build daemons)
My preferred solution at this point would be to just say for 2.0.x the python
tests are unsupported and disabled completely. All the problems are with our
agent setup regarding the test suite and not really with functionality.
Mar 23 2017
Sorry, the test case code is here: https://github.com/rethab/h-
gpgme/blob/master/test/KeyTest.hs#L91
The removeKey function code is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64
I hope the attached log helps. The log is a test of this command:
GPGME_DEBUG=9:/home/dmp1ce/Projects/DMSS/h-gpgme/mygpgme.log ./runtests remove_alice_key_prompt
The test is creating a GPG context directory, creating a temporary key and then deleting it. The
log should show me manually confirming to delete the key. I would like the delete prompt to be
suppressed with an automatic deletion of the key. I didn't see any way of suppressing the
confirmation in the documentation here:
https://www.gnupg.org/documentation/manuals/gpgme/Deleting-Keys.html#Deleting-Keys
The code to the test case is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64
The test is running the function c'gpgme_op_delete which is a binding to the c function
gpgme_op_delete. Source code for the binding is here: https://github.com/jwiegley/bindings-
dsl/blob/master/bindings-gpgme/src/Bindings/Gpgme.hsc#L534
Mar 22 2017
The log indeed does not match the former gpgme2.trace.
I would try to switch to gpgme 1.8.0 so see whether you can still reproduce the
problem.
Right now it seems to be complaining about an expired key.
(Could be that this is a different error than originally reported because it's
been some time...)
Mar 21 2017
Thanks. So gpgsm is started but terminates before it can actually receive a
command from GPGME. Can you please add
log-file /bar/bar/gpgsm.log
debug 1024
verbose
to ~/.gnupg/gpgsm.conf and run the test again. Please post the log again.
Can you provide a plain C test program to show the effect or, maybe easier a
GPGME trace file running your program?
GPGME_DEBUG=9:gpgme.trace: YOURTESTPGM
See tests/run-genkey --set-primary on how to use it.
commit 421ddd1 implements that for 1.9.0.
I'm maintaining a language binding. https://github.com/rethab/h-gpgme
I've run mutt as suggested on the troublesome email; the resulting log is attached.
To debug this you need to run mutt like this:
GPGME_DEBUG=9:gpgme.trace: mutt
The trace file will be pretty verbose but contains everything GPGME sees from
the engine.
What do you mean by "maintainig a GPGME library"? A language binding or an
implementaion similar to GPGME?
I close this one. An implementation is already in master.
Duplicate of T2819
Done with commit 35023f3.
I modified the patch slighly, added docs and a --from-file to run-keylist.
You may want to add a C== and Qt interface.
Mar 20 2017
Unfortunately I'm unable to test this properly, because the patches can't be
applied properly to 1.8.0 (I need to add them to the package).
FYI this is:
Skip tests if GnuPG is too old.
Use 'gpg-agent --allow-loopback-pinentry' if applicable.
So this is about the new Python binding.
I would suggest not to build tye python support on systems with the old 2.0.24.
Note that 2.0 will reach EOL in 9 months.
Mar 8 2017
gnupg fixed in dd60e868d2bf649a33dc96e207ffd3b8ae4d35af.
ntbtls fixed in e582e91e47a164816ac074b9078dbed8537601dc.
libgcrypt fixed in 654024081cfa103c87bb163b117ea3568171d408.
libksba fixed in 561d03a008150c201ece22b29c97b24a1f6bf590.
libassuan fixed in b26b73d04bff10852382113ae361ea5726661510.
libgpg-error fixed in 5e51b642f747547c737a7abbc37e65b0f630d188.
Mar 2 2017
Duplicate of T2962
Mar 1 2017
I addressed this for GPGME in 60273e8b2c11d42215a5707bc55e3e0d8f350e07 but
apparently forgot to mention that here.
I'll keep the bug open until I fixed this in all packages.
Feb 16 2017
Feb 13 2017
Thank you very much. Straightforward fix. Applied the patch.
Delegating to our resident C++ expert.
Feb 11 2017
Jan 25 2017
Merged in 9291ebaa4151a1f6c8c0601095ec45809b963383.