emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#29406: closed ([PATCH core-updates]: Add selected


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#29406: closed ([PATCH core-updates]: Add selected upstream fixes for glibc 2.26.)
Date: Tue, 28 Nov 2017 16:04:01 +0000

Your message dated Tue, 28 Nov 2017 17:03:21 +0100
with message-id <address@hidden>
and subject line Re: [bug#29406] [PATCH core-updates]: Add selected upstream 
fixes for glibc 2.26.
has caused the debbugs.gnu.org bug report #29406,
regarding [PATCH core-updates]: Add selected upstream fixes for glibc 2.26.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
29406: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29406
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH core-updates]: Add selected upstream fixes for glibc 2.26. Date: Wed, 22 Nov 2017 22:28:49 +0100 User-agent: Notmuch/0.25.2 (https://notmuchmail.org) Emacs/25.3.1 (x86_64-pc-linux-gnu)
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

Attachment: 0001-gnu-glibc-Add-selected-fixes-from-upstream-stable-br.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- Subject: Re: [bug#29406] [PATCH core-updates]: Add selected upstream fixes for glibc 2.26. Date: Tue, 28 Nov 2017 17:03:21 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Marius Bakke <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> Hi,
>>
>> Marius Bakke <address@hidden> skribis:
>>
>>> 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"))
>>
>> 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’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]