Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17
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 not). Hi. I try to report just facts (unless I can guess what's really happening) and leave the interpretation and the fix for the maintainer. Sometimes a package have more than one reason to fail and we don't know about the second reason until we fix the first. When the maintainer is very clever, he/she is sometimes able to fix the second before the first :-)
Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17
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 --debug-quick-random, it seems perfect to me. > > Stephan, do you think it would be possible to patch mini-buildd so > that --debug-quick-random is added to gnupg command line, but only > when the package is doing the tests following the build? fwiw, I quickly tested '--debug-quick-random', and it does the trick, albeit for 2.1 only. So I unfortunately cannot use it (needing to support 1.4 still as well). I am now doing the doctest with pre-built keys, so this is will hopefully finally settle this issue with the next upload. 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 not). Thx, S
Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17
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 blocking kernel RNG in the buildd anyway? > Either that, or maybe a build-depends on a package specifically > created to do that (as I'm not sure we could really ask all buildd > operators to make the symlink permanently). > > A good solution should be automatic and not need manual intervention, > and should be independent of the machine on which the build is done. Exactly ;). > > 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 --debug-quick-random, it seems perfect to me. > > Stephan, do you think it would be possible to patch mini-buildd so > that --debug-quick-random is added to gnupg command line, but only > when the package is doing the tests following the build? Yeah, I will check this out (though it's not an option to gpg directly, afair). Or maybe going with a pre-generated key. Thx, S
Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17
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) (which is one of the reasons mini- buildd recommends haveged). So I guess just going for both for now ;), so I will check how I can improve that specific doctest in mini-buildd. I am still sort of wondering how other testsuites behave in this respect (like gnupg, gcrypt)? Thx! S
Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17
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 package specifically created to do that (as I'm not sure we could really ask all buildd operators to make the symlink permanently). A good solution should be automatic and not need manual intervention, and should be independent of the machine on which the build is done. > 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 --debug-quick-random, it seems perfect to me. Stephan, do you think it would be possible to patch mini-buildd so that --debug-quick-random is added to gnupg command line, but only when the package is doing the tests following the build? Thanks.
Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17
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 would hope that the autobuilders never actually *need* entropy to build packages. we want package builds to be reproducible, and entropy isn't necessary for that :) > But I really don't know. A quick search on gnupg and /dev/random > led me to the "haveged" package you mention. > > This is the kind of "entropy helper" package I believed it "had" to exist, > but I have never used any of them really. > > Would be possible to have haveged as a build-dependency of this > package so that it works automatically and avoids the problem in a > generic way for every kind of autobuilder trying to build the package? I've used haveged with gnupg before. It certainly removes the kernel's sense of lacking entropy, but i have had no time to verify that the bits mixed into the random pool by haveged is in any way a robust entropy source. I'm also not sure that haveged is available (or well-motivated) on all architectures, since what little logic i've understood about how haveged works sounded processor-specific to me. > Maybe we should ask dkg and the other people maintaining gnupg about > what it's usually done in cases like this (package needing a lot of > entropy in its build system). 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? 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? --dkg signature.asc Description: PGP signature
