From Fedora Project Wiki
< Changes
No edit summary |
|||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 38: | Line 38: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/26 | Fedora 26 ]] | * Targeted release: [[Releases/26 | Fedora 26 ]] | ||
* Last updated: | * Last updated: 2017-02-03 | ||
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
Bugzilla states meaning as usual: | Bugzilla states meaning as usual: | ||
| Line 47: | Line 47: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1425334 #1425334] | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
The GNU C Library version 2.25 will be released at the beginning of February 2017; we have started closely tracking the glibc 2.25 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 26 will branch after the GLIBC 2.25 upstream release. | The GNU C Library version 2.25 will be released at the beginning of February 2017; we have started closely tracking the glibc 2.25 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 26 will branch after the GLIBC 2.25 upstream release. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 68: | Line 64: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: Aside from Carlos O'Donell <carlos@redhat.com>, Florian Weimer <fweimer@redhat.com>, Torvald Riegel <triegel@redhat.com>, Martin Sebor <msebor@redhat.com>, and Patsy Franklin <pfrankli@redhat.com>, no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 26 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated.<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: Aside from Carlos O'Donell <carlos@redhat.com>, DJ Delorie <dj@redhat.com>, Florian Weimer <fweimer@redhat.com>, Torvald Riegel <triegel@redhat.com>, Martin Sebor <msebor@redhat.com>, and Patsy Franklin <pfrankli@redhat.com>, no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 26 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated.<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: | * Release engineering: All Fedora releases must be released using a released version of glibc. The Fedora glibc team is responsible for ensuring that Fedora Rawhide stabilizes ABI before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by glibc or other components, the Fedora glibc team will ensure coordination with release engineering such that a mass rebuild uses the released version of glibc to fix any last minute ABI changes. The GNU C Library (glibc) does not require a mass rebuild for this release. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | ||
| Line 110: | Line 106: | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
All packages do not need to be rebuilt. | All packages do not need to be rebuilt, but applications will benefit from the mass rebuild, so that they pick up the new <code>getrandom</code>, <code>getentropy</code> and <code>explicit_bzero</code> symbols. | ||
== Contingency Plan == | == Contingency Plan == | ||
| Line 135: | Line 131: | ||
The GNU C Library version 2.25 will be released at the beginning of Feburary 2017. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD | The GNU C Library version 2.25 will be released at the beginning of Feburary 2017. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD | ||
[[Category: | [[Category:ChangeAcceptedF26]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Latest revision as of 09:05, 21 February 2017
The GNU C Library version 2.25
Summary
Switch glibc in Fedora 26 to glibc version 2.25.
Owner
- Name: Carlos O'Donell
- Email: carlos@redhat.com
- Release notes owner:
Current status
Detailed Description
The GNU C Library version 2.25 will be released at the beginning of February 2017; we have started closely tracking the glibc 2.25 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 26 will branch after the GLIBC 2.25 upstream release.
Benefit to Fedora
Stays up to date with latests security and bug fixes from glibc.
The packaging changes will provide a small reduction in disk space needed by minimal installations.
Scope
- Proposal owners: Update glibc to 2.25 from tested upstream release.
- Other developers: Aside from Carlos O'Donell <carlos@redhat.com>, DJ Delorie <dj@redhat.com>, Florian Weimer <fweimer@redhat.com>, Torvald Riegel <triegel@redhat.com>, Martin Sebor <msebor@redhat.com>, and Patsy Franklin <pfrankli@redhat.com>, no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 26 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated.
- Release engineering: All Fedora releases must be released using a released version of glibc. The Fedora glibc team is responsible for ensuring that Fedora Rawhide stabilizes ABI before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by glibc or other components, the Fedora glibc team will ensure coordination with release engineering such that a mass rebuild uses the released version of glibc to fix any last minute ABI changes. The GNU C Library (glibc) does not require a mass rebuild for this release.
- Policies and guidelines: The policies and guidelines do not need to be updated.
Upgrade/compatibility impact
The library is backwards compatible with the version of glibc that was shipped in Fedora 25.
Some packaging changes required, see: https://sourceware.org/glibc/wiki/Release/2.25#Packaging_Changes
We fully expect to fix all packaging changes in Fedora Rawhide given that glibc in Rawhide is tracking what will become glibc 2.25.
How To Test
The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 1000+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones.
User Experience
Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. The glibc 2.25 NEWS update will include more details.
Dependencies
All packages do not need to be rebuilt, but applications will benefit from the mass rebuild, so that they pick up the new getrandom, getentropy and explicit_bzero symbols.
Contingency Plan
- Contingency mechanism: Given that Rawhide has started tracking GLIBC 2.25, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.24 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API.
- Contingency deadline: Alpha freeze.
- Blocks release? Upgrading glibc does block the release. We should not ship without a newer glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations.
Documentation
The glibc manual contains the documentation for the release and doesn't need any more additional work.
Release Notes
The GNU C Library version 2.25 will be released at the beginning of Feburary 2017. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD