@adamwill, flang got merged into llvm and is now retired. More details is available at: https://fedoraproject.org/wiki/Changes/LLVM-22#Detailed_Description

pocl-7.1-6 got built separately: FEDORA-2026-830ea7a7d6 This new build does not need to depend on the new packages from this Bodhi update.

@adamwill flang got merged into llvm and is now retired. More details is available at: https://fedoraproject.org/wiki/Changes/LLVM-22#Detailed_Description

jexposit, do you plan to request a freeze exception for this update? This version of spirv-headers is prerequirement for the LLVM 22 update.

It looks like fedora-ci.koji-build.tier0.functional is failing due to an issue on TF: https://status.testing-farm.io/issues/2026-02-17-testing-farm-jobs-on-rawhide-fail-signature-check/ Let's give some time for this issue to be fixed.

This update has been unpushed.

This is not ready for stable yet.

This update has been unpushed.

This update has been unpushed.

The test failures are unrelated to this update. I'm waiving them.

AFAIU, this test is still being worked on. That's why it isn't required yet. Furthermore, this build had only small changes. I think this build was ready to be pushed to stable.

Thanks!

I don't think this Bodhi update is more broken than previous packages. Actually, I reproduced the problem without using this build. IMHO, this update looks OK, but we will definitely need another build with a higher NVR.

I reproduced here with the following commands:

# dnf install lld-19.1.0
# dnf install lld18

This is happening because the lld source package was built with nvr:

Name        : lld
Version     : 18.1.8
Release     : 2.fc41

Meanwhile, this update and previous lld18 builds have lower version 18.1.7.

@nikic, I don't think that's a good idea in the long term because it prevents us from having a compat package is newer than the default package. This type of installation may be important in the scenario where we need to provide a LLVM compat version that is newer than the default LLVM version used in a distro, e.g. a new package/feature requires a newer LLVM version. IMO, we really need to fix the issue in the long term. I do not oppose adding this conflict in the short term, though.

The first paragraph from my previous comment was a quote from a previous message. I failed to see it wouldn't be treated as such.

Specifically, compiler-rt18 should obsolete or conflict with compiler-rt < 19; right now it conflicts with compiler-rt = 18 , which is a bad condition, I don't think it would ever be satisfied (we have never shipped a compiler-rt-18.x86_64.rpm , after all). Similarly, clang18 should obsolete or conflict with clang < 19 .

@adamwill, I'm not sure this proposal is correct. You can see here that we distributed compiler-rt-18 and compiler-rt-17. Also important: compiler-rt18 (compat package) does not conflict with compiler-rt-17 (non-compat package). The same thing applies to clang.

If you still believe the conflict statement should be modified, could you elaborate why, please?

The rust issue was reported upstream as https://github.com/rust-lang/rust/issues/125492 Fixed with https://github.com/rust-lang/rust/pull/125498