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?

Correction: this directory should move to $XDG_RUNTIME_DIR (if set).

That's the current approach I'm using, but like I said in the first message, it
feels ugly and hackish.

Okay, I now see what you mean.
autoconf.sh is a mainatiner tool and not a distribution. If your application
uses gpgme, I suggest to distribute the gpgme.m4 in the m4 directory.

I don't understand what you mean. gpgme.m4 gets installed my gpgme and thus the
AM_PATH_GPGME macro is available. There will be no pkg-config support, becuase
cusom config files are more flexible.

Fixed with git commit b74a70f.

D148: 327_libassuan-2.0.1-darwin.patch

For each test we write a log file. What is the content of conventional.test.log ?

By now, I'm running GnuPG 2.0.17 on Gentoo. The card reader completely stopped
working after upgrading to pcsc-lite 1.6.6. I tried to install GnuPG without the
pcsc-lite USE flag, but this didn't change anything either.
If somebody wants to work on the problem and needs a reader for that, I'm
willing to send it by snail mail.

Please don't report problems with a non-released development version to the
tracker. Bugs and missing features are expected. Use gnupg-devel@ instead.

As a good GNU citizen I spent some time on it and implemented PBES2 in
minip12.c. This is in master and I don't intend to backport it to 2.0.x.

Frankly, I'd prefer if gnutls would use the gnupg infrastructure instead of
duplicating everything. If they have time to add their new key derivation
feature to minip12.c; I will be glad to apply such a patch.

I appreciate that PKCS#12 is stupid and baroque, but if the goal is
interoperability with other software, it seems like other GNU tools would be a
reasonable target at least :)