Fixed for 1.4.13 (e3e5406)

I would say this should go into 2.1.

This is not a bug. The description of --max-cache-ttl reads:

  Set the maximum time a cache entry is valid to @var{n} seconds.  After
  this time a cache entry will be expired even if it has been accessed
  recently.  The default is 2 hours (7200 seconds).

Thus even if you set the cache-ttl-ssh > max-cache-ttl, it will expire after
max-cache-ttl seconds.

May I ask for the status of this bug?

May I ask what happen with this bug?

Just trying to keep track of these bugs in Debian Bug Tracking System.

Sorry for reviving this bug, but, What is this implemented in gpg 1.4.x series?

Or this is going to be in the gpg 2.x series?

No, I can't reproduce the problem. I just came to check the status of the bug.
Thanks for the info werner.

The first example runs gpg on a file and displays what it sees in the file. The
--with-fingerprint only adds the fingerprint. The second example is a shortcut
for --list-keys --with-fingerprint and lists the keys known to gpg.

Given that running gpg on any file is not well defined; I would consider this a
minor bug. However, gpg 2.1 messes the output completely up and thus I need to
do something for it. But not for 1.4.

It was set to resolved in 2011 because I was not able to replicate it. Are you
now able to replicate the problem?

Hi!

These options are going to be removed from the manpage?

Hi!

Is this bug solved? And if yes, in what version is resolved?

The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be
able to do what we can do with this combination.

Please disregard my stupid comments about GPA. I was on the wrong track.

That is actually a bug.

I will consider that for 2.1. Doing it for 1.4 will break all translations and
thus I don't belive it will be an improvement in the end.

We don't see a reason for this. 2k is the current best practise. See the long
discussions on gnupg-users which pop up every few months.

I need to verify this. It is possible that we do a keylisting while importing
keys and the keylisting prints to stdout. If that is the case, we can't change
it because gpgme and scripts may reply on it.

Using --quiet for --refresh-keys makse sens, though.

You mean there is a useless process running which should better be killed, right?

Another user reported in this (I can verify it):

During a full refresh of the keyring, gpg seems to output all information
to STDERR and STDOUT. This makes it inconvenient to have a cron job to refresh
keys, because it can result in a very large and fairly useless mail.

Please ensure that normal output goes to STDOUT and errors and warnings to
STDERR so that problems aren't lost in the noise from this command.

Indeed some "normal" messages go to stderr and some warnings go to stdout.

This won't add a dependency on pkg-config. The reporter requests, that you
ship a .pc file, so packages dependening on gpgme can use pkg-config to
determine compiler and linker flags when building against gpgme. There is no
request to make gpa use pkg-config.

Done. Thanks.

In general I don't like pkg-config because it adds an extra dependecy above the
required libraries and introduces other problems. However, for GPA we already
have lot of dependencies and thus I would accept a patch.

Fixed for 2.0.19 (8b9fb19).

Fixed in GIT master (0ad03d2). Will go into future releases of all branches.

Fixed in commit 1ce38d7

This has been fixed in master for quite some time.

Fixed with with commit d0a9b8a

Oh well, we use an old copy of gpg-zip.1 from Debian for 1.4. I replaced it
with a texinfo generated file from master. Commit 75d62be.

Well, not a functional bug. I'll fix it in master.

D135: 308_gnupg_2_0__de_po.diff

D136: 307_gnupg_1_4__de_po.diff

I fixed that in the README files but won't change it all over the project tree.

Given that the FAQ is entirely out of date, I will add this to the BUGS section:

In card edit it is:

Changed in all branches (svn rev 5256).
The prompts are now:

There is further a grammar: