This is failing tests because it needs a new rebuild of mesa. The one currently in this update is lower-versioned than the one currently stable in Rawhide, which is mesa-24.2.3-2.fc42 from FEDORA-2024-9f88177f21 .
This update's test gating status has been changed to 'waiting'.
The remaining failure is rpmdeplint stuff. These probably aren't a real issue (it looks like rpmdeplint doesn't properly understand which packages from the update will replace packages in the existing repos):
clang18-18.1.7-5.fc42.x86_64 provides /usr/bin/clang++-18 which is also provided by clang-18.1.8-3.fc41.i686
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/clang_rt.crtbegin.o which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/clang_rt.crtend.o which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/libclang_rt.asan-preinit.a which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.a which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
... [there are lots more similar compiler-rt ones, cut for space]
But these seem to be real conflicts in the update itself and maybe should be addressed, or else libomp and libomp18 won't both be installable together, which it seems like they should be?
libomp-19.1.0-1.fc42.x86_64 provides /usr/lib64/libarcher.so which is also provided by libomp18-18.1.7-3.fc41.x86_64
libomp-19.1.0-1.fc42.x86_64 provides /usr/lib64/libomp.so which is also provided by libomp18-18.1.7-3.fc41.x86_64
libomp-19.1.0-1.fc42.x86_64 provides /usr/lib64/libompd.so which is also provided by libomp18-18.1.7-3.fc41.x86_64
Also, I've got an openQA test branch running on staging right now which enables more tests on updates, and one of them saw an issue with this. In the desktop_keyring test, when logging into localhost with sftp, we get a flood of warnings like '-avx512er' is not a recognized feature for this target (ignoring feature). Google suggests this is a rust thing, so it seems relevant here. We're not seeing these messages in tests of other Rawhide updates, which suggests it's really this update that triggers them. See https://openqa.stg.fedoraproject.org/tests/4252490#step/keyring_passwordless/15
Oh, no, the libomp-19.1.0-1 vs. libomp18-18.1.17-3 thing is actually OK, because libomp18-18.1.17-3 is the old libomp18. The newer libomp18 from this update does not contain those files, so it's fine. That's just the same issue in rpmdeplint - it's not filtering out the old libomp18 .
Hmm, so I wrote a patch for rpmdeplint, but it caused a test to fail, and that test pointed to https://bugzilla.redhat.com/show_bug.cgi?id=1502458 , which made me rethink whether this behavior of rpmdeplint is actually wrong. Arguably, it's not wrong, and instead, we should have better obsoletes/conflicts in the packages. 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 .
The libomp one is a bit tricker, but maybe libomp-19 could conflict with libomp18 < 18.1.7-4 or something.
these relationships should probably stay as conflicts: not obsoletes:, as we don't want clang18 getting automatically installed on update from clang-18.x unless it's actually needed...
I don't think that this is related to Rust. Rust should still be using LLVM 18, and there's really no reason why Rust should be involved in that test at all.
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?
Regarding the conflicts, presumably the ideal here would be to say that compiler-rt18 conflicts with compiler-rt >= 18 < 19, but (as far as I know) we can't actually express that. Conflicting with compiler-rt < 19 is the next best thing we can do. It's not precise, but I don't think that installing compiler-rt18 and compiler-rt 17 together is a scenario we need to worry about (after all, on any distro that has compiler-rt18, the main compiler-rt package would already be on version 19).
@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.
Conflicting with compiler-rt < 19 is the next best thing we can do.
I think adding this conflict is the best solution for now given where we are at in the cycle. We were planning to move to a more python-like main/compat package solution, so maybe we can address this problem then.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This is failing tests because it needs a new rebuild of mesa. The one currently in this update is lower-versioned than the one currently stable in Rawhide, which is mesa-24.2.3-2.fc42 from FEDORA-2024-9f88177f21 .
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
frantisekz edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
The remaining failure is rpmdeplint stuff. These probably aren't a real issue (it looks like rpmdeplint doesn't properly understand which packages from the update will replace packages in the existing repos):
But these seem to be real conflicts in the update itself and maybe should be addressed, or else libomp and libomp18 won't both be installable together, which it seems like they should be?
Also, I've got an openQA test branch running on staging right now which enables more tests on updates, and one of them saw an issue with this. In the desktop_keyring test, when logging into localhost with sftp, we get a flood of warnings like
'-avx512er' is not a recognized feature for this target (ignoring feature). Google suggests this is a rust thing, so it seems relevant here. We're not seeing these messages in tests of other Rawhide updates, which suggests it's really this update that triggers them. See https://openqa.stg.fedoraproject.org/tests/4252490#step/keyring_passwordless/15Oh, no, the libomp-19.1.0-1 vs. libomp18-18.1.17-3 thing is actually OK, because libomp18-18.1.17-3 is the old libomp18. The newer libomp18 from this update does not contain those files, so it's fine. That's just the same issue in rpmdeplint - it's not filtering out the old libomp18 .
Hmm, so I wrote a patch for rpmdeplint, but it caused a test to fail, and that test pointed to https://bugzilla.redhat.com/show_bug.cgi?id=1502458 , which made me rethink whether this behavior of rpmdeplint is actually wrong. Arguably, it's not wrong, and instead, we should have better obsoletes/conflicts in the packages. 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 .
The libomp one is a bit tricker, but maybe libomp-19 could conflict with libomp18 < 18.1.7-4 or something.
these relationships should probably stay as conflicts: not obsoletes:, as we don't want clang18 getting automatically installed on update from clang-18.x unless it's actually needed...
tbaeder edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
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
I don't think that this is related to Rust. Rust should still be using LLVM 18, and there's really no reason why Rust should be involved in that test at all.
Judging by the preceding libEGL warning, I think the culprit here is actually mesa. And I found it passing the avx512er feature to LLVM here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp#L373
So I guess we need to condition that code on LLVM version and a new mesa build.
Ah, looks like there's an issue for it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11870
@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 first paragraph from my previous comment was a quote from a previous message. I failed to see it wouldn't be treated as such.
I've put up a potential fix for mesa here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31321
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
Backport PR for mesa: https://src.fedoraproject.org/rpms/mesa/pull-request/56
Regarding the conflicts, presumably the ideal here would be to say that compiler-rt18 conflicts with compiler-rt >= 18 < 19, but (as far as I know) we can't actually express that. Conflicting with compiler-rt < 19 is the next best thing we can do. It's not precise, but I don't think that installing compiler-rt18 and compiler-rt 17 together is a scenario we need to worry about (after all, on any distro that has compiler-rt18, the main compiler-rt package would already be on version 19).
@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.
Conflicting with compiler-rt < 19 is the next best thing we can do.I think adding this conflict is the best solution for now given where we are at in the cycle. We were planning to move to a more python-like main/compat package solution, so maybe we can address this problem then.
tbaeder edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
tbaeder edited this update.
New build(s):
Removed build(s):
Karma has been reset.
Okay, conflicts added in libomp18, compiler-rt18 and clang18.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This looks good to me now. You can waive the remaining libomp rpmdeplint failure, as it's due to a bug in an old package version.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update has been submitted for stable by bodhi