Wow, thank goodness this bug is invalid.  The original poster, with all due respect, was simply ignorant of how things are supposed to work.  Remember the Debian SSL bug?  That was due to some code maintainer who thought he knew more than the crypto coders.  As a result he broke thousands of keys across the Internet and severely embarrassed the Debian developers.

People have already given you solutions:

1) Generate the key on a device that has a mouse and keyboard and then transfer the key to the other device.

2) Go buy yourself a hardware RNG like the entropy key.  It is cheap and fits into any USB slot.

3) Go download HAVEGED from the repository.  It likely gives "good enough" randomness and will keep your random pool full at all times.  However, since it hasn't been well studied, use this only as a last resort! (It was developed by PhD's, so it's probably good enough, but it still needs peer review).

If you can't do either of those then you shouldn't be generating keys on the device.  There was a recent study that collected millions of keys across the internet and found that many thousands of them were easily broken.  Why?  Because they were generated with crappy entropy (and mostly generated on devices like routers, vpn's,  etc.)  Is this what you want?  An easily broken key?

If your system doesn't have any inputs or you have no way of generating entropy, that's *your* problem to figure out.  Don't go suggesting that Ubuntu should make us all insecure because of you.  Again, if you don't have a keyboard or mouse hooked up to the machine, go find a machine with them and generate the keys there.  If the machine is remote, then simply generate the keys locally (with a strong password) and then send them over the wire to the remote machine.  This should not present any security issues since the private key is itself encrypted.

Bottom line:  the GnuPG RNG is working as it is *supposed* to work.  If it didn't work the way it did I would not use it.  This is *not* a bug with Ubuntu and it's not a bug with GnuPG.  Also rng-tools is *not* meant to be used unless you have a hardware TRNG, so it is working as intended as well. Whoever suggested pointing it at /dev/urandom is a complete amateur at cryptography and should be ignored.  There's a lot of people out there who just don't know what they're talking about when it comes to crypto and they should be ignored just as much as this bug report should be ignored.

@JoePete

There are no processes on an OS that are sufficient for entropy gathering *besides* keyboard, mouse and disk movements (and even they have problems, but are probably good enough).  So what the developers are doing now *is* sound development practice.  They don't need amateurs trying to tell them how to do crypto.  

I think part of the problem with people trying to get entropy from disk seeks is they don't understand how /dev/random works.  It estimates the entropy before it hashes it and outputs it.  Since disk seeks have much less entropy than say a random mouse or keyboard input, this is why it takes forever to generate any output.  /dev/random is designed with entropy measurement in mind and it simply wont output anything if the entropy estimates are not up to par.  Disk seeks are obviously pretty bad for generating entropy or else the output would be faster.  It is what it is.  Security should *always* trump speed in situations like this.