Dependencies of other packages that would be BROKEN by the tested packages:
package: audacious-plugins-exotic-4.6.1-7.eln159.x86_64 from https://kojipkgs.fedoraproject.org/compose/eln/latest-Fedora-eln/compose//Extras/x86_64/os
  libsidplayfp.so.6()(64bit)

New dependency problems in the tested packages themselves:
package: kiwi-cli-11.0.2-1.eln159.noarch from Extras
  (kiwi-selinux = 11.0.2-1.eln159 if selinux-policy)

Warning: pre-existing dependency problems in the tested packages themselves:
package: wordpress-7.1.1-1.eln159.noarch from /var/tmp/rdccomposerepogor49669/Extras
  php-sodium

Unfortunately still sorts lower than the bad version :(

I think you may have to stick with the non-compliant versioning for now and just remember to bump the number after the + for each new snapshot, so sorting doesn't depend on the git commit. And then drop the non-compliant versioning with 5.88 and don't use it again.

Or we could designate the snapshots as "5.88 pre-release" instead of "5.87 post-release", and version as 5.88~20260918gitb5ed56d8c-3.fc46 (or -1.fc46 I guess). I think that would work:

[adamw@toolbx fedora-toolbox-44 initial-setup (master)]$ rpmdev-vercmp 0 5.87+1.git789f6e154 2.fc46 0 5.88~20260918gitb5ed56d8c 1.fc46
0:5.87+1.git789f6e154-2.fc46 < 0:5.88~20260918gitb5ed56d8c-1.fc46

The llvm update for F45 has not gone stable. It failed testing for similar reasons (it was submitted too soon after the llvm22 compatibility package update went stable). I am re-running tests on it now. Once it passes tests, is pushed stable, and is included in a compose, we can re-test this update and it should pass.

It would have been better to include this mesa build in the llvm update, or wait until the llvm update was pushed stable and reached a compose before submitting this.

I think this failed tests because it was submitted very soon after FEDORA-2026-06a5023802 went stable; we don't use the buildroot repo for post-UT-activation Branched, so we need llvm22 to be in a compose before this will pass. It looks like it was in Fedora-45-20260917.n.0 , which happened after the tests ran, so I'll re-run them and see.

Seems this missed several dependencies, @smani :

Dependencies of other packages that would be BROKEN by the tested packages:
package: mingw32-gdal-3.13.3-1.fc46.noarch from https://kojipkgs.fedoraproject.org/repos/f46-build/latest/x86_64
  mingw32(libxml2-2.dll)
package: mingw32-python3-lxml-6.1.1-2.fc45.noarch from https://kojipkgs.fedoraproject.org/repos/f46-build/latest/x86_64
  mingw32(libxml2-2.dll)
package: mingw64-gdal-3.13.3-1.fc46.noarch from https://kojipkgs.fedoraproject.org/repos/f46-build/latest/x86_64
  mingw64(libxml2-2.dll)
package: mingw64-python3-lxml-6.1.1-2.fc45.noarch from https://kojipkgs.fedoraproject.org/repos/f46-build/latest/x86_64
  mingw64(libxml2-2.dll)

Filed https://forge.fedoraproject.org/packaging/guidelines/issues/1569 .

This failed tests because you versioned it wrong.

This update is versioned bluez-5.87+1.git789f6e154-2.fc46 . The previous build was versioned bluez-5.87+1.git8750129efca8-1.fc46 .

Those NVRs are identical up until the "git..." bit, and "git8750129efca8" is higher than "git789f6e154". So the old build is higher-versioned than this build.

I don't know where you got this versioning approach from but it is absolutely not what is written in the packaging guidelines. Please fix the versioning. In theory it should probably be:

bluez-5.87^20260916git789f6e154

but that won't work since you've messed it up:

[adamw@toolbx fedora-toolbox-44 45]$ rpmdev-vercmp 0 5.87+1.git789f6e154 2.fc46 0 5.87^20260916git789f6e154 1.fc46
0:5.87+1.git789f6e154-2.fc46 > 0:5.87^20260916git789f6e154-1.fc46

i.e. the correct versioning sorts lower than the current, incorrect versioning.

It was also inappropriate and incorrect to waive the test failures with the flippant message "whatevah". Gating test failures are not a joke, and yes, they apply to you.

You're both long experienced packagers, you should know better than this. @hadess @pbrobinson

rmdepcheck output suggests several dependencies were missed: coccinelle, lem-devel, nbdkit-ocaml-plugin-devel, ocaml-domain-name-devel, ocaml-ocamlnet, ocaml-plplot-devel, ocaml-pyml, ocaml-stdcompat-devel, ocaml-xmlrpc-light. It also suggests the ocaml-benchmark in the update is not installable (may have been built against the wrong ocaml?)

Ah, it looks like the package gating policy got updated, but that happened long after this build of llvm was done. Bodhi seems to pick up changes to the gating policy only after new builds happen.

So the remaining gating issues here are two absent tests for the 'llvm' package: fedora-ci.koji-build.rpmdeplint.functional and fedora-ci.koji-build./tests/kernel-ark-build.functional .

I can explain the first: rpmdeplint is configured to only run on Rawhide, so no package's gating.yaml should ever require it for any branch other than Rawhide. This is actually painful to express because we use 'fedora-NN' for Rawhide results not 'fedora-rawhide', so practically speaking, you probably just shouldn't gate on that test. We do have rmdepcheck now which is probably a better thing to gate on; it passed for this update.

fedora-ci.koji-build./tests/kernel-ark-build.functional is the same - it's a package-specific test but you can see there that it's configured to only run on Rawhide (line 21). So, the gating config should not require this test for non-Rawhide.

I guess I'll send a PR for the gating policy. For this update we can waive the absences.

That's being tracked as https://bugs.kde.org/show_bug.cgi?id=525748 .

sure I guess it's fine

See if this unsticks it...

This update has been unpushed.

Tests pass now the nss update is in stable.