GnuPG 2.1.0: key too large, import stops

[Phil Pennock]

While migrating keyring formats for GnuPG 2.1.0, with this command:

    % gpg --import old-linear-public-keyring.gpg

the import stopped at key 0x57930DAB0B86B067:

gpg: error writing keyring '/home/username/.gnupg/pubring.kbx': Provided object is too large
gpg: key 0x57930DAB0B86B067: public key "[User ID not found]" imported
gpg: error reading 'old-linear-public-keyring.gpg': Provided object is too large
gpg: import from 'old-linear-public-keyring.gpg' failed: Provided object is too large

I've confirmed that import also fails with:

    % gpg --keyserver sks.spodhuis.org --recv-key 0x57930DAB0B86B067

and I've seen the size caps on keys mentioned in mails on this list, but
I was expecting this to cause the import of this key to be skipped, not
for it to abort the entire keyring import.

    % gpg --keyring old-linear-public-keyring.gpg --export 0x57930DAB0B86B067 > toolarge.0x57930DAB0B86B067
    % ls -ld toolarge.0x57930DAB0B86B067 | awk '{print $5}'
    2364114

It's a legitimate key.  I've used --delete-key to remove it from that
keyring, and fired up the import once more.  I left the second run going
under screen last night, after the first failed.

BTW: kudos on the speed improvements for large keyrings, they're very
_very_ much appreciated.  Even with an incomplete import, I still had
nearly three quarters of the old keyring in and the performance
differences are _very_ marked.  I'd realized the cause of the problems
and had been mulling over a project idea of trying to use sqlite with
GnuPG and am exceedingly happy that a good and maintained solution has
already been found and incorporated.

Now just to figure out why I have to keep specifying the keyserver
manually ...