Hi
Cc'ing the Debian Perl Group list, in case someone there has an idea.
On Tue, Apr 20, 2010 at 10:32:51AM -0400, Abaddon Daemon via RT wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=56723 >
>
> This report and your previous report stopped at different places. Your first
> report for 0.16 stopped here:
>
> Read in NEED_PASSPHRASE
>
> But your second report goes one step further and stops here:
>
> Read in SHM_GET_HIDDEN - passphrase.enter
Hmm, the first entry was when building 0.15. I get
Read in SHM_GET_HIDDEN - passphrase.enterGnuPG: reading from status fd 3
when building 0.16. So yes, the very first report stopped at a
different place, this was fixed by the 0.16 upload!
Show quoted text> I find this interesting. It's difficult for me to debug, since the breaking
> point doesnt seem to be the same, and Im still unable to reproduce the
> symptoms (unfortunately I dont have an AMD box available anymore, so I cant
> do a real architecture-specific test).
Damian had a look too, and tried it both under i386 and amd64 to
build, the following was the conclusion:
[21:37] < carnil> can someone please try to build libgnupg-perl and look if it fails? It still does here, but
upstream cannot reproduce it.
[21:38] < carnil> would be great if someone can test it too
[21:38] < dam> just a minute
[21:40] < dam> it seems to hang after ok 10 - pipe_decrypt_test
[21:41] < dam> carnil: ^^^
[21:42] < dam> strace shows it is waiting in read(), from FD 3
[21:42] < carnil> dam: ok same here, is it on amd64?
[21:42] < dam> FD 3 is a pipe
[21:43] < carnil> dam: do you have the possibility to test too the build on i386?
[21:43] < dam> the other end of the pipe belongs t a 'gpg' process
[21:43] < dam> carnil: I have an i386 chroot. will test
[...]
[21:51] < dam> carnil: i386 hangs at the same place
[21:51] < dam> strace says: [ Process PID=1097 runs in 32 bit mode. ] wait4(-1,
[21:52] < dam> which is different to amd64, which hanged on read(3,
Show quoted text> If you could, in your chroot environment, try running the following command
> manually:
>
> /usr/bin/gpg --output test/file.txt.sgpg --no-greeting --yes
> --run-as-shm-coprocess 0 --homedir test --recipient 'GnuPG Test' --sign
> --armor --encrypt test/file.txt
>
> What is most likely happening here is you are somehow getting into a
> scenario where GPG is throwing a prompt that has not been anticipated by me.
> The --yes flag was meant to catch these, but it must be a non yes/no prompt.
Hmm, this should not really be the problem I assume, as it works in
the really same chroot (so even same gpg), but with GnuPG 0.11?! And
as you said, none of the changes affects prompting at least. So it's
really strange.
Show quoted text> I find it odd that you say 0.11 works, though. None of the changes Ive made
> should effect shared memory OR prompting. The only thing in that arena
> (related to your scenario) that should be different is the password prompt
> stuff (I added one escape in the event of a blank password). But if you're
> running the tests that come with it, the password shouldnt be blank,
> therefore shouldnt be effected.
Yes, I'm running the tests in the suite.
Show quoted text> Im at a bit of a loss here.
/me too, let's see if someone from debian-perl list has an idea.
Bests and thanks for your work
Salvatore
