From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJUvT-0000xA-DC for guix-patches@gnu.org; Mon, 27 Nov 2017 20:43:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJUvO-0008Uf-Tr for guix-patches@gnu.org; Mon, 27 Nov 2017 20:43:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:52792) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eJUvO-0008Ub-Na for guix-patches@gnu.org; Mon, 27 Nov 2017 20:43:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eJUvO-0007QX-EK for guix-patches@gnu.org; Mon, 27 Nov 2017 20:43:02 -0500 Subject: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for glibc 2.26. Resent-Message-ID: From: Marius Bakke In-Reply-To: <20171127213004.GA22910@jasmine.lan> References: <87mv3eove6.fsf@fastmail.com> <20171123145702.GA5794@jasmine.lan> <20171127213004.GA22910@jasmine.lan> Date: Tue, 28 Nov 2017 02:42:05 +0100 Message-ID: <87bmjnyyaa.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Leo Famulari Cc: 29406@debbugs.gnu.org --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Leo Famulari writes: > On Thu, Nov 23, 2017 at 09:57:02AM -0500, Leo Famulari wrote: >> On Wed, Nov 22, 2017 at 10:28:49PM +0100, Marius Bakke wrote: >> > So I wonder if we should simply pick everything from this branch, >> > instead of only the few that fixes immediately visible problems. >> > Thoughts? >>=20 >> Based on this discussion [0], I think we should take the whole branch. >> It sounds like commits on the release branches are considered important >> bug fixes and "stable". > > So after reading the rest of that thread, I'm not so sure we should take > the whole branch. > > They use the word "stable" to refer to the ABI, but the branch itself is > not tested to the same degree as the tarball releases, and may even be > in an incomplete state, depending on WIP commits. The thread ebbed out in an argument about the utility of git tags vs the output of `git describe`: https://sourceware.org/ml/libc-alpha/2017-10/msg00565.html And spawned a new thread to bump the "development" release number to 9000 in order not to conflict with long-lived release branches: https://sourceware.org/ml/libc-alpha/2017-10/msg00628.html AFAICT all commits on the branch are considered stable and nearly all are cherry-picked from master after initial testing. > On IRC Marius said that at least one thing mentioned as "incomplete" in > that thread has been completed on the branch. I think this is the email you are referring to, and actually both proposed 2.26.1 release blockers have been on the 2.26 branch a while. https://sourceware.org/ml/libc-alpha/2017-10/msg00103.html > Anyways, I don't have a strong opinion anymore about which commits to > take. But, let's make a choice and continue with core-updates :) Now that I've combed the branch history, I found that I had actually missed some fixes in the first C++/float128 roundup patch, that might not have caused problems until late in the cycle. Who knows what all those other commits do, but I trust the judgmement of the glibc maintainers more than my own regarding which patches to pick. Seeing as Fedora and IBM use the release branch, and the alternative is to carry almost every patch anyway (~1.2MiB), I prepared an update that uses a snapshot from : --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-gnu-glibc-Update-to-2.26-91-gaaa2eb83b8.patch Content-Transfer-Encoding: quoted-printable From=20a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001 From: Marius Bakke Date: Sat, 25 Nov 2017 19:17:28 +0100 Subject: [PATCH] gnu: glibc: Update to 2.26-91-gaaa2eb83b8. * gnu/packages/base.scm (glibc/linux): Update to 2.26-91-gaaa2eb83b8. [source](uri): Download from alpha.gnu.org. [source](patches): Remove glibc-CVE-2017-15670-15671.patch. =2D-- gnu/packages/base.scm | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm index a6663c5cf..20d5fa72b 100644 =2D-- a/gnu/packages/base.scm +++ b/gnu/packages/base.scm @@ -515,14 +515,22 @@ store.") (define-public glibc/linux (package (name "glibc") =2D (version "2.26") + ;; Glibc has stable branches that continuously pick fixes for each supp= orted + ;; release. Unfortunately they do not do point-releases, so we are stu= ck + ;; with copying almost all patches, or use a snapshot of the release br= anch. + ;; + ;; This version number corresponds to the output of `git describe` and = the + ;; archive can be generated by checking out the commit ID and run: + ;; git archive --prefix=3D$(git describe)/ HEAD | xz -9 > $(git describ= e).tar.xz + ;; See for details. + (version "2.26-91-gaaa2eb83b8") (source (origin (method url-fetch) =2D (uri (string-append "mirror://gnu/glibc/glibc-" =2D version ".tar.xz")) + (uri (string-append "https://alpha.gnu.org/gnu/guix/mirror/" + "glibc-" version ".tar.xz")) (sha256 (base32 =2D "1ggnj1hzjym7sn93rbwydcqd562q73lsb7g7kd199g6j9j9hlkp5")) + "0867nxcv3n48iq3b5f1hca7cyx8pzjva67rxyslf9l595xd934kx")) (snippet ;; Disable 'ldconfig' and /etc/ld.so.cache. The latter is ;; required on LFS distros to avoid loading the distro's libc= .so @@ -533,7 +541,6 @@ store.") (modules '((guix build utils))) (patches (search-patches "glibc-ldd-x86_64.patch" "glibc-versioned-locpath.patch" =2D "glibc-CVE-2017-15670-15671.patch" "glibc-o-largefile.patch")))) (build-system gnu-build-system) =20 =2D-=20 2.15.0 --=-=-= Content-Type: text/plain I don't think including the "g" prefix in the commit ID string is great, but stripping it seemed unnecessarily complicated. WDYT? Can someone generate and upload this tarball if this makes sense? --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlocvu0ACgkQoqBt8qM6 VPo6hwf/f8sAn2bI3AEA7jg7U9PK369DlnynT1Y2jQo50MeHlJSlsRm8Ae4/h03I LGMijBo36k5w2ObXBqncb9EuZNAQMdrKYTEnur+gJEDkOsFmYzQr4hxYHTIyq2YB sLPRDTt0IuM8fk9LcUMBZbOrvVzSkRrdEWE3TkQdVZqsqX2tyBSFfOI81Ev7h7ef 8pv9708SPtFGc62EiZeiLZKDLJ1OZhdn6DX7PHEkm+/c4TC3MdoXgo1em+PYFqmG hMPOdT2sr0aj2ekZUwcjzIgx7/mFgB622ukDA2mQpvwIbd9BdyUn4bw6DBSecUqE YT7Po4pY1st1vBp74IcHFxqhhsNjgQ== =OUWz -----END PGP SIGNATURE----- --==-=-=--