F44 Change Proposal: LLVM-22 [SystemWide]

Project Discussion Change Proposals
, ,
1

LLVM-22

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

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

Owner :open_book:

Detailed Description :open_book:

All llvm sub-projects in Fedora will be updated to version 22. There will be a soname version change for the llvm libraries, and an llvm21 compat package added to ensure that packages that currently depend on clang and llvm version 21 libraries will continue to work.

Other notable changes:
*flang merged into llvm The flang RPMs are now built from the llvm SRPM.

=== Planned Schedule ===
Our plan is to push 22.1.0 into Fedora 44 during the Beta Freeze with a Beta Freeze exception.

We are not planning to push earlier release candidates into rawhide because the library ABI is not stabilized until the final 22.1.0 release.

==== Important Dates ====

  • Jan 16: Begin building LLVM 22.1.0-rc1 in COPR.
  • Jan 27: Begin building LLVM 22.1.0-rc2 in COPR.
  • Feb 3: Fedora f44 branches created
  • Feb 10: Begin building LLVM 22.1.0-rc3 in COPR.
  • Feb 17: Fedora f44 Beta Freeze
  • Feb 24: Begin building LLVM 22.1.0 in Rawhide and 44 side-tags.
  • Feb 24 → Mar 17: Request a Beta Freeze exception for LLVM.
  • Mar 31: Fedora f44 Final Freeze

Feedback :open_book:

Benefit to Fedora :open_book:

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

Scope :open_book:

  • Proposal owners:
    ** Build and test release candidates of LLVM 22 in COPR.
    ** Build and test final release of LLVM 22 in koji.
  • Other developers:
    ** Fix build issues found with LLVM-22 or switch their package to use the llvm21 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-22. There should be around ~10 weeks between when -rc1 lands in COPR and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-22 update.
  • Release engineering: [Making sure you're not a bot! #Releng issue number]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact :open_book:

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? N

How To Test :open_book:

User Experience :open_book:

Dependencies :open_book:

Contingency Plan :open_book:

  • Contingency mechanism: (What to do? Who will do it?) If there are major problems with LLVM 22, the compatibility package provide a way for other packages to continue using LLVM 21.
  • Contingency deadline: Final Freeze
  • Blocks release? No

Documentation :open_book:

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

  • llvm (now includes flang)
  • libclc
  • llvm-test-suite

Release Notes :open_book:

\n

Last edited by @alking 2025-12-16T15:19:45Z

Last edited by @alking 2025-12-16T15:19:45Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

This should actually be a system-wide change, I just forgot to set that initially on the wiki page, but I’ve set it now.

4

When you say “build in COPR”, what does this entail? Just LLVM and subpackages? Are maintainers of deoending packages supposed to test against COPR builds themselves? That couid mean that LLVM 22 does not see much testing before it hits rawhide, and given your policy and the timing, people will just switch to compat to fix FTBFS before F44 release.

5

For this proposal, we are just building LLVM 22 release candiates and its subpackages in COPR. If packaging maintainers want to do early testing with LLVM 22 then they can get it from the COPR project.

We do build packages that BuildRequires: clang in COPR approximately every 3 weeks with the latest builds of LLVM from upstream git, so for those packages we try to either fix or file issues ahead of the LLVM 22 release to reduce the chances of FTBFS.

We do expect that most llvm libraries users will switch to the compat package unless they are also doing a new release that support newer llvm.

1 Like
6

This change proposal has now been submitted to FESCo with ticket #3531 for voting.

To find out more, please visit our Changes Policy documentation.

7

This change has been approved by FESCo and will be included in Fedora Linux 44.
To find out more about how our changes policy works, please visit our docs site.

FESCo Issue: Making sure you're not a bot!

8

For the record for next time… since it’s in the plan, it’d be good to file the FE earlier rather than last minute so the Quality team can plan around it better. (It looks likely that this week, we’d otherwise have an RC, but won’t be “go” if we accept the FE at this point.)

Like, if you have FE proposals for F45, you can do that even now.

9

I don’t think this is the case? As I understand it, accepted Freeze Exceptions do not block the release, only accepted Blockers do.

10

Matthew Miller notifications@fedoraproject.discoursemail.com writes:

For the record for next time… since it’s in the plan, it’d be good to file the FE earlier rather than last minute so the Quality team can plan around it better.

Ack. I had the impression that we had to have the Bodhi update created
in order to request the FE.
I’m going to update our docs on this.

Thanks!

11

Note that llvm 22 is breaking some builds, see devel-list. I guess you’re missing transitive buildrequires in your tests, such as buildrequires on python3-clang.

12

Note that llvm 22 is breaking some builds, see devel-list. I guess you’re missing transitive buildrequires in your tests, such as buildrequires on python3-clang.

I suspect you’re referring to Making sure you're not a bot!

I do not follow you.
How is that build failure related to a missing buildrequires? Could you
elaborate, please?

13

I think what Michael is saying is that

  • mupdf depends on python3-clang

    $ďżźfedrq pkgs mupdf -F requires --src | grep clang ďżźpython3-clang
    python3-clang

  • This is a subpackage of llvm
    $ fedrq pkgs python3-clang -F source
    llvm

  • the issue was not caught in testing which led Michael to wonder if packages BR-ing on python3-clang were not tested

HTH - Michel

1 Like
14

That’s correct, and per mailing list, the answer is they weren’t tested and there’s no compat package for python-clang. While I got some useful technical hints on the ML, they (and what I tried on top) are not enough to fix the build issue. Upstream is building against LLVM 18 (which is what pypi has). So I can’t fix this FTBFS quickly and there’s no time for more. This is why we should not do these invasive changes so late before release, between freezes.

One could claim that I should have known since December, but I read @tstellar ‘s answer as “yes we test” and “yes there will be compat”, which applied to clang but not python-clang (nor recursively), as I know now.