On Thu, Sep 15, 2016 at 03:51:01PM +0200, Stephan Sürken wrote:
> Btw, it's only now that I actually grasp your initial problem was about
> entropy all along ;). I just blatantly assumed your initial bug report
> was about the doctest failing due to GPG 2.1 (which it did at the time,
> entropy or
Hi Santiago,
On Mo, 2016-09-12 at 21:34 +0100, Santiago Vila wrote:
(...)
> > Lastly, one other option for gnupg at least is to patch upstream to
> > use
> > --debug-quick-random in the build-time test.
> >
> > do any of these options sound more appealing than the others?
> I didn't know about --
Rehi,
On Mo, 2016-09-12 at 21:34 +0100, Santiago Vila wrote:
> On Mon, Sep 12, 2016 at 07:34:09PM +0200, Daniel Kahn Gillmor wrote:
>
> >
> > An even easier approach might be to do the following within the
> > build:
> >
> > * ln -sf /dev/urandom /dev/random
> >
> > why would we need the blo
Hi Daniel, Santiago,
thx for the answer; I am not 100% satisfied, though ;).
For me, it actually boils down to what notion we have:
(1) The builder hosts must provide reasonable entropy.
(2) Software testsuites generally must work fine even with low entropy.
In the past, I tended to go with (1)
On Mon, Sep 12, 2016 at 07:34:09PM +0200, Daniel Kahn Gillmor wrote:
> An even easier approach might be to do the following within the build:
>
> * ln -sf /dev/urandom /dev/random
>
> why would we need the blocking kernel RNG in the buildd anyway?
Either that, or maybe a build-depends on a pa
Hi Santiago and all--
On Sun 2016-09-11 21:30:22 +0200, Santiago Vila wrote:
> Well, maybe the problem has always been there.
>
> Maybe official autobuilders have a lot of entropy and we have never
> found the problem there, but IMHO we should not take that for granted
> in the general case.
I wo
6 matches
Mail list logo
