The repository contains outdated translations. Before releasing gnupg-2.0.17, I
had been poked by Werner and I have sent updated translation of gnupg2 back.
It's part of 2.0.17 release. You must have stored current translation somewhere
else.

Please use a wrapper for this. The problem with an --language option is how
should we display messages pertaining to option parsing if we don't have the
languages already set. This might lead to a mixup of languages which for sure
will yeild in complains by other users.

I merged it into gnupg where dirmngr now resides. The cs.po file there is
probably out of date anyway though and may need some massaging.

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.

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

again.

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:

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).

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.

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.

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

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 :)

i dont quite understand/agree with the last few comments, but i guess it doesnt
matter that much since the code now uses AC_PATH_TOOL which is all i wanted ;)

Okay, using AC_PATH_TOOL to implement AM_PATH_GPG_ERROR makes sense.
I changed libgpg-error and updated the macro in libgcrypt master.

The idea for a search path for a cross-build environment is not sane. If you
have a cross-build environment then it is easy to set it up correclty. If your
environment is already broken, gcrypt-config could only help by printing an
additional warning, but it will never be bulletproof.

i'm not requesting you install HOST prefixed wrappers. that would actually be
worse since people setting up cross-compile environments already generically
take care of this issue.

The compiler folks are breaking all assumptions C hackers used for decades :-(
The benefit is a little performace improvement which might be outweighted by the
bugs introduced due to the code changes required to to use gcc specific stuff or
even memcpy everything forth and back.

Libraries are a part of the application. Hiding all details of a
library is simply not possible. You suggestion does not work either;
because switching the thread system is not possible: Either you are
using thread system A or thread system B; A can't switch to B, because
it does not know about B's internals.

FWIW, I started to work on another random backend which uses /dev/random
directly. It is not yet finished, though.

Thanks for having fixed it for master. It's OK so, because a comment to Issue
1236 shows me a workaround (--allow-freeform-uid) until the next release.

Fixed for master (2.1) with commit 71e7a16.

That must be a problem of the FreeBSD ports. GnupG comes with a man page. On
my system I can do

man gpg

for th1 1.4 GnuPG and

man gpg2

for the 2.x gpg. Please report to freebsd.

FreeBSD 8.1 release :

man gpg

No manual entry for gpg

Huh? "man gpg" "man gpgsm" "man gpg-agent" ... all work perfectly for me.
For ages.

GPG needs to to run trial decryptions with all available secret keys; there is
no specific order for this. This can be improved by ordering the packets so
that those with known keys are tried first and only then the wildcard keys. The
wildcards could also be more optimized. This is a actually long standing wish
by myself but I didn't found the time to implement it. Instead I implemented
the --skip-hidden-recipients in 2.1.