I am using gpg-agent on a KDE system, compiled from gentoo sources on ~x64.
A couple of weeks ago it started that I get two error messages presented upon
every logon. One says an error occurred while scanning my keyring and then
presents something like that (I have used --checkdb here to recreate it on the
shell)

sm@hal9001 ~ $ gpg --check-trustdb
gpg: enabled debug flags: memstat
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: key 00000000 occurs more than once in the trustdb
gpg: Note: signatures using the MD5 algorithm are rejected
...

The next message says that it cannot start gpg-agent. However, when I check for
the agent then it appears to be running. Also, I seem to be able to sign mails.

The problem appears to be gpg doing something unexpected upon start.
I am using a keyring that is quite old. Been using it since the late 90s. Sadly,
this also means the trustdb is exceedingly large. --check-trustdb throws an
endless list of warnings of all kinds but the above seems to be the most severe.
I don't know if my speculations here are of any help. The warnings are like this:

gpg: public key 0BC39EB6 is 265359387 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867739 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867739 seconds newer than the signature
gpg: public key 0BC39EB6 is 452815208 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867728 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867728 seconds newer than the signature
gpg: public key 0BC39EB6 is 11229 seconds newer than the signature
gpg: public key 0BC39EB6 is 452815208 seconds newer than the signature
gpg: public key 0BC39EB6 is 452815208 seconds newer than the signature
gpg: public key 0BC39EB6 is 263867739 seconds newer than the signature
gpg: public key 0BC39EB6 is 11425 seconds newer than the signature
gpg: public key 0BC39EB6 is 11474 seconds newer than the signature
gpg: public key 0BC39EB6 is 11521 seconds newer than the signature
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: WARNING: signing subkey B31CEDFC is not cross-certified
gpg: please see https://gnupg.org/faq/subkey-cross-certify.html for more information
gpg: public key of ultimately trusted key 00000000 not found
gpg: public key of ultimately trusted key 87978569 not found
gpg: public key of ultimately trusted key 1F8C7C61 not found
...
and so on.

This was causing some other problems so it got treated as a bug in T2000 it
is fixed in the latest 2.0 and 2.1 releases.