(Add note that rebase to 2.31 supersedes this rebase) |
(review doc) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 7: | Line 7: | ||
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG | * coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG | ||
System Wide Changes are: | System-Wide Changes are: | ||
* changes that | * changes that do not fit Self Contained Changes category touching | ||
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.) | * changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.) | ||
* changing system defaults | * changing system defaults | ||
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is | For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM-WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is improper or updated to System Wide category). System-Wide Changes all fields on this form are required for FESCo acceptance (when applies). | ||
improper or updated to System Wide category). | |||
We request that you maintain the same order of sections so that all of the change proposal pages are uniform. | We request that you maintain the same order of sections so that all of the change proposal pages are uniform. | ||
Line 33: | Line 32: | ||
--> | --> | ||
* Name: [[User:nickc|Nick Clifton]] | * Name: [[User:nickc|Nick Clifton]] | ||
<!-- Include | <!-- Include your email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: nickc@redhat.com | * Email: nickc@redhat.com | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | ||
Line 50: | Line 49: | ||
Bugzilla states meaning as usual: | Bugzilla states meaning as usual: | ||
NEW -> change proposal is submitted and announced | NEW -> change proposal is submitted and announced | ||
ASSIGNED -> accepted by FESCo with | ASSIGNED -> accepted by FESCo with ongoing development | ||
MODIFIED -> change is substantially done and testable | MODIFIED -> change is substantially done and testable | ||
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA) | ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA) | ||
Line 60: | Line 59: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences | <!-- Expand on the summary, if appropriate. A couple sentences suffice to explain the goal, but the more details you can provide the better. --> | ||
Switch the binutils package from being based on the 2.29.1 release of the FSF binutils to being based on the 2.30 release. This release includes bug-fixes and new features. | Switch the binutils package from being based on the 2.29.1 release of the FSF binutils to being based on the 2.30 release. This release includes bug-fixes and new features. | ||
Line 67: | Line 66: | ||
The new release includes the "-z undefs" linker option which can be used to revert the "-z defs" option. This can be useful as "-z defs" is now part of the standard command line when building packages, but can cause problems in some circumstances. | The new release includes the "-z undefs" linker option which can be used to revert the "-z defs" option. This can be useful as "-z defs" is now part of the standard command line when building packages, but can cause problems in some circumstances. | ||
In addition the readelf and objdump tools now have the ability to parse and follow links to separate debug information files, so their output will be more useful to developers that use this feature. | In addition, the readelf and objdump tools now have the ability to parse and follow links to separate debug information files, so their output will be more useful to developers that use this feature. | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
Replace the 2.29.1 source tarball with the 2.30 source tarball and update the Fedora specific patches. (This work has already been completed locally and is ready for comitting). | Replace the 2.29.1 source tarball with the 2.30 source tarball and update the Fedora-specific patches. (This work has already been completed locally and is ready for comitting). | ||
* Other developers: None. | * Other developers: None. | ||
Line 87: | Line 86: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
The binutils are | The binutils are backward compatible with previous releases, so no changes should be necessary. | ||
== How To Test == | == 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. | 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. | ||
Line 117: | Line 116: | ||
None needed. | None needed. | ||
[[Category: | [[Category:ChangeRejected]] | ||
<!-- 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 13:06, 8 August 2018
BINUTILS 2.30
Summary
Rebase the binutils package from version 2.29 .1 to version 2.30. This will bring in bug-fixes and some new features.
Note - this change has now been superseded by a rebase to GNU Binutils 2.31: https://fedoraproject.org/wiki/Changes/BINUTILS231
Owner
- Name: Nick Clifton
- Email: nickc@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 29
- Last updated: 2018-08-08
- Tracker bug: #1551329
- Release Notes tracking: #121
Detailed Description
Switch the binutils package from being based on the 2.29.1 release of the FSF binutils to being based on the 2.30 release. This release includes bug-fixes and new features.
Benefit to Fedora
The new release includes the "-z undefs" linker option which can be used to revert the "-z defs" option. This can be useful as "-z defs" is now part of the standard command line when building packages, but can cause problems in some circumstances.
In addition, the readelf and objdump tools now have the ability to parse and follow links to separate debug information files, so their output will be more useful to developers that use this feature.
Scope
- Proposal owners:
Replace the 2.29.1 source tarball with the 2.30 source tarball and update the Fedora-specific patches. (This work has already been completed locally and is ready for comitting).
- Other developers: None.
- Release engineering: https://pagure.io/releng/issue/7282
A mass rebuild is required.
- List of deliverables: Just the binutils packages.
- Policies and guidelines: No updates needed.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The binutils are backward 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.
Contingency Plan
- Contingency mechanism: Revert to the 2.29.1 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
The binutils are documented here: https://sourceware.org/binutils/ This page includes links to the manuals and NEWS files detailing the new features. The new release was announced here: https://www.sourceware.org/ml/binutils/2018-01/msg00381.html
Release Notes
None needed.