Testing pinentry-qt Version: 0.8.0.svn234-0kk1 (the changelog indicates
that the change is in) on Debian Lenny with KWin from KDE 3.

No response, assuming the test was positive.

May we close this bug now?

In will include estream.h.

Works for me, thanks.

The fix applied is a pth_kill wrapper and to protect all pth calls in estream.c.
Please try ce98524.

I've now switched from gcc4.3 to gcc4.4, and this warning is no longer emitted.

Quoting my gnupg-devel mail:

D147: 331_gnupg-2.0.17-Do-not-lock-the-es_list-when-flushing-it-from-es_dei.patch

cf. Fabian Keil's mail from today to gnupg-devel.

That is a limitation of the keyservers.

We allwo only algorithms which are implemented. IDEA is not implemented because
it is patented. MD5 is implemented but too weak to be used. We won't allow that.

With 2.1 the keyserver access has been moved to dirmngr and this gives us a bit
of the framework to implement such a feature. The other missing part are meta
information in the keyring - that is also on my short list.

This has been fixed in master for quite some time.

Please let us know your operation system and the version numbers of gpg,
gpg-agent and pinentry. 2.1 is not a valid gnupg version.

Sure, you import all the keys store in secring.gpg. What you need to do is to
export the keys you want to import:

Because it is a user program and not a daemon.

1.4.0 works, indeed. I didn't realize that was the latest version. The web page
is woefully out-of-date, but following the ftp link got me what I needed.

there was no crash or disc problem. also logs are clean. only ram+swap was a few
times nearly full (so perhaps not enough for gnupg). why gnupg don't reports
problems to syslog?

This due to a system crash or a disk problem (out of space). GPG uses a
copy,change,rename scheme for any updates of a keyring file. If a problem
occurs the old keyring is still available as .tmp file. If there was a disk or
permission problem, gpg even tells you about this backup file.

If this XDG_RUNTIME_DIR is supported on most posix platforms we may look at this

again.

Scute 1.2.0 is very old. It should be fixed in 1.4.0.

Ok, using TMPDIR is great. I hope that 2.1 still provides the --no-use-standard-
socket option. Stating that "an option to specify the socket name does not make
sense because other tools need to find gpg-agent" doesn't make sense, unless gpg-
agent stopped providing $GPG_AGENT_INFO.

Actually I recently changed it to detect misconfigured cross-platform build
systems. All the m4 files are chnage from time to time; it is the same as with
libtool or config.guess.

If this XDG_RUNTIME_DIR is supported on most posix platforms we may look at this
again.

This has been changed in the current version:

That's not a bug.

Well, so be it then. I can't say I understand the decision (have you considered those
who don't need that unnecessary flexibility?), but I guess I'll just have to continue
shipping gpgme.m4 within the geany-plugins autofoo buildsys. The waf buildsys will just
have to reimplement the check. I don't look forward to the day that you guys decide to
change gpgme.m4 though, assuming that ever happens.

In particular, $XDG_RUNTIME_DIR only allows writing by the user, so if you want
to have a socket with a fixed name and no random component, you can safely do that.

Hence my followup correcting that to $XDG_RUNTIME_DIR, which if set points to a
user-specific writable directory intended for this kind of purpose (sockets and
other runtime files for user-specific daemons).

Hi Werner, David,

I suppose if we wanted to be needlessly pedantic, RFC-4880 actually specifies
JFIF (not JPEG as a whole).

If you use CMAKE, you need to write your own test. gpgme-config provides all
what you need.

We won't do that. The socket is per user and thus /var/run can't be used (no
sticky bit). In any case GnuPG is moving away from random directories to a
weel-known per-user socket. GnuPG 2.1 will have this as the default.

I am not sure what to do. Do all the display tools in common use know about
non-JFIF encoded JPEGs?