From Fedora Project Wiki
(update release note tracker)
 
(28 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
{{admon/tip | Report issues | To report an issue with this template, file an issue in the [https://pagure.io/fedora-pgm/pgm_docs pgm_docs repo].}}
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= LLVM 17 <!-- The name of your change proposal --> =
= LLVM 17 <!-- The name of your change proposal --> =


{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
Line 28: Line 21:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF39]]
<!-- 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 -->
Line 46: Line 39:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* [<will be assigned by the Wrangler> devel thread]
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DCX54HQNCPT56XDGVXXTHMDPGHJWKT7A/ devel thread]
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3034 #3034]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2233282 #2233282]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/1011 #1011]


== Detailed Description ==
== Detailed Description ==
Line 59: Line 52:
* The Clang Resource Directory will be moved from /usr/lib64/clang/17/ to /usr/lib/clang/17/ this is the location of clang's internal headers and runtime libraries like libomp and compiler-rt.  Package owners of packages that read or write this directory will need to update their packages when rebuilding against/with LLVM 17.  The %clang_resource_dir helper macro can be used to make this transition smoother, and packages are encouraged to update to use this macro even before the LLVM 17 update.
* The Clang Resource Directory will be moved from /usr/lib64/clang/17/ to /usr/lib/clang/17/ this is the location of clang's internal headers and runtime libraries like libomp and compiler-rt.  Package owners of packages that read or write this directory will need to update their packages when rebuilding against/with LLVM 17.  The %clang_resource_dir helper macro can be used to make this transition smoother, and packages are encouraged to update to use this macro even before the LLVM 17 update.


* Along with the Clang Resource Directory change, compiler-rt will now install its libraries into /usr/lib/clang/16/lib/$TRIPLE/ instead of /usr/lib64/clang/16/lib/
* Along with the Clang Resource Directory change, compiler-rt will now install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of /usr/lib64/clang/17/lib/
 
* The macros.clang file with RPM macros will be moved from the clang-devel package to the clang-resource-filesystem package.


===LLVM Build Schedule===
===LLVM Build Schedule===
Line 73: Line 68:
* Aug  25: Upstream: 17.0.0-rc3 Release
* Aug  25: Upstream: 17.0.0-rc3 Release
* Sep  8: Upstream: 17.0.0 Release
* Sep  8: Upstream: 17.0.0 Release
* Oct  10: Fedora: f38 Final Freeze
* Oct  10: Fedora: f39 Final Freeze


====Plan====
====Plan====


#Build LLVM 17.0.0-rc1 in COPR.
# Build LLVM 17.0.0-rc1 in COPR.
#Build LLVM 17.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc1 into a rawhide side-tag in Koji.
#Build LLVM 17.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc1 into a f39 side-tag in Koji.
#Build LLVM 17.0.0-rc2 into a f39 side-tag.
# Build LLVM 17.0.0-rc2 into a rawhide side-tag in Koji.
#Push F39 Bodhi Update with 17.0.0-rc2 (or 17.0.0-rc1 if -rc2 is not ready) prior to the Beta Freeze.
# Build LLVM 17.0.0-rc2 into a f39 side-tag in Koji.
#Continue building new release candidates and pushing them to stable until the Final Freeze.
# Push F39 Bodhi Update with 17.0.0-rc2 (or 17.0.0-rc1 if -rc2 is not ready) prior to the Beta Freeze.
# Continue building new release candidates and pushing them to stable until the Final Freeze.
 
We are not planning to push 17.0.0-rc1 into rawhide because the library ABI is not stabilized at that point. Typically, the ABI stabilizes after -rc2, but there are no guarantees from upstream about this.  Given the history of minimal ABI changes after -rc2, we feel like it's safe to push -rc2 into rawhide.  The worst case scenario would be an ABI change -rc3 that we force us to patch LLVM to maintain compatibility with the -rc2 ABI.  This scenario would not require rebuilding LLVM library uses in Fedora, so this would not require much extra work from our team.
 
Updates after 17.0.0-rc2 will generally be very small and can be done after the Final Freeze is over.  If we are late packaging -rc3 or the final release, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.


== Feedback ==
== Feedback ==
Line 121: Line 121:
<!-- 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?-->
** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
** Do scratch builds of Fedora packages that depend on llvm and report issues to package maintainer.


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- 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?-->
** Fix build issues found with LLVM-17 or switch their package to use the llvm16 compat libs.  The LLVM team no longer plans to block Bodhi updates on dependent packages that fail to build or run with LLVM-17.  There should be around 6-8 weeks between when -rc1 lands in koji and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-17 update.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issues/11455] <!-- 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 -->
Line 142: Line 144:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
This change should not impact upgradeability.


== How To Test ==
== How To Test ==
Line 160: Line 162:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 17.


== User Experience ==
== User Experience ==
Line 178: Line 180:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
Packages that depend on one of the llvm packages will need to be updated to work with LLVM17 or will need to switch to using one of the llvm16 compat packages.


== Contingency Plan ==
== Contingency Plan ==


<!-- 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: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism:  If there are major problems with LLVM 17, the compatibility package provide a way for other packages to continue using LLVM 16. <!-- 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: N/A (not a System Wide Change) <!-- 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? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== Documentation ==
== Documentation ==
Line 194: Line 195:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
Release notes will be added for this change.


== Release Notes ==
== Release Notes ==
Line 202: Line 203:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
LLVM sub-projects in Fedora have been updated to version 17:
*llvm
*clang
*lld
*lldb
*compiler-rt
*libomp
*llvm-test-suite
*libcxx
*python-lit
*flang
*mlir
*polly
*libclc
*llvm-bolt

Latest revision as of 23:20, 28 September 2023


LLVM 17

Summary

Update all llvm sub-projects in Fedora Linux to version 17.

Owner

Current status

Detailed Description

All llvm sub-projects in Fedora will be updated to version 17, and there will be a soname version change for the llvm libraries. Compatibility packages clang16, llvm16, and lld16 will be added to ensure that packages that currently depend on clang and llvm version 16 libraries will continue to work.

Other notable changes:

  • The Clang Resource Directory will be moved from /usr/lib64/clang/17/ to /usr/lib/clang/17/ this is the location of clang's internal headers and runtime libraries like libomp and compiler-rt. Package owners of packages that read or write this directory will need to update their packages when rebuilding against/with LLVM 17. The %clang_resource_dir helper macro can be used to make this transition smoother, and packages are encouraged to update to use this macro even before the LLVM 17 update.
  • Along with the Clang Resource Directory change, compiler-rt will now install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of /usr/lib64/clang/17/lib/
  • The macros.clang file with RPM macros will be moved from the clang-devel package to the clang-resource-filesystem package.

LLVM Build Schedule

We will be changing our build schedule slightly from previous Fedora releases. We will now plan to ship a release candidate in Fedora build prior to the Beta Freeze rather than waiting until after.

Important Dates

  • July 28: Upstream: 17.0.0-rc1 Release
  • Aug 8: Fedora: f39 branch created
  • Aug 11: Upstream: 17.0.0-rc2 Release
  • Aug 22: Fedora: f39 Beta Freeze
  • Aug 25: Upstream: 17.0.0-rc3 Release
  • Sep 8: Upstream: 17.0.0 Release
  • Oct 10: Fedora: f39 Final Freeze

Plan

  1. Build LLVM 17.0.0-rc1 in COPR.
  2. Build LLVM 17.0.0-rc1 into a rawhide side-tag in Koji.
  3. Build LLVM 17.0.0-rc1 into a f39 side-tag in Koji.
  4. Build LLVM 17.0.0-rc2 into a rawhide side-tag in Koji.
  5. Build LLVM 17.0.0-rc2 into a f39 side-tag in Koji.
  6. Push F39 Bodhi Update with 17.0.0-rc2 (or 17.0.0-rc1 if -rc2 is not ready) prior to the Beta Freeze.
  7. Continue building new release candidates and pushing them to stable until the Final Freeze.

We are not planning to push 17.0.0-rc1 into rawhide because the library ABI is not stabilized at that point. Typically, the ABI stabilizes after -rc2, but there are no guarantees from upstream about this. Given the history of minimal ABI changes after -rc2, we feel like it's safe to push -rc2 into rawhide. The worst case scenario would be an ABI change -rc3 that we force us to patch LLVM to maintain compatibility with the -rc2 ABI. This scenario would not require rebuilding LLVM library uses in Fedora, so this would not require much extra work from our team.

Updates after 17.0.0-rc2 will generally be very small and can be done after the Final Freeze is over. If we are late packaging -rc3 or the final release, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.

Feedback

Benefit to Fedora

New features and bug fixes provided by the latest version of LLVM.

Scope

  • Proposal owners:
    • Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
    • Do scratch builds of Fedora packages that depend on llvm and report issues to package maintainer.
  • Other developers:
    • Fix build issues found with LLVM-17 or switch their package to use the llvm16 compat libs. The LLVM team no longer plans to block Bodhi updates on dependent packages that fail to build or run with LLVM-17. There should be around 6-8 weeks between when -rc1 lands in koji and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-17 update.
  • Release engineering: [1]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

This change should not impact upgradeability.

How To Test

The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 17.

User Experience

Dependencies

Packages that depend on one of the llvm packages will need to be updated to work with LLVM17 or will need to switch to using one of the llvm16 compat packages.

Contingency Plan

  • Contingency mechanism: If there are major problems with LLVM 17, the compatibility package provide a way for other packages to continue using LLVM 16.
  • Contingency deadline: Beta Freeze
  • Blocks release? No

Documentation

Release notes will be added for this change.

Release Notes

LLVM sub-projects in Fedora have been updated to version 17:

  • llvm
  • clang
  • lld
  • lldb
  • compiler-rt
  • libomp
  • llvm-test-suite
  • libcxx
  • python-lit
  • flang
  • mlir
  • polly
  • libclc
  • llvm-bolt