D101: 236_doc-fixes.diff

No, --fix-trustdb is a hidden command and may get a new life in the future.

Thanks for the change, I will check it out.
Did you consider removing the option --fix-trustdb
if you do not intend to implement it?
I would consider removal to be good, if the warning
is all what people get in the foreseeable future.
The existance of the options assumes that there is code
to do the fixing behind it.

Fixed in svn 5087.

An admin saw this suggestion in front of a user and got annoyed
that the recommendation

"the trustdb is corrupted; please run \"gpg --fix-trustdb\".\n") );

in tdbio_invalid(void) gnupg-2.0.12 did not work.

Are you still using the 4040?

Werner Koch via BTS wrote:

If that all does not help, a log file from gpg-agent would be useful.
Required options gpg-agent.conf are the log-file and "debug 1024".

Okay, okay, I remove the "pub/".

Then why is it referenced in multiple locations in the GnuPG website?!

I guess I found it. The process was simply leaking file descriptors during the
LOOKUP commands. This should explain the hangings we noticed by some folks.
The fix is in svn rev 318. It boils down to this little patch:

I have an strace log for the time before the kill, it is quite boring only
4130804 lines of
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)

Fixed in svn 5083. Will be backported to 1.4 if needed.
Thanks.

Done for 2.0 in svn r5082; will also be packaged with gnupg 1.4.10.

We can't print an error message because that would let gpg treturn with an error
code and lead to problesm with scripts which assume the current way of doing
things. A warning is possible but Unix tools generally don't do that.

Obviously you found that software thus I don't see a problem. ftp.gnupg.dk is
not related to gnupg.org in any way.

New log with svn rev 313 send to Werner on friday. The user had killed dirmngr.
(I am putting the internal reference in the topic.)

D100: 235_issue1091.diff

I looked at the source code and believe to have found the problem. Attached is a
diff against the latest svn that fixes this issue.

Werner Koch via BTS wrote:

Are you sure that you are using the latest gpg-agent;

Are you sure that you are using the latest gpg-agent; i./e. that which comes
with the SVN version of GnuPG? The easiest way to use a nwer gpg-agent trhan
one that is already running is by using

Werner Koch via BTS wrote:

However, I reverse engineered the protocol used by the Windows driver
and figured out how that driver does it. The SVN version has a hack
which basically works. I tested the 4040 and it works in most cases.
The hack is not 100% reliable but I was able to generate and use keys.

For obvious reasons the mailto scheme is not very useful. It is not even build
by default; you have to use ./configure --enabe-mailto. OTOH, I see that a way
to batch up keys for later retrieval is a nice feature - it should hwoever not
be limited to the mailto scheme.

Sorry, Omnikey based readers are broken for keys >= ~ 2048 bit. See
http://pcsclite.alioth.debian.org/ccid_extended_apdu.html . The 4040 might not
be listed but it uses the same chip and doesn't work either.

UID are expected to be UTF-8, IDN conversion should be done by the MUA.

Already fixed in my working copy. Will be commited with other translation
changes later the week.

Fixed in SVN. Thanks.

not a bug or - if at all - a bug in glibc. Further discussion please on the ML

Will be released with 1.4.10.

You can change the location of the keystore by cetting the environment variable
GNUPGHOME.

ping

The first part is not easy to fix and would require quite some rework. I don't
think this is justified.

Enter a "?" on the prompt and it will show you the valid characters.
We can't change this right now because this would break all translations.

Okay, I marked the zh_CN entry as fuzz.