Leo Famulari <l...@famulari.name> skribis:
> On Thu, Apr 13, 2017 at 05:08:29PM +0200, Ludovic Courtès wrote:
>> A simple approach is to force LibreSSL to always use its non-getentropy
>> code, and lift this restriction once we clearly require newer kernels¹.
>> The attached patch does that.
>>
>> Thoughts?
>
>> + ;; Do as if 'getentropy' was missing since older Linux kernels lack it
>> + ;; and libc would return ENOSYS, which is not properly handled.
>> + '(#:configure-flags '("ac_cv_func_getentropy=no")))
>
> If we are committed to building glibc with the 2.6 kernel headers, and
> to providing substitutes for libressl and it's dependent packages, then
> I think this patch is a good option.
>
> But, it's a bit of a shame to leave this ~2.5 year old feature behind,
> especially when the 2.6 Linux series is not even part of the Linux
> long-term-support project. [0] These kernels *will* live for a long time
> through support from RHEL; their most recent kernel on RHEL7 is 3.10.
>
> However, I don't fully understand the impact of building glibc with a
> newer set of headers, so my objection is a weak one :)
I would suggest bumping the kernel requirement in glibc on the next
core-updates cycle (well, the current one!) and also making sure all our
build machines run the right thing.
In the meantime, I’d apply the above hack, and hopefully we can remove
it in a couple of months.
How does that sound?
Ludo’.
