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

[Marius Bakke <mbakke@fastmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

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

> Heya Marius!
>
> Marius Bakke <mbakke@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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]