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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29406 in the body.
You can then email your comments to 29406 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: guix-patches <at> gnu.org
Subject: [PATCH core-updates]: Add selected upstream fixes for glibc 2.26.
Date: Wed, 22 Nov 2017 22:28:49 +0100

[Message part 1 (text/plain, inline)]

Hello!

I discovered that 'icu4c' failed to build for x86_64 on 'core-updates'.
After some investigation, it turns out to be a problem with <math.h> in
C++ mode, due to its usage of C-only builtins (in the 2.26 release).

Here are the relevant bug reports I've found so far by digging through
the "release/2.26/master" branch, aka "2.26 stable"[0]:

<https://sourceware.org/bugzilla/show_bug.cgi?id=21930>
<https://sourceware.org/bugzilla/show_bug.cgi?id=22235>
<https://sourceware.org/bugzilla/show_bug.cgi?id=22146>
<https://sourceware.org/bugzilla/show_bug.cgi?id=22296>

The attached patch includes the fixes from those bugs, as well as a
couple of others that looked important.  However it's still a very small
subset of the 2.26 post-release fixes.

I've read through _most_ of the commits and around half of them look
important enough to pick "unconditionally".  The other half I mainly
lack the context or skills to assess.

So I wonder if we should simply pick everything from this branch,
instead of only the few that fixes immediately visible problems.
Thoughts?

[0] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.26/master

