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 u

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

2012-10-20 Thread Debian Bug Tracking System
Processing control commands: > tags -1 + patch Bug #682648 [src:python-gnupg] python-gnupg: FTBFS: test hangs for 60 mins Added tag(s) patch. -- 682648: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682648 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCR

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 spec

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 rel

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 debian-bugs-rc-requ...@lists.de

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 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 sta

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 caus

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'' -- To

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 dire