Use the pdf version.
An info file will be installed with gnupg.

D144: 317_gnupg-2.1-liblber.patch

D143: 316_libgcrypt-tests-ldadd.patch

Should probably beretested with Gnupg 2.1(beta or later)
because agent startup might have changed.

The fix in 1.4.11 did not work. See
http://lists.gnupg.org/pipermail/gnupg-devel/2010-October/025805.html
for a working patch.

Hello,
libgcrypt 1.4.6

http://pkgs.fedoraproject.org/gitweb/?p=libgcrypt.git;a=blob_plain;f=libgcrypt-1.4.5-ImplicitDSOLinking.patch;hb=HEAD

Sure. That is the actual goal of the light package.

Given that we don't install a HOST-gpg-error-config tool, it does not make sense
to look for it.

The given patch URL is not valid.

2.1 will fix that.

What version of libgcrypt are you using (gpg-agent --version)?

Thanks for testing.

Testing suggests that the "can't connect my own socket: Invalid value passed to
IPC" gpg-agent issue has been resolved.

Revision 389 compiled fine - many thanks!

Hello Werner,

Hallo Werner!

For the given use case you should ask the former employee to revoke the uid.
And in case you can't contact him, the signers may revoke their signatures
(--edit-key, "revsig").

D139: 315_stable-2-0.diff

Oops cruft in the stable-2-0.diff use this version instead and delete the first one.

STABLE-2-0.diff

D140: 314_stable-2-0.diff

STABLE-1-4 patch

D141: 313_stable-1-4.diff

D142: 312_trunk.diff

A colleague just observed that expiration dates are also missing when
--list-secret-keys is used without a matching string.

I would just like to add that this problem only happens when gpg-agent is _not_
being used, and it disappears completely if gpg-agent is used.

Well, ce-server.c is code we used for some tests on WindowsCE. There is no need
to build it on other platforms. I disabled building ce-server.

Any update?!?

The problem was an old /tmp/keyring-RT77ms which contained three file: control,
gpg and pkcs11. I think this happened when I had both an Openpgp card and a
PKCS#11 plugged in at the same time. At that time I ran a gpg --card-status and I
could see that two cards were detected but I was not able to access the OpenPGP
one.

Shame on me. I have use_agent in my gpg.conf but don't have the gpg-agent
started. Commenting out this line gave me access to the card again. This is weird
because earlier today I would get a simple warning about missing gpg-agent and
that /tmp/xxx is not available.

As I already explained: It works for me using the qt pinentry!

The release pinentry 0.8.0 version (from 2010-03-03) is based on svn222 (see
tags(pinentry-0.8.0).

Use the released 0.8.0 qt pinentry and not some earlier (i.e. -svnXXX versions).

Because we have not done a regular release yet. However a release candidate has
been published: (cf. ftp://ftp.gcrypt.org:gcrypt/alpha/gnupg01.4.11rc1.tar.bz2)

This has been fixed in the SVN.

Changed to "the following key" for GnuPG 2.0 and 2.1.

Hum, so why am i having this bug while running the last version of gnupg?

Just to make sure:
I tested with gnupg 2.0.16 + pinentry 0.8.0-svn234.
You say that I should test gnupg 2.0.16 + pinentry 0.8.0-svn237.
Right?
(But in T1237 (wk on Sep 28 2010, 01:05 PM / Roundup) you wrote: "you need a newer gnupg".)

2.0.16 should be sufficient, though. Just use a recent pinentry-qt.

Right, you need a newer gnupg. Pinentry has no i18n support, thus your tests
are pointless.

Fixed in SVN for a very long time.

This was already fixed the day after the release. Please check the SVN or the
recently published release candidate.

Fix confirmed. Tested with gpg4win 2.1.0-svn1569.
So resolved.