From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: 01/02: gnu: libressl: Update to 2.5.3. Date: Fri, 14 Apr 2017 14:43:34 +0200 Message-ID: <87shlbdurt.fsf@gnu.org> References: <20170412011114.29557.46901@vcs0.savannah.gnu.org> <20170412011115.CE2FF220BE@vcs0.savannah.gnu.org> <87pogioukr.fsf@netris.org> <20170412152029.GA5920@jasmine> <87mvbkny4y.fsf@gnu.org> <20170413185921.GD14931@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz0Zg-0001YP-43 for guix-devel@gnu.org; Fri, 14 Apr 2017 08:43:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cz0Zd-000156-0C for guix-devel@gnu.org; Fri, 14 Apr 2017 08:43:40 -0400 In-Reply-To: <20170413185921.GD14931@jasmine> (Leo Famulari's message of "Thu, 13 Apr 2017 14:59:21 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Leo Famulari Cc: guix-devel@gnu.org Leo Famulari skribis: > On Thu, Apr 13, 2017 at 05:08:29PM +0200, Ludovic Court=C3=A8s 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=C2= =B9. >> The attached patch does that. >>=20 >> Thoughts? > >> + ;; Do as if 'getentropy' was missing since older Linux kernels lac= k it >> + ;; and libc would return ENOSYS, which is not properly handled. >> + '(#:configure-flags '("ac_cv_func_getentropy=3Dno"))) > > 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=E2=80=99d apply the above hack, and hopefully we can rem= ove it in a couple of months. How does that sound? Ludo=E2=80=99.