From Fedora Project Wiki
m (Marking as rejected, superseded by https://fedoraproject.org/wiki/Changes/BINUTILS231)
(review doc)
 
Line 8: Line 8:


System-Wide Changes are:
System-Wide Changes are:
* changes that does not fit Self Contained Changes category touching  
* 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 improper or updated to System Wide category). System Wide Changes all fields on this form are required for FESCo acceptance (when applies).   
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).   


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 86: Line 86:


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no changes should be necessary.  
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.  
   
   



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

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.

A mass rebuild is required.


  • 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.