GNU bug report logs - #30873
[PATCH core-updates 0/3] glibc 2.27

Previous Next

Package: guix-patches;

Reported by: Marius Bakke <mbakke <at> fastmail.com>

Date: Tue, 20 Mar 2018 10:22:02 UTC

Severity: normal

Tags: patch

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#30873: closed ([PATCH core-updates 0/3] glibc 2.27)
Date: Thu, 22 Mar 2018 18:37:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Thu, 22 Mar 2018 19:36:47 +0100
with message-id <87fu4sklds.fsf <at> fastmail.com>
and subject line Re: [bug#30873] [PATCH core-updates 1/3] gnu: glibc: Update to 2.27.
has caused the debbugs.gnu.org bug report #30873,
regarding [PATCH core-updates 0/3] glibc 2.27
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
30873: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30873
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Marius Bakke <mbakke <at> fastmail.com>
To: guix-patches <at> gnu.org
Cc: Marius Bakke <mbakke <at> fastmail.com>
Subject: [PATCH core-updates 0/3] glibc 2.27
Date: Tue, 20 Mar 2018 11:20:45 +0100
These patches allow building the world with glibc 2.27.  Apart from
"make", packages seem generally happy with this version.

I opted for a unified diff of all post-release updates instead of
individual patches.  It is "only" 12k lines so far.

Marius Bakke (3):
  gnu: glibc: Update to 2.27.
  gnu: make: Fix compatibility with glibc 2.27.
  gnu: make: End phase on #t.

 gnu/local.mk                                       |     3 +
 gnu/packages/base.scm                              |    60 +-
 gnu/packages/commencement.scm                      |     3 +-
 gnu/packages/patches/glibc-2.27-git-fixes.patch    | 12765 +++++++++++++++++++
 .../patches/glibc-hidden-visibility-ldconfig.patch |    16 +
 gnu/packages/patches/make-glibc-compat.patch       |    52 +
 6 files changed, 12875 insertions(+), 24 deletions(-)
 create mode 100644 gnu/packages/patches/glibc-2.27-git-fixes.patch
 create mode 100644 gnu/packages/patches/glibc-hidden-visibility-ldconfig.patch
 create mode 100644 gnu/packages/patches/make-glibc-compat.patch

-- 
2.16.2



[Message part 3 (message/rfc822, inline)]
From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 30873-done <at> debbugs.gnu.org
Subject: Re: [bug#30873] [PATCH core-updates 1/3] gnu: glibc: Update to 2.27.
Date: Thu, 22 Mar 2018 19:36:47 +0100
[Message part 4 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:

> Heya Marius!
>
> Marius Bakke <mbakke <at> fastmail.com> skribis:
>
>> There are actually not a lot of high severity fixes in 2.27 yet.  I
>> opted for this mostly as a proof-of-concept for a couple of reasons.
>
> Good.  :-)
>
>> The question is which do we pick?  Portability fixes for arches we don't
>> (yet) support?  Some of the locale fixes seem genuine, and not just
>> typos, e.g.:
>>
>> * https://sourceware.org/bugzilla/show_bug.cgi?id=22517
>> * https://sourceware.org/bugzilla/show_bug.cgi?id=22848
>
> [...]
>
>> But, we risk missing important commits this way, and may cause headaches
>> for people wanting to port Guix to a new architecture.  And the approach
>> doesn't really scale for branches approaching ~100 commits.
>>
>> Regardless, here is a patch with just the above commits.  Let me know if
>> you spot others in the history that look important.  WDYT?
>
> “Which ones do we pick” summarizes the problem, I think.  It’s
> upstream’s job to pick a set of changes and declare a new release.  It
> seems to me that we’re kinda doing the glibc release manager’s job here,
> except we lack insight compared to them: it’s harder for us to judge
> which changes are critical, which changes are just the beginning of
> broader modifications/fixes, etc.
>
> I’d be willing to just use upstream’s release.  It has bugs, no doubts,
> but the next release will have its own bugs too.  :-)  Furthermore,
> SONAMEs and symbol versioning is quite critical, but it’s usually done
> under the assumption that people use releases, not intermediate
> snapshots.
>
> I understand that glibc’s 2.27 branch is stable, contains nothing but
> bug fixes, and in that sense is rather safe.  Still…
>
> WDYT?

I pushed the patch with the cherry-picked fixes.  I'd rather not
knowingly break "date" on some locales, or introduce runtime issues on
i686.  But I do agree that these things should really be upstreams job.

All the distros I've checked take the entire branch, so we are the "odd
kid out".  But I guess that's nothing new.  ;-)

> BTW, what about emailing the libc people to add you to the list of
> distro maintainers at <https://sourceware.org/glibc/wiki/MAINTAINERS>?
> I think it could be useful.

That might be useful indeed.  I'll look into it.

I think we're getting ready to build core-updates now.  Should we try
starting the 'core' subset on Hydra?  Maybe also set a 'freeze' date?
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 7 years and 60 days ago.

Previous Next


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