[bug#29406] [PATCH core-updates]: Add selected upstream fixes for glibc 2.26.

[Marius Bakke]

Leo Famulari <address@hidden> 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?
>> 
>> 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 <https://alpha.gnu.org/gnu/guix/mirror>:

From a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001
From: Marius Bakke <address@hidden>
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.
---
 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
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -515,14 +515,22 @@ store.")
 (define-public glibc/linux
   (package
    (name "glibc")
-   (version "2.26")
+   ;; Glibc has stable branches that continuously pick fixes for each supported
+   ;; release.  Unfortunately they do not do point-releases, so we are stuck
+   ;; with copying almost all patches, or use a snapshot of the release branch.
+   ;;
+   ;; 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=$(git describe)/ HEAD | xz -9 > $(git 
describe).tar.xz
+   ;; See <https://bugs.gnu.org/29406> for details.
+   (version "2.26-91-gaaa2eb83b8")
    (source (origin
             (method url-fetch)
-            (uri (string-append "mirror://gnu/glibc/glibc-"
-                                version ".tar.xz"))
+            (uri (string-append "https://alpha.gnu.org/gnu/guix/mirror/";
+                                "glibc-" version ".tar.xz"))
             (sha256
              (base32
-              "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"
-                                     "glibc-CVE-2017-15670-15671.patch"
                                      "glibc-o-largefile.patch"))))
    (build-system gnu-build-system)
 
-- 
2.15.0

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?

signature.asc
Description: PGP signature