This fails tests because the new fmt is not included in Workstation or KDE live images, Silverblue ostree images, or the container base image; some dependency issue makes dnf prefer the old fmt. It may take some detective work to figure out why. It's possible this isn't a 'real' issue and the images would build OK (possibly with both the new fmt and the compat package) if the older fmt from rawhide was not available; it's unfortunately hard to have the openQA tests run in an environment that mimics the post-landing situation. I'll try and look into it manually somehow later.

Thanks for the analysis. Note that this is likely to make the mass rebuild very messy if not resolved.

oh, hmm. I have an idea. it probably prefers the old fmt as the provider of libfmt.so.10()(64bit) because it's got a higher NVR than the new fmt10 package. I bet if we added an fmt10-10.2.1-5.fc41 to this update, it might work. I'm going to test that using a scratch build, give me an hour or two.

@adamwill We need to push this update to Rawhide today before the mass rebuild starts.

okay, doing a higher versioned fmt10 build seems to have done the trick, this is stable now.

Thank you!

Thank you all for the help!