Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup"): > can you clarify the race? i'm afraid we've been arguing about the gnupg > upgrade in several places and i'm happy to re-focus this particular > ticket.
Sorry about that. I guess I must be coming across as quite grumpy. Please don't be discouraged. Yes, let's refocus this bug. > i think you're saying that if two different instances of 2.1 > concurrently try to upgrade a given 1.4.x homedir, one of them may > intermittently fail. > > Is that correct? Do you have a narrower replication example than > running dgit repeatedly? I haven't tried to narrow the test case. I'm not 100% sure that concurrent execution of different gnupg instances is necessary. My replication is with the dgit test suite, which does run dgit but only in a self-contained way. > > Can you at least make the migration work every time ? > > can you help me to replicate the migration failure? from stretch, you > can create a GNUPGHOME with gpg1 and try to trigger parallel upgrades. > > I've done: > > export GNUPGHOME=$(mktemp -d) > gpg1 --gen-key > for x in 1 2 3 4 ; do > echo test $x | gpg --output test$x.gpg --clearsign & > done > wait %1 %2 %3 %4 > > and it seems to work fine on my 4-core machine. > > Is there a better way to replicate? I don't know. You could try sudo apt-get install dgit dgit-infrastructure devscripts debhelper dgit clone dgit sid cd dgit tests/using-intree tests/run-all and then look in test/tmp/NAME-OF-FAILED-TEST.log Or you could give me a version of gnupg2 which prints a better error message or instructions for making it produce debugging output. Currently I see, when it fails: gpg: starting migration from earlier GnuPG versions gpg: can't connect to the agent: IPC connect call failed This doesn't say what the errno was. (And is "IPC connect call" a reference to connect(2) ?) > > This is a very broad definition of "co-installable". In practice an > > admonition not to use gnupg1 and gnupg2 with the same ~ is going to be > > impractical to comply with. > > That's why i'm trying to help consolidate debian to only use a single > gpg, and to support 1.4.x only for people with unusual/antique use > cases. In fact the other things in your mail were much more reassuring. For example, given the behaviour you describe, I can convert the test suite's $GNUPGHOME once and it will work just fine with both gnupg1 and gnupg2. If I add private keys later with gnupg2 then those won't be visible to gnupg1, but for me that's kind of expected. But I would like to nail the intermittent failure before I cover it up by making the conversion happen much less often (and probably covered by some kind of outer lock of my own)... Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.