[Top][All Lists]

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

[bug#30873] [PATCH core-updates 1/3] gnu: glibc: Update to 2.27.

From: Marius Bakke
Subject: [bug#30873] [PATCH core-updates 1/3] gnu: glibc: Update to 2.27.
Date: Tue, 20 Mar 2018 17:54:36 +0100
User-agent: Notmuch/0.26 ( Emacs/25.3.1 (x86_64-pc-linux-gnu)

Ludovic Courtès <address@hidden> writes:

> Hello!
> Thanks for working on this update!  Crazy that it turned out to be this
> difficult.
> Marius Bakke <address@hidden> skribis:
>> +++ b/gnu/packages/patches/glibc-2.27-git-fixes.patch
>> @@ -0,0 +1,12765 @@
>> +This patch includes all post-release fixes for version 2.27 up to commit
>> +3b922526415d1af93fe5a0e3caf7e6a790cb1619.
>> +
>> +;a=shortlog;h=refs/heads/release/2.27/master
>> +
>> +Generated by "git diff glibc-2.27..release/2.27/master".
> In general I’d be in favor of not doing that, unless the fixes are
> important (build issue, security issue, etc.), as was the case when we
> packaged 2.26; and, if there are important fixes, I’d rather extract
> them from the whole patch stream, and skip unrelated changes.
> For example, I’m sure we can live without the locale updates that show
> up in this patch set.  :-)
> Do you know which of these patches are really needed?
> Thoughts?


I was hoping you'd comment on this ;-)

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.

* Giving the GNU C Library special treatment is OK IMO.
* In 2.26, cherry-picking individual fixes was not feasible.
** However, using the same method, the 2.26 diff is "only" 27k lines/904k.

It does mean growing the Guix repository up to ~1MiB every six months,
but in the large scale of things, it doesn't seem that bad.

Yet, I'm not sure if it makes sense to do this now.  There are only a
handful of "important" commits on 2.27 so far.  Additionally, the 2.27
release manager has said he would do 2.27.1 once (if?) enough patches
has piled up, so maybe there is hope for the future.

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


Actually, now that I've scoured the history, reverting this one commit
brings the patch from 12921 to 2391 lines:

~2k isn't too bad IMO.  Yet, I've attached a patch with only the
following commits, and without NEWS and ChangeLog updates.  It's 547
lines, which is more palatable; but may grow longer than the unified
approach since it includes git commit logs.


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?

I suppose we'll have to revisit this with every 'core-updates'.  :-)

Attachment: 0001-gnu-glibc-Update-to-2.27.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature

reply via email to

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