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.

Done for 2.0.13:

In IRC, weasel just told me that this output is just fine. He is right, since
doc/DETAILs says, there is no escaping for --fixed-list-mode.

The translation in zh_TW.po looks good, but the one in zh_CN.po doesn't. It
contains the kanji sequence "删除" (U+5220, U+9664) which is very close to "削
除" (U+524a, U+9664, "remove" in Japanese) in shape.

The greek translation is anywat marked as fuzz. I also marked the Spanish one
fuzzy. The two Chinese translations seem right to me - at least the two strings
don't look to similar.

D97: 232_po-typo.diff

2.0.12 has been released.

Fixed in SVN using

Please check whether this still happens with gnupg rev 5039 or with the patch below

I guess that Kontact calls gpgconf with the the standard descriptors closed.
Without debugging I can't say why stuff ends up in trustdb.gpg but it is an all
too common problem that I expect thsi cause.

I think I fixed that while applying your patches.

Although it is an application error to assume a certain sigprocmask beyond
what's defined by POSIX, we should be nice and try to kill pth too.

Ah found something:

Fixed in my working copy. Thanks.

Right, I did no "make dist" to check this. Fix committed.

No, that is not a typo. --daemon used to be required to avoid starting several
gpg-agents - which happened quite often while in lets-see-what-happens testing
mode. Later the code was change so that running gpg-agent without any args
tested whether a gpg-agent is already running. Thus we can simplify the paragraph.

You are keeping me pretty busy :-)

kbxutil is more a debug tool and may change at any time. I don't think that a
man page is useful.

Applied to both versions (r5030). Thanks to you and also to Jens Seidel.

See these threads for example:

The internals are already set for multiple keyservers (opt.keyserver is a
strlist, etc.) I had to implement it for the auto-key-retrieve feature, which
does support multiple servers.

D92: 231_314068_gnupg1_de.diff

D93: 230_314068_gnupg2_de.diff

I get a build failure. g10/gpgv.c probably misses:

And the same fixes for gnupg 1.4.

D94: 229_~_packages_vcs_gnupg_2_314068_gnupg2_de.diff

D95: 228_314068_gnupg2_de.diff

I found some more. So here a new diff for gnupg 2.

One more. At

I see. Then comparing the value to ULONG_MAX should solve the issue, right?

Found the cuplrit:

Well that value is 0xFFFFFFFFFFFFFFFF.

Good idea. I think an adaptation of that code will do nicely. I think what is
needed here is a pass through that code, which almost always returns UTF8, then
a pass through utf8_to_native and then native_to_utf8. This is a lot of
manipulation, but string_to_utf8 may not return UTF8 if the user ID is coded
very badly, and the LDAP server will reject anything that isn't UTF8

On Thu, May 28, 2009 at 03:03:07PM -0000, Werner Koch via BTS wrote:

Hm. Comparing --debug-all on both architectures I see clear differences. Not
sure if they count. But the value for length on the amd64 box, when it re-enters
the loop looks weired:

i386: no loop