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:
> <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!
> 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,
> 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.
> 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.
> 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
Attachment:
signature.asc
Description: Digital signature