Description of problem: Rebuilding of my perl-Crypt-GPG package doesn't any longer work, since gnupg2 is used instead of gnupg, see bug #539150 and below: [11:55:10] < rsc> Could somebody please have a look to http://koji.fedoraproject.org/koji/taskinfo?taskID=1820381? Why doesn't it ever end? [12:49:30] < G> rsc: sounds like the tests don't like Koji [12:50:22] < rsc> G: in the past, that worked [12:50:57] < rsc> G: I just fired a scratch build to see whether the rebuild issue of mdomsch can be verified [12:51:18] < G> rsc: why does it start a gpg-agent btw? [12:51:30] < rsc> G: no idea? [12:52:08] < G> rsc: it looks like it's waiting on input... [12:52:22] < G> 427 19660 0.0 0.0 14580 1000 ? SL Nov20 0:00 /usr/bin/pinentry-curses [12:55:47] < rsc> hmmm [12:56:29] < G> rsc: pstree claims thats the last process executed for your build [12:56:42] < G> rsc: mind if I nuke it to clean up the build? [12:56:57] < rsc> G: that's okay. I wonder why it worked in past [12:57:18] < G> 427 19652 0.0 0.1 142908 8840 ? S Nov20 0:00 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/01-keygen.t t/02-import.t t/03-export.t t/04-encdec.t t/05-sigver.t t/06-keyops.t [12:57:27] < G> rsc: that should help isolate the failing test [12:57:38] < rsc> that's all tests IIRC ;) [12:58:20] < G> rsc: ahh well, GPG.pm line 479 is where it got [13:00:48] < G> rsc: it's cleaned up now, but yeah, looks like gpg-agent and pinentry-curses was causing it to get stuck [13:01:13] < G> rsc: actually yeah, looks like it was 'perl -w t/01-keygen.t' [13:01:27] < tmz> Could the failure be due to changing from gnupg1 to gnupg2 recently? [13:01:47] < rsc> tmz: it uses /usr/bin/gpg [13:02:01] < G> hmmm if we did change, then it could be different behaviours for key generation [13:02:39] < tmz> rsc: And that's now from gnupg2 in rawhide. [13:03:13] < rsc> http://koji.fedoraproject.org/koji/rpminfo?rpmID=1526401 [13:03:14] < rsc> hu? [13:03:31] < rsc> gnupg-1.4.10-1.fc12 ships /usr/bin/gpg [13:04:29] < tmz> Check the root.log for that build though. It pulls in gnupg2. This was changed recently to provide gnupg as the plan is to only ship gnupg2 now. [13:04:40] < rsc> urgs. [13:04:50] < G> okay, that is confusing [13:05:10] < rsc> nobody wants gpg2 ;) [13:05:33] < tmz> rsc: I can't disagree with that. I prefer gnupg1 as well. [13:05:58] < rsc> ah, looks like gnupg2 is broken by design: http://bugs.gentoo.org/217640 [13:07:02] < G> rsc: ouch, thats the bug [13:07:17] * rsc tends to add a Conflicts: gnupg2 ;) Version-Release number of selected component (if applicable): gnupg2-2.0.13-3 How reproducible: Everytime, see above. Actual results: Password entry dialog is broken when used with pipe. Expected results: Working with gnupg2 as it ever worked in gnupg without manual fuddling. Additional info: http://bugs.gentoo.org/217640
Please use options --passphrase-fd 0 and --batch when calling the gpg.
And at which places in perl-Crypt-GPG will I need to use these parameters to get things working again?
It would have to be added to all the places where the gpg is invoked. Unfortunately the gen key invocation has to be modified for the --batch mode because gpg in the batch mode does not prompt for the key parameters but rather expects the parameters in the form of 'Parameter: value' lines.
Could I please get some support here? I did not break the stuff, that was the person(s) who decided to obsolete gnupg in favour of gnupg2. As you walked this way, please provide a fix for my package. Rex, can you please show up and help?
Obsoleting gnupg wasn't really my doing... Tomas has led the gnupg->gnupg2 effort here, and has been kind enough to provide good direction on where/how to fix this ... I can try to help where I can, perhaps enough to provide concrete patches, though honestly I'm a bit swamped these days.
Unfortunately I don't know perl much so it is not quite easy for me to make the changes especially in the gen key function.
FTBFS fixed in gnupg2-2.0.14-2.fc13. Closing.