I've linked the broken pubring (encrypted to Werner)

To trigger this bug run:

gpg2 --homedir broken-pubring --keyserver hkp://keys.gnupg.net --recv-key
6D3A9AB887A6229308D9C007E72581B1FE9F104C

Now you get an endless loop of:
gpg: keydb_search failed: Invalid packet

Afterwards even commands like: gpg --homedir broken-pubring -k
Fail in the same way.
If you don't do the recv-key first you only get the invalid packet message once
and the key is not listed.
And it has to be this keyid as it appears that this key is broken in the pubring.

The latest version i tested is gnupg 2.1.1-beta20

Details about how the pubring got corrupted:

We've updated some of our test application servers today to gnupg 2.1.1 from
gnupg 2.0.26

During the update we've killed all running gpg-agents but still after the update
a user had a 100% cpu hogging gpg process with the command line:

gpg --use-agent --batch --no-sk-comment --charset utf8 --enable-progress-filter
--ttyname /dev/pts/23 --ttytype xterm --with-colons --fixed-list-mode
--with-fingerprint --with-fingerprint --list-keys --
6D3A9AB887A6229308D9C007E72581B1FE9F104C

(Note this is gpg-1.4.12 from wheezy)

I've checked if I could reproduce this and imported the key to my own keyring on
the same machine with:

gpg --recv-key 6D3A9AB887A6229308D9C007E72581B1FE9F104C

(Also using gpg 1.4.12)
This worked and I could not reproduce the problem.
But as it turns out I ended up with a corrupted keyring.

I could not reproduce this by importing this key with gpg1 on another machine
(using gpg 1.4.16) so I doubt that this was the cause for the corruption.

Another cause might be that in the setup where the problem occured we have the
homedir on an NFS and there might have been other gpg-agents (2.0) still running
with that homedir. I did not expect this to be a problem though as I could use
my homedir with gpg1 and 2.0 even after I used 2.1 on it.