From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: bug#30537: glibc 2.26 refuses to run on CentOS 6.8 Date: Tue, 20 Feb 2018 07:51:36 -0500 Message-ID: <20180220125136.GA7573@jasmine.lan> References: <87eflgstqt.fsf@mdc-berlin.de> <20180220012229.GA28522@jasmine.lan> <20180220115221.GA17373@jasmine.lan> <87woz7rga4.fsf@mdc-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eo7Ox-00068j-Pr for bug-guix@gnu.org; Tue, 20 Feb 2018 07:52:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eo7Os-0001ZV-RI for bug-guix@gnu.org; Tue, 20 Feb 2018 07:52:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:44340) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eo7Os-0001Z7-Fm for bug-guix@gnu.org; Tue, 20 Feb 2018 07:52:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eo7Os-00062N-5j for bug-guix@gnu.org; Tue, 20 Feb 2018 07:52:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87woz7rga4.fsf@mdc-berlin.de> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: 30537@debbugs.gnu.org --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2018 at 01:34:27PM +0100, Ricardo Wurmus wrote: > The only reason for moving the lower bound to Linux 3.2 is that 2.6 has > reached EOL. This allows the glibc developers to assume certain > kernel features and simplify their code. >=20 > The RHEL kernels are special, though, in that they are continuously > patched beyond recognition, backporting features. A RHEL 2.6.32 kernel > is very different from a stock 2.6.32 kernel. >=20 > The patch explicitly permits a *single* extra kernel version (0x020620 =3D > 2.6.32) at runtime, not *all* older kernels, so it isn=E2=80=99t as bad a= s it > may seem. Okay, thanks for the clarification. > For future updates to the glibc we would have to re-evaluate if the > current RHEL 6.x kernel still supports all features the glibc expects, > and decide once more if we can justify patching glibc to allow that one > particular kernel version. Yes... and this will probably continue for many years. But I do think we should do something to work around the issue now, and reevaluate our solution when the pressure is off. It would be nice if the graft only applied to x86_64-linux, but I've never considered if that is easy to do or not. --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlqMGdUACgkQJkb6MLrK fwjUfRAA1S+p7fadQdisowygmBFOp54UUXFcaTep5zdt1Tl+IefCrYheaZMP+WF9 5a15m+WdtE6GyQUiw2hNShig2Sau7YIdJj8IR+LNXqbxogzbdnaQHeXe/sO4rUmo cN4wPnnNPVOEs487eAUBcOT5j/i0HUTJlT7fjcyWirmHFfS2WtnZqnDo3qErW0rX 2D7tiL55lXlfWpo71g9e+1Q2hZVdfwdsGFynhz6gehoZ8VvkaEPEetlBwLKfugMr efOhPCgvoSjJAFQ7CAZxnEZUrzuJRcXYTuPSl2/pwjDVVBHQsjTTL6SK/mfBcn4E J8IH0b00/ii1GfEH1mT9cmtRKqzBAXqiY09QW6y3h4V5PVKIl0vmtd6GP+KG1hGe 9KdXJcUkzT+O4Ztd088ic5w/3rgLb/QJEw37Kasus7h2fLdCxhVrUqZ/wj/EzbKU yvnxV95W2IuwrwDRADDDMdQDYr4u/8VlSUBFyWMEteyZwBTo5mJTpNwzhcjE1zwZ TfUGqqD+dZNSyyHK3W6z0gP88YXp1KCOc9TEKsAQGRB0FzTfL0R4bp60Vr3MaCwM IGftNvF+7yPl5ZNY6WJHDBto5qfcmZhHX3vmSiV73kPX3Sk8kWLeQbI2xBrwLtlZ E5BDDU7aoxEfG8aFjdza/YF43ErXKVx3nBnNVSZp+GG1L9s86rg= =Pcen -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--