Ah but now armhf and arm64 fail because of the same problem. The
connects in the Qt Testsuite fail.
As I already mentioned I think its some incompatibility between the Qt
buildflags and the QGpgME buildflags:
https://bugreports.qt.io/browse/QTBUG-36129 but I'm not sure what the
suggestion from
I don't think Barry included the patch against entropy starvation in his
PPA so It's expected that it would hang.
I've discussed possibly high resource usage of the gpgme test suite
(there were also other complaints) and we reduced it accordingly:
https://git.gnupg.org/cgi-
Regarding the armhf failure in t-thread-keylist-verify This is a test
for a race condition bug we had in the past. It's fairly resource
intensive so maybe it runs into resource problems on the armhf builder.
Maybe we can just reduce the number of threads there or disable the
test.
Regarding the
Indeed my fix was incomplete, according to your build log the gpg-agent
for the python tests is already running when the modified start-stop-
agent script is called so it was still started without debug quick
random.
This was because in difference to my local system gpg is gpg2.1 and not
gpg1 so
> https://www.python.org/dev/peps/pep-0524/
This has nothing to do with it. GpgME does not gather the entropy /
randomness itself but leaves this to libgcrypt / gpg-agent. On Linux
system this means to add some entropy from /dev/random into the mix. If
nothing is available there it will block
The Problem here is that ubuntu is shipping a gnome-keyring package that is
malicoulsly hjacking the GPG_AGENT_INFO environment variable and thus breaking
gnupg2 and software (like GPA using it).
For more information about this see: http://wiki.gnupg.org/PlatformNotes
Or the gnome-keyring
This also breaks GPA (
https://bugs.launchpad.net/ubuntu/+source/gpa/+bug/1381926 ) and S/MIME
support in Kontact.
It has required that there is a section about this in the GnuPG Wiki (
http://wiki.gnupg.org/PlatformNotes ). And related problems are
regularly raised on the gnupg-users mailing
