The repository contains outdated translations. Before releasing gnupg-2.0.17, I
had been poked by Werner and I have sent updated translation of gnupg2 back.
It's part of 2.0.17 release. You must have stored current translation somewhere
else.

I sent the translations as bugs #1144 (gnupg-2) and #1145 (dirmngr) a week ago.

D110: 264_dirmngr-1.0.3-allow_only_complete_dps.diff

Previous patches does not solve problem that one of DPs failes.

Just for clarification about DP list in certificate syntax and its semantics:

My previous patch does not delete all duplicate CRLs from cache if one entry is
recognised as still usable.

D111: 263_dirmngr-1.0.3-dont_overwrite_usable_crls-2.diff

D112: 262_dirmngr-1.0.3-dont_overwrite_usable_crls.diff

So, here it is. It's little verbose, be free to remove log_infos. This is output
I get (LDAP enabled) with this patch:

D114: 261_dirmngr-1.0.3-hexadecimal_serial_numbers.diff

Attached patch fixes it.

$ gpgsm --help
gpgsm (GnuPG) 2.0.11
[…]

--assume-binary              předpokládat vstup v binárním formátu

-r, --recipient ID_UŽIVATELE šifrovat pro ID_UŽIVATELE

--prefer-system-dirmngr      použít systémový dirmngr, je-li dostupný

I read RFC 3280 and I thing I understand it.

Sorry, I added gpgsm output without LDAP attempt because valid up-to-date CRL
for one CA was cached already. Follows output demonstrating stop on LDAP failure:

I got the idea probably. The structure of DP extension assumed by dirmngr is:

I did some debugging and I found that problem is not that it does not give up on
first successfully fetched CRL regardless expiration time. The real problem is
it simply fetches from all DPs and it rewrites the CRL with CRL from next DP on
each iteration.