Well, I have no more excuses at hand to actually look at the problem ;-).

well. I tried.

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

See the INSTALL file for another way to share defaults (section "Sharing Defaults").

No. CFLAGS is used to override default flags. It might be that in a BSD system
CFLAGS can be used in the way you describe it; with the GNU system this is not
the case.

However, if CFLAGS is set in the environment previously, configure will fail.
This is especially inconveniently for those who set CFLAGS in bashrc etc and
those who uses source-based package manager doing this.
Setting CFLAGS as an environment variable should be universally correct,
shouldn't it?

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.

That is a warning to tell you that you called a regular Libgcrypt function
before gcry_check_version. It auto-initializes Libgcrypt as a workaround.

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.

The file INSTALL tells how to do this correctly:

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

D96: 227_314068_gnupg2_de.diff

D91: 226_380241.diff

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

Sorry, I mixed this up with gpgshell. Actually I might have done that for a
long time and ignored the existance of that project. Too bad.

Idea is not supported.

Might be a zlib problem; see also T1011 .

Change 5028 for 2.0.

JFTR: I have only tested on an amd64 box. But I can check this later with an
i386 box too.

I see this then:

This has been fixed in the SVN:

D79: 225_fix.diff

Even with the example file inthe Debina BTS, I can't replicate it with 1.4.8,
1.4.9. the current 1.4 svn version or gpg2. It is either a problem of libz or
more likely due to the amd64 CPUI. Unfortunately I don't have such a box
running right now.

See the recent threads on gnupg-devel for a discussion on this topic.

I changed some diagnostics to better track possible problems. You may want to
try svn rev 313.

Change 5024 for 1.4. Will do 2.0 shortly.

Marcus, can you please have a look at this?

Any news on this one?

I have not checked the code, but it seems plausible not to check the subkeys
once the primery key has been marked as expired. Checking the subkeys would
spend useless CPU cycles.