Bug 539875

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