The exit code alone is not sufficient to return a useful error status. Thus
Marcus is right that we can't do much and gpgconf should be used to validate the
configuration.

I am closing this bug because there was no answer to my request for a more
detailed report.

I reassign this to gnupg, because this does not seem to be related to gpgme at
all. Maybe it can be closed due to age, don't know.

I merged in the translation to the gnupg package, where dirmngr now resides.

Fixed in repository.

In this case it is a bug in poldi. Reassigning.

Dirmngr 2.1.0-gitde7cfc0 also stays active.

Testing the fix:

So, I understand this can't be fixed in software?

There is no cache for smartcards; depending on the type of smartcard they
remember their PIN until they are powered down. With the OpenPGP card you may
use the gpg forcesig subcommand to force a PIN entry for each use of the
signature key.

Oh well, the svn syncing stopped quite some time ago. Just renabled it and 347
should no be on cvs.gnupg.org

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.

Stored files can be in any encoding, as they are not displayed, so
interpretation is up to the user. But for a displayed string, the encoding matters.

Fixed today, thanks.

Fixed today, thanks.

Seems to be fixed in gpg4win 2.1.0

Clearly gpgsm outputs to stdout and gpgconf is confused by that.

There is a configure check now. I am still not happy that we sleep at all, but
thats a bigger issue.

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.

Werner, where is the patch for dirmngr 1.1.0?
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/?root=Dirmngr only goes up to rev346,
while you say rev347 has the fix. Maybe a missing sync on the svn repositories
on your part?

I can not reproduce this on Snow Leopard, I guess it has been fixed in the meantime.

Haven't had a chance to test it, I was somehow waiting for a new release.
Just made sure I get a 1.1.0 patched package to test next.

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: