From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: 01/02: gnu: libressl: Update to 2.5.3. Date: Fri, 14 Apr 2017 14:07:30 -0400 Message-ID: <8760i6q2vx.fsf@netris.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]:54677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz5dV-0002Nb-UC for guix-devel@gnu.org; Fri, 14 Apr 2017 14:07:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cz5dS-0007bI-Op for guix-devel@gnu.org; Fri, 14 Apr 2017 14:07:57 -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 writes: > 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"))) Ludo's approach looks good to me. > Personally, I don't think it's paramount to offer substitutes for the > packages in question. But I know this is an unpopular position, in > general :) It's not just about not providing substitutes. At present, our libressl simply won't work properly on systems with older kernels, including hydra.gnu.org and our x86 build slaves. One issue is that there's a longstanding hope for us to switch to using libressl for most or all packages that currently use openssl. We would be blocked from doing that if we accept that our libressl won't work on older kernels. Thoughts? Mark