The GNU C Library will be rebased in F21 to match glibc 2.20.

[Siddhesh Poyarekar]

On Thu, Jul 31, 2014 at 09:03:45AM -0400, Rahul Sundaram wrote:
> Yes.  My concern is that glibc is using Rawhide as their continuous
> integration sandbox to shake out bugs as opposed to doing it elsewhere and
> just taking care of integration of releases when they are ready.   If this
> viewed as a gap that needs to be fixed, that's fine for now.

CI is indeed a gap that needs to be fixed, but rebasing in rawhide
isn't nearly as fatal as it seems.  The upstream glibc commit policy
is quite stringent in that every commit is required to pass an
extensive (but obviously not exhaustive) testsuite and as a result it
is usually safe (as safe one would consider rawhide) to rebase from
the latest commit.  I've been doing regular rebases for a while now
(almost a year AFAICT) and IIRC we have had just one serious problem
last week where i686 boxes got bricked.  In the end it was found to be
a gcc bug that miscompiled some code in glibc.

That said, we still need a nicer way to back out from a broken glibc
update into the previous known-to-work glibc similar to how the kernel
does it and not need a rescue disk for it.

Siddhesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140731/2d9e2575/attachment.sig>