@werner, I think that the scope is different. The bug reporters' claim were basically "GnuPG's cross building is different (for them), why?". They didn't claim GnuPG were unable to be cross-build.

That is a different python binding than what we provide with gpgme. Our gpgme based binding is called "gpg" and was formerly known as "pyme". I strongly suggest to install gpgme and not to use pip because the "gpg" module over there has not been updated for quite some time.

from pip i used command
pip install gnupg

From where did you go that "python package gnupg==2.3.1" ?
Sorry, I can see what kind of Python code this is. It is not part of GnuPG, though.

"dkg (Daniel Kahn Gillmor)" <noreply@dev.gnupg.org> writes:

what's the status on this? i'd love to be able to build binaries for
both python3.6 and 3.7 for debian. as it stands right now, the
python3.7 continuous integration test for debian is failing
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/gpgme1.0/1158040/log.gz.

Frankly, I still do not understand the problems with cross-compiling. Since 2014 we support SYSROOT and the respective foo-config script is installed as $SYSROOT/bin/foo-config. This guarantees that a matching config script is used and because it is a script it works on all platforms from which we are cross-building. It is also fine to install that very script in the bin dir of the (target) host; it will work there as long as host is a Unix system. So it does not matter whether it is a plain text file (a la pgk-config) or a POSIX script. The only important thing is to really install the foo-config at SYSROOOT/bin - make install does it.

Hi Andre,

I think it has something to do with the number of files. Just encrypting / decrypting a 10GB random data file did not show a problem.

Hi Andre,
thanks for the fast feedback. I will wait for the 3.1.4 Release then and test it afterwards. If it still occurs i will update this thread. Thanks for your help!
All the best
Dorian

Hi Andre,
thanks for the feedback, will try this asap when i have the chance to get on the laptop of my co-worker. Will update you afterwards. Thanks for the help!
All the best
Dorian

Thanks for the report. Prio High as this is data loss. I won't stop the 3.1.4 release which is currently in progress though as this issue does not appear to be a regression.

Your best bet is to try it on the command line to see if that provides some more useful output:

That is a strange failure. I don't see how that can happen without a legitimate bug.

This patch D467: Enable dynamically defining pkg_config_libdir for multiarch, enables multiarch dynamic PKG_CONFIG_LIBDIR support.

what's the status on this? i'd love to be able to build binaries for both python3.6 and 3.7 for debian. as it stands right now, the python3.7 continuous integration test for debian is failing.

It seems to be a cpp problem. Andre, would you mind to take this bug?

Release today.

There is now an option in the debugging tab of the GpgOL config dialog to disable async decryption. This does not fully fix the issue but maybe mitigates it for some users that are very affected by this.

I decided today to install the beta version and give it a try, because the final version is not yet released. I still facing major problems, see attachment. The mail will not be delivered, but Outlook does not crash as before.

I finally got around to look at your examples. Sorry for the delay. I can reproduce the issue and understand the problem.

Done for libgcrypt, finally.

ntbtls adopts the way from the beginning.