[0001-gnu-glibc-Add-selected-fixes-from-upstream-stable-br.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406 <at> debbugs.gnu.org
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes
 for glibc 2.26.
Date: Thu, 23 Nov 2017 09:57:02 -0500

[Message part 1 (text/plain, inline)]

On Wed, Nov 22, 2017 at 10:28:49PM +0100, Marius Bakke wrote:
> Hello!
> 
> I discovered that 'icu4c' failed to build for x86_64 on 'core-updates'.
> After some investigation, it turns out to be a problem with <math.h> in
> C++ mode, due to its usage of C-only builtins (in the 2.26 release).
> 
> Here are the relevant bug reports I've found so far by digging through
> the "release/2.26/master" branch, aka "2.26 stable"[0]:
> 
> <https://sourceware.org/bugzilla/show_bug.cgi?id=21930>
> <https://sourceware.org/bugzilla/show_bug.cgi?id=22235>
> <https://sourceware.org/bugzilla/show_bug.cgi?id=22146>
> <https://sourceware.org/bugzilla/show_bug.cgi?id=22296>
> 
> The attached patch includes the fixes from those bugs, as well as a
> couple of others that looked important.  However it's still a very small
> subset of the 2.26 post-release fixes.
> 
> I've read through _most_ of the commits and around half of them look
> important enough to pick "unconditionally".  The other half I mainly
> lack the context or skills to assess.
> 
> 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".

There was talk of a mid-October 2.26.1 release, but that didn't happen,
as we know.

Are you able to prepare a patch, Marius? If not, I can do it later
tonight.

[0]
https://sourceware.org/ml/libc-alpha/2017-09/msg01134.html

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406 <at> debbugs.gnu.org
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Thu, 23 Nov 2017 16:42:22 +0100

Hello!

Marius Bakke <mbakke <at> fastmail.com> skribis:

> I discovered that 'icu4c' failed to build for x86_64 on 'core-updates'.
> After some investigation, it turns out to be a problem with <math.h> in
> C++ mode, due to its usage of C-only builtins (in the 2.26 release).

[...]

> So I wonder if we should simply pick everything from this branch,
> instead of only the few that fixes immediately visible problems.
> Thoughts?

Cherry-picking like you did sounds reasonable to me.

That said, as discussed on IRC, I think that it’s up to upstream to tell
us what code we should be building, and a simple way to do that is by
making a bug-fix release.

> From 7121dc7ed24e97080154794fb14ae4078a3451f7 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke <at> fastmail.com>
> Date: Wed, 22 Nov 2017 22:26:31 +0100
> Subject: [PATCH] gnu: glibc: Add selected fixes from upstream stable branch.
>
> This backports a small subset of
> <https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.26/master>.
>
> * gnu/packages/patches/glibc-2.26-cpp-fixes.patch,
> gnu/packages/patches/glibc-2.26-ifunc-resolver-longjmp.patch,
> gnu/packages/patches/glibc-2.26-resolver-fixes.patch: New files.
> * gnu/local.mk (dist_patch_DATA): Register them.
> * gnu/packages/base.scm (glibc/linux)[source](patches): Use them.

Great that you created one patch for each category of bug.

LGTM!

After applying, you can restart an evaluation of ‘core-updates’.

Thanks,
Ludo’.

Message #14 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: 29406 <at> debbugs.gnu.org
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Fri, 24 Nov 2017 02:12:09 +0100

[Message part 1 (text/plain, inline)]

Leo Famulari <leo <at> famulari.name> writes:

> On Wed, Nov 22, 2017 at 10:28:49PM +0100, Marius Bakke wrote:
>> Hello!
>> 
>> I discovered that 'icu4c' failed to build for x86_64 on 'core-updates'.
>> After some investigation, it turns out to be a problem with <math.h> in
>> C++ mode, due to its usage of C-only builtins (in the 2.26 release).
>> 
>> Here are the relevant bug reports I've found so far by digging through
>> the "release/2.26/master" branch, aka "2.26 stable"[0]:
>> 
>> <https://sourceware.org/bugzilla/show_bug.cgi?id=21930>
>> <https://sourceware.org/bugzilla/show_bug.cgi?id=22235>
>> <https://sourceware.org/bugzilla/show_bug.cgi?id=22146>
>> <https://sourceware.org/bugzilla/show_bug.cgi?id=22296>
>> 
>> The attached patch includes the fixes from those bugs, as well as a
>> couple of others that looked important.  However it's still a very small
>> subset of the 2.26 post-release fixes.
>> 
>> I've read through _most_ of the commits and around half of them look
>> important enough to pick "unconditionally".  The other half I mainly
>> lack the context or skills to assess.
>> 
>> 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".

I agree.

> There was talk of a mid-October 2.26.1 release, but that didn't happen,
> as we know.
>
> Are you able to prepare a patch, Marius? If not, I can do it later
> tonight.

I ran this command from a glibc git checkout:

  $ git format-patch -p --minimal --no-signature -o ~/guix/gnu/packages/patches/ \
    glibc-2.26..origin/release/2.26/master

Afterwards, in ~/guix/gnu/packages/patches:

  $ rename 's/^(\d{4})-.*\.patch/glibc-2-26-$1.patch/' 00*.patch

And adjusted gnu/local.mk and glibc source accordingly.

The patch is ~30k lines.  WDYT?

[0001-gnu-glibc-Add-fixes-from-upstream-2.26-stable-branch.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: 29406 <at> debbugs.gnu.org
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Fri, 24 Nov 2017 04:08:20 +0100

[Message part 1 (text/plain, inline)]

Marius Bakke <mbakke <at> fastmail.com> writes:

> Leo Famulari <leo <at> famulari.name> writes:
>
>> On Wed, Nov 22, 2017 at 10:28:49PM +0100, Marius Bakke wrote:
>>> Hello!
>>> 
>>> I discovered that 'icu4c' failed to build for x86_64 on 'core-updates'.
>>> After some investigation, it turns out to be a problem with <math.h> in
>>> C++ mode, due to its usage of C-only builtins (in the 2.26 release).
>>> 
>>> Here are the relevant bug reports I've found so far by digging through
>>> the "release/2.26/master" branch, aka "2.26 stable"[0]:
>>> 
>>> <https://sourceware.org/bugzilla/show_bug.cgi?id=21930>
>>> <https://sourceware.org/bugzilla/show_bug.cgi?id=22235>
>>> <https://sourceware.org/bugzilla/show_bug.cgi?id=22146>
>>> <https://sourceware.org/bugzilla/show_bug.cgi?id=22296>
>>> 
>>> The attached patch includes the fixes from those bugs, as well as a
>>> couple of others that looked important.  However it's still a very small
>>> subset of the 2.26 post-release fixes.
>>> 
>>> I've read through _most_ of the commits and around half of them look
>>> important enough to pick "unconditionally".  The other half I mainly
>>> lack the context or skills to assess.
>>> 
>>> 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".
>
> I agree.
>
>> There was talk of a mid-October 2.26.1 release, but that didn't happen,
>> as we know.
>>
>> Are you able to prepare a patch, Marius? If not, I can do it later
>> tonight.
>
> I ran this command from a glibc git checkout:
>
>   $ git format-patch -p --minimal --no-signature -o ~/guix/gnu/packages/patches/ \
>     glibc-2.26..origin/release/2.26/master
>
> Afterwards, in ~/guix/gnu/packages/patches:
>
>   $ rename 's/^(\d{4})-.*\.patch/glibc-2-26-$1.patch/' 00*.patch

There was a major bug in the regexp here: ^

The patch below fixes that, and add CVE identifiers to the patch names.

I realized the glibc graft on master has been classified as low severity
in Debian and not added to the stable releases.  I wish to revert it, or
at the very least remove the graft.  Thoughts?

https://security-tracker.debian.org/tracker/CVE-2017-15670
https://security-tracker.debian.org/tracker/CVE-2017-15671

It also incorrectly mentions that CVE-2017-15671 is fixed, when in fact
that was a different bug entirely.  I have an ugly patch to fix that,
but I'm not sure if it's even worth the hassle.

I will also refrain from doing important work late at night :-(

[0001-gnu-glibc-Add-fixes-from-upstream-2.26-stable-branch.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406 <at> debbugs.gnu.org
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes
 for glibc 2.26.
Date: Mon, 27 Nov 2017 16:30:04 -0500

[Message part 1 (text/plain, inline)]

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.

On IRC Marius said that at least one thing mentioned as "incomplete" in
that thread has been completed on the branch.

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 :)

> [0]
> https://sourceware.org/ml/libc-alpha/2017-09/msg01134.html

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: 29406 <at> debbugs.gnu.org
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Tue, 28 Nov 2017 02:42:05 +0100

[Message part 1 (text/plain, inline)]

Leo Famulari <leo <at> famulari.name> 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>:

[0001-gnu-glibc-Update-to-2.26-91-gaaa2eb83b8.patch (text/x-patch, inline)]

From a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke <at> fastmail.com>
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

[Message part 3 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #26 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Tue, 28 Nov 2017 11:45:40 +0100

Hi,

Marius Bakke <mbakke <at> fastmail.com> skribis:

> From a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke <at> fastmail.com>
> 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"))

I’ve built the tarball locally with the command above but the hash I get is:

  1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk

I did it twice and got the same hash.

This is with:

--8<---------------cut here---------------start------------->8---
$ readlink -f $(type -P git)
/gnu/store/44ahv950sc9qj8b1k86y7rbx4y7z2h3y-git-2.15.0/bin/git
$ readlink -f $(type -P xz)
/gnu/store/9cgv5prf1prqf75dwna4j7824286imyx-xz-5.2.2/bin/xz
$ readlink -f $(type -P tar)
/gnu/store/30zazbgh0lx2pav0ikx5hglgay28264j-tar-1.29/bin/tar
--8<---------------cut here---------------end--------------->8---

Are you using the same tools?

Ludo’.

Message #29 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 29406 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Tue, 28 Nov 2017 13:54:57 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi,
>
> Marius Bakke <mbakke <at> fastmail.com> skribis:
>
>> From a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke <mbakke <at> fastmail.com>
>> 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"))
>
> I’ve built the tarball locally with the command above but the hash I get is:
>
>   1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk

Gah.  I used "xz --threads=0" initially and didn't expect it to change
the outcome.

I can reproduce the above hash by running the same command:

$ git archive --prefix=$(git describe)/ HEAD | xz -9 > $(git describe)-nothreads.tar.xz
$ guix hash glibc-2.26-91-gaaa2eb83b8-nothreads.tar.xz
1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk 

Let's stick with the "nothreads" variant for compatibility.

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 29406-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406-done <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Tue, 28 Nov 2017 17:03:21 +0100

Marius Bakke <mbakke <at> fastmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi,
>>
>> Marius Bakke <mbakke <at> fastmail.com> skribis:
>>
>>> From a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001
>>> From: Marius Bakke <mbakke <at> fastmail.com>
>>> 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"))
>>
>> I’ve built the tarball locally with the command above but the hash I get is:
>>
>>   1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk
>
> Gah.  I used "xz --threads=0" initially and didn't expect it to change
> the outcome.
>
> I can reproduce the above hash by running the same command:
>
> $ git archive --prefix=$(git describe)/ HEAD | xz -9 > $(git describe)-nothreads.tar.xz
> $ guix hash glibc-2.26-91-gaaa2eb83b8-nothreads.tar.xz
> 1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk 
>
> Let's stick with the "nothreads" variant for compatibility.

OK, it’s now available at
<https://alpha.gnu.org/gnu/guix/mirror/glibc-2.26-91-gaaa2eb83b8.tar.xz>.

Thank you!

Ludo’.

Message #37 received at 29406-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 29406-done <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Tue, 28 Nov 2017 18:16:20 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Marius Bakke <mbakke <at> fastmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hi,
>>>
>>> Marius Bakke <mbakke <at> fastmail.com> skribis:
>>>
>>>> From a5b022a355a0babdc4809f39f94b6662ea7789d1 Mon Sep 17 00:00:00 2001
>>>> From: Marius Bakke <mbakke <at> fastmail.com>
>>>> 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"))
>>>
>>> I’ve built the tarball locally with the command above but the hash I get is:
>>>
>>>   1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk
>>
>> Gah.  I used "xz --threads=0" initially and didn't expect it to change
>> the outcome.
>>
>> I can reproduce the above hash by running the same command:
>>
>> $ git archive --prefix=$(git describe)/ HEAD | xz -9 > $(git describe)-nothreads.tar.xz
>> $ guix hash glibc-2.26-91-gaaa2eb83b8-nothreads.tar.xz
>> 1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk 
>>
>> Let's stick with the "nothreads" variant for compatibility.
>
> OK, it’s now available at
> <https://alpha.gnu.org/gnu/guix/mirror/glibc-2.26-91-gaaa2eb83b8.tar.xz>.
>
> Thank you!

Typical: The 2.26 branch just got 10 new commits that look important:

https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.26/master

Especially the malloc() fixes.  Should we pick them while we still have
time, or update the snapshot?

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 29406 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes
 for glibc 2.26.
Date: Tue, 28 Nov 2017 13:26:44 -0500

[Message part 1 (text/plain, inline)]

On Tue, Nov 28, 2017 at 01:54:57PM +0100, Marius Bakke wrote:
> Gah.  I used "xz --threads=0" initially and didn't expect it to change
> the outcome.

Since threads=0 means "compress with as many CPU cores as are
available", I'd guess the output of this depends on the number of
threads used.

from man(1):
"Setting threads to a special value 0 makes xz use as many threads as
there are CPU cores on the system."

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 29406-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 29406-done <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Tue, 28 Nov 2017 22:02:04 +0100

Marius Bakke <mbakke <at> fastmail.com> skribis:

> Typical: The 2.26 branch just got 10 new commits that look important:
>
> https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.26/master
>
> Especially the malloc() fixes.  Should we pick them while we still have
> time, or update the snapshot?

Your call!  :-)

Maybe we can focus on building more on the branch, and revisit this
issue when we’re ready to build the whole branch.  (Or are we ready
yet?)

WDYT?

Ludo’.

Message #46 received at 29406-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 29406-done <at> debbugs.gnu.org, Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes
 for glibc 2.26.
Date: Tue, 28 Nov 2017 16:42:04 -0500

[Message part 1 (text/plain, inline)]

On Tue, Nov 28, 2017 at 10:02:04PM +0100, Ludovic Courtès wrote:
> Marius Bakke <mbakke <at> fastmail.com> skribis:
> 
> > Typical: The 2.26 branch just got 10 new commits that look important:
> >
> > https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.26/master
> >
> > Especially the malloc() fixes.  Should we pick them while we still have
> > time, or update the snapshot?
> 
> Your call!  :-)
> 
> Maybe we can focus on building more on the branch, and revisit this
> issue when we’re ready to build the whole branch.  (Or are we ready
> yet?)
> 
> WDYT?

I think there's not much to do without at least some of the glibc
patches, because icu4c fails to build.

I think we should take all the glibc patches, try building core, then
everything.

[signature.asc (application/pgp-signature, inline)]

Message #49 received at 29406-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Leo Famulari <leo <at> famulari.name>
Cc: 29406-done <at> debbugs.gnu.org, Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for
 glibc 2.26.
Date: Wed, 29 Nov 2017 17:40:17 +0100

Leo Famulari <leo <at> famulari.name> skribis:

> On Tue, Nov 28, 2017 at 10:02:04PM +0100, Ludovic Courtès wrote:
>> Marius Bakke <mbakke <at> fastmail.com> skribis:
>> 
>> > Typical: The 2.26 branch just got 10 new commits that look important:
>> >
>> > https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.26/master
>> >
>> > Especially the malloc() fixes.  Should we pick them while we still have
>> > time, or update the snapshot?
>> 
>> Your call!  :-)
>> 
>> Maybe we can focus on building more on the branch, and revisit this
>> issue when we’re ready to build the whole branch.  (Or are we ready
>> yet?)
>> 
>> WDYT?
>
> I think there's not much to do without at least some of the glibc
> patches, because icu4c fails to build.

The glibc tarball I uploaded does fix icu4c, doesn’t it?

Anyway I’m happy to update another tarball when you want!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.