Sorry for the back and forth. Pushed "push to stable" t0o soon and tried to revert by "unpush", which unpushed from testing instead, forcing me to to repush to testing.

Background: F41 update is held back waiting for feedback regarding an soname bump update (as in rawhide) which would include the fix.

This update has been unpushed.

Thanks, solves the problem with missing "SPV_KHR_non_semantic_info" (Intel Xe, tested with darktable).

If someone could give positive karma on https://bodhi.fedoraproject.org/updates/FEDORA-2024-3a15d9bc6a before the freeze then the FTI which is caused by this updated here is solved by that update :-)

.. a few moments later ... It turns out that py3status has an exact version requirement in pyproject.toml which the pyproject macros pick up.. Duh.

So this was pushed to stable 5 days ago, missing a dependency (py3status). Consequently, I got an FTI bug: https://bugzilla.redhat.com/show_bug.cgi?id=2271293

3 days ago I rebuilt py3status: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d9cffaf474 But this picked up 3.46!? Consequently, I got another FTI bug: https://bugzilla.redhat.com/show_bug.cgi?id=2271807

What is going on here? Why do rebuilds pick up pygobject 3.46 at a time when FTIs were filed already because of pyggobject is not available (after this update to 3.48)?

py3status+dbus will FTI with this as it did on rawhide. (https://bugzilla.redhat.com/show_bug.cgi?id=2271293)

I took care of the rawhide rebuild and pushed the rebuild commit to py3status/f40 as well. Should I build it into this side-tag target, or how do we edit the bodhi update?

I've rebuilt mupdf into the side-tag successfully.

You compile qpdfview with 5 plugins and put all of them in the same package. Unless there is a preference that I overlooked, qpdfview provides no way to select a specific plugin. As a consequence, the last plugin ("pdf" alias poppler) which registers for the pdf file type wins over earlier ones such as "fitz" (aka mupdf).

So, in order to test the latter, you need to use a file type that no other plugin registers for.

But really I think the packaging should be different and offer plugins as subpackages, with a default for the typical user, and others you can swap in.

By disabling libqpdfview_pdf.so you can test the fitz/mupdf plugin against PDFs. But all this probably does not matter as long as fitz/mupdf is practically turned off due to the packaging.

When I suggested this update (adjust to mupdf shared) I wrote "rawhide and F40" for a reason: The reason is that these are the only branches with "mupdf shared". In particular, there was no FTBFS on F39.

Have you tested that this F39 update works as expected (with the removed switches)?

I don't mind pushing "mupdf shared" to F39 - I hadn't done so because other dependent packages didn't want to at the time. I can make that decision myself now, but we need to coordinate this in a side-tag. So I suggest not to push this qpdfview update to stable unless you confirmed that every plugin works. We can then bump and build in a side-tag for F39 (with mupdf shared, PyMuPDF, zathura-pdf-mupdf).

Makes zathura-djvu work again - fantastic turn around time :)

So, this uodate fixes the FTI but some tests are failing. I guess we should have a way to run them before the update ...

This version has a bug/change that affects gpg use within emacs, at least in unattented mode such as test suites:

https://dev.gnupg.org/T6481

So this should rather not go to F38 before the upstream fix is committed and picked. (notmuch test suite fails on rawhide these days, presumably due to this.)

The update itself is OK. But:

package obs-studio-libs-29.1.0-2.fc38.x86_64 requires qt6-qtbase(x86-64) = 6.4.3, but
 none of the providers can be installed
  - cannot install both qt6-qtbase-6.5.0-2.fc38.x86_64 and qt6-qtbase-6.4.3-2.fc38.x86_64

etc I.e. the push apparantly missed the current qt6-qtbase bump. It might be better to replace this build with a rebuilt.

The correct bug number is #2187614 , sorry about that.