Note that GraphicsMagick (and users) suffers from a similar problem like xmlsec did: bz#2138022

I bisected this and reported upstream:

https://bugs.ghostscript.com/show_bug.cgi?id=703013

(It's the fix to that bug which introduced the problem.)

@remyabel , but it fails also locally when I run a single test, reliably, and only for those 3 devices. Since x11cmyk2 is a test device I would wave the test result if I was sure that x11gray aren't used somewhere.

The devices x11cmyk2 x11gray2 x11gray4 reproducibly give a segfault for the automated test. Has any of the commenters tested successfully with any of these devices?

Thanks for confirming that it works. So, there are no technical issues.

There are a few policy/guidelines issues, though:

• mupdf is not in RHEL nor EPEL. mupdf has bugs from time to time but no bugfix releases, only feature+bugfix releases. This does not match well with RHEL/EPEL packaging guidelines. Backporting bugfixes is a lot of work. So I'm not sure whether I even should push mupdf to EPEL 9.

• mupdf needs curl-devel and jbig2dec-devel. They are in Fedora, but we cannot put them into EPEL because RHEL carries curl and jbig2dec (libraries without headers). We can ask RH (and I have filed a bug about jbig2dec) to put the devel packages into "code ready builders" for RHEL.

• zathura-pdf-mupdf is not "my" package. While I could adopt the EPEL branch I'd rather coordinate with the maintainer (and with mupdf, which I maintain).

• I don't know about zathura packager's plans with this. Plugins should coordinate with that. It's possible to have some plugins in EPEL and some in COPR for EPEL, of course.

The two pdf plugin packages do not conflict each other, btw. I don't know how zathura chooses between them. "plugins-all" is a meta-package which requires all plugins except pdf-mupdf (because it prefers pdf-poppler).

Indeed, as expected, two packages in rhel/cb need to ship devel subpackages first. Once this is done we can have everything in place. Feel free to try your zathura with this plugin:

https://copr.fedorainfracloud.org/coprs/mjg/mupdf-zathura-EPEL/

Well, we did work around that, but the PR got mismerged. The relevant part of the diff between origin/rawhide and mjg/rawhide (plus the the explicit -p1) is:

 %prep
-%autosetup
+%autosetup -p1

 %build
-%meson
+%meson -Dlink-external=true
 %meson_build

OK, I see you have some cmake target files in -devel and some in -static. I'm no cmake guy, but... -devel should be enough to develop against SDL2, i.e. against all targets, should't it?

We see builds of darktable failing with this now. SDL2 2.0.18-3 seems to contain db732fc Add missing SDL2Targets files to devel subpackage (even though it's not mentioned in clog). Is that maybe not complete? Do we have to buildrequire more than cmake(SDL2) now?

https://koji.fedoraproject.org/koji/taskinfo?taskID=80865753 gives CMake Error at /usr/lib64/cmake/SDL2/SDL2Config.cmake:42 (get_target_property): get_target_property() called with non-existent target "SDL2::SDL2main".

The same darktable spec used to work last week.

obsoleted by FEDORA-2021-a6934c273c

Wfm

Having kernel{,-core,-devel,-modules,-modules-extra} at .4 but kernel-{headers,tools,tools-libs} at .3 looks a bit unsusal and might even throw off some third party modules or tools.

So, technically this is a regression reintroducing bug #1851668

it did not have, obviously

The real issue is that ghostscript does not require the exact version of jbig2dec that it depends on. So, ghostscript needs a rebuild and an update for the requires.