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

Annocheck reported the same issue that should be skipped. We need to add support for skipping files to annocheck. I'm working on it. Meanwhile, I'm waiving the test results.

I'm discussing with annobin's maintainer this behavior from annocheck. He explained to me that annocheck doesn't support the usage of files in --skip-lto, but he does agree this would be useful. I'm planning to contribute this feature.

I run the tests manually and I identified more files that need to be ignored. I have a solution for this.

So, I'm going to waive the test results again.

I'm discussing with annobin's maintainer this behavior from annocheck. He explained to me that annocheck doesn't support the usage of files in --skip-lto, but he does agree this would be useful. I'm planning to contribute this feature.

I run the tests manually and I identified more files that need to be ignored. I have a solution for this.

So, I'm going to waive the test results again.

The rpminspect configuration requires to specify the relative path of the files to be skipped in a test. I'm proposing a fix in https://src.fedoraproject.org/rpms/zlib-ng/pull-request/22

The issue with dnf debuginfo-install has been reported upstream in https://github.com/teemtee/tmt/issues/2988 It seems it hasn't reached downstream yet.

Meanwhile the rpminspect / annocheck issue was reported at https://github.com/fedora-ci/rpminspect-runner/issues/125

Tests timed out. I'm re-triggering them.

FTR: I believe I found the root cause and reported it at https://github.com/fedora-ci/rpminspect-runner/issues/125

FTR: I believe I found the root cause and reported it at https://github.com/fedora-ci/rpminspect-runner/issues/125

annocheck's lto tests should be skipped, but the arguments we set are not being respected and that's causing the failure. I'm going to waive this test result.

I run the annocheck test by hand and I can't reproduce this failure:

Running annocheck inspection...      pass

I'm re-triggering the tests. It looks like annocheck ignored its parameters.

I reported the issue with dnf debuginfo-install in https://github.com/teemtee/tmt/issues/2988

This update has been unpushed.

I confirmed that -z relro -z now is being used. I wonder if this test had a false positive...

We're getting a weird error here:

Package Vendor changed from "Fedora Project" to "unknown" in zlib-ng

I don't think we can progress with this error.