Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-10-20 Thread Arthur de Jong
Control: tags -1 + patch On Mon, 2012-09-10 at 15:33 +0200, Elena ``of Valhalla'' wrote: Yes, I've been working to add the switch via the above feature, but it is breaking other tests, and I didn't have time to fix those further failures yet. I've had a look at this and made a patch for

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-09-10 Thread Dmitry Shachnev
Felix Geyer, 2012-08-05: gpg has a --quick-random switch which makes it read from /dev/urandom instead of /dev/random. However I'm not sure how to force python-gnupg to use that parameter for the tests. An option to specify command-line arguments to gpg call was added in upstream 0.3.1

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-09-10 Thread Elena ``of Valhalla''
On 2012-09-10 at 14:02:26 +0400, Dmitry Shachnev wrote: Felix Geyer, 2012-08-05: gpg has a --quick-random switch which makes it read from /dev/urandom instead of /dev/random. However I'm not sure how to force python-gnupg to use that parameter for the tests. An option to specify

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-08-05 Thread Felix Geyer
You're right, reading from /dev/urandom is not the issue. gpg has a --quick-random switch which makes it read from /dev/urandom instead of /dev/random. However I'm not sure how to force python-gnupg to use that parameter for the tests. -- To UNSUBSCRIBE, email to

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-07-26 Thread Elena Grandi
On 2012-07-25 at 15:30:16 +0200, Felix Geyer wrote: That test requires a lot of random data (5 MB). It seems to be only used for testing if signing files work. Do you have an idea why the data needs to be random instead of just using a hardcoded pattern to generate that file? Just to be

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-07-25 Thread Felix Geyer
On 24.07.2012 22:12, Elena ``of Valhalla'' wrote: The package builds on my amd64, but running the tests takes a long time[1] because gnupg (called by python-gnupg) is waiting for random data. I suspect that the issue is that the typical lack of entropy of virtual machines is the cause of

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-07-25 Thread Elena ``of Valhalla''
On 2012-07-25 at 15:30:16 +0200, Felix Geyer wrote: I suspect that the issue is that the typical lack of entropy of virtual machines is the cause of the 60 minutes wait. That test requires a lot of random data (5 MB). Actually the build fails before said file is generated: the tests start

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-07-24 Thread Lucas Nussbaum
Source: python-gnupg Version: 0.3.0-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120724 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[1]: Entering

Bug#682648: python-gnupg: FTBFS: test hangs for 60 mins

2012-07-24 Thread Elena ``of Valhalla''
The package builds on my amd64, but running the tests takes a long time[1] because gnupg (called by python-gnupg) is waiting for random data. I suspect that the issue is that the typical lack of entropy of virtual machines is the cause of the 60 minutes wait. -- Elena ``of Valhalla'' --