< Changes
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
<!-- Self Contained or System Wide Change Proposal? | <!-- Self Contained or System Wide Change Proposal? | ||
Use this guide to determine to which category your proposed change belongs to. | Use this guide to determine to which category your proposed change belongs to. | ||
| Line 109: | Line 107: | ||
* Release engineering: [https://pagure.io/releng/issue/8837] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: [https://pagure.io/releng/issue/8837] <!-- 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 rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
A mass rebuild will be required. | |||
* Policies and guidelines: No update needed. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Policies and guidelines: No update needed. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 121: | Line 120: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
The binutils are backwards compatible with previous releases, so no changes should be necessary. | The binutils are backwards compatible with previous releases, so no changes should be necessary. | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 157: | Line 157: | ||
- Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system. | - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system. | ||
--> | --> | ||
The change should not be noticeable to the user. | The change should not be noticeable to the user. | ||
| Line 163: | Line 164: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
This update has no hard dependencies on any other package. | This update has no hard dependencies on any other package. | ||
There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config. | There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config. | ||
| Line 169: | Line 171: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: Revert to the 2.32 binutils as currently used in rawhide. This work can be done by me, should it prove necessary. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: Revert to the 2.32 binutils as currently used in rawhide. This work can be done by me, should it prove necessary. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: Beta Freeze. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: Beta Freeze. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revision as of 10:07, 25 September 2019
Binutils 2.33
Summary
Rebase the binutils package from version 2.32 to version 2.33.
Owner
- Name: Nick Clifton [1]
- Email: nickc@redhat.com
Current status
- Targeted release: Fedora 32
- Last updated: 2019-09-25
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Switch the binutils package from being based on the 2.32 release of the GNU binutils to being based on the 2.33 release. This release will bring in numerous bug fixes, as well as support for the CTF debug format.
Benefit to Fedora
The main benefit will be the bug fixes and the improvement to the linker. In addition the new support for the CTF debug format will help consumers of CTF, most notably the kernel.
Scope
- Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed. This is a significant change to the underlying tools used to build Fedora and so there should be a mass rebuild in order for the changes to be noticed across the system.
- Other developers:
No other work should be necessary. Once the rebase is in place and the buildroot contains the new binutils its use should be automatic.
- Release engineering: [2]
A mass rebuild will be required.
- Policies and guidelines: No update needed.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The binutils are backwards compatible with previous releases, so no changes should be necessary.
How To Test
The binutils package does include its own set of testsuites which check basic functionality. The real test however is by rebuilding other packages which depend upon the binutils, or more likely, upon gcc. If these packages continue to work then the binutils update has not broken anything.
User Experience
The change should not be noticeable to the user.
Dependencies
This update has no hard dependencies on any other package. There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config.
Contingency Plan
- Contingency mechanism: Revert to the 2.32 binutils as currently used in rawhide. This work can be done by me, should it prove necessary.
- Contingency deadline: Beta Freeze.
- Blocks release? No
- Blocks product? None
Documentation
Documentation is not currently available, due to the fact that the 2.33 release has not yet been created. (It is hoped that the release will happen before the Fedora 32 mass rebuild).