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

BZ#2128443 Firefox 105.0.0 was released
Test Case firefox browse

I bisected this and reported upstream:

(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:


Interesting :-)

I did not know about an epel9 push for zathura but I'm all for it if it works.

zathura and its plugins are interconnected and therefore best built in the same side-tag before merging that in. Is girara etc in epel9?

Note that zathura-pdf-mupdf depends on mupdf. I maintain mupdf, which is why I sometimes commit to adjust zathura-pdf-mupdf, but I'm not the zathura-pdf-mupdf maintainer.

mupdf is not in epel9 either, nor in any epel. It has some other dependencies, of course, and I'm not sure whether all of them are in epel or rhel, or some of the same are "half-baked" (rhel/crb shipping lib without headers where we would have to prod them to do so first).

So, in summary, this looks a bit backward. Is there any plan for this? I'll give down-karma not because of the idea of having zathura in epel9, but for the broken state this update is in.

BZ#2095717 Review Request: sfsexp - Small Fast S-Expression Library
BZ#2095717 Review Request: sfsexp - Small Fast S-Expression Library
BZ#2095717 Review Request: sfsexp - Small Fast S-Expression Library

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:

+%autosetup -p1

+%meson -Dlink-external=true

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? 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.



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

This pulls in new dependencies (flatpak, ostree-libs) which it did have before (see below). Also, it cannot be erased due to the dependency. Why are flatpak and ostree forced upon us?

dnf erase xdg-desktop-portal Error: Problem: The operation would result in removing the following protected packages: gnome-shell

Installing dependencies: flatpak-selinux noarch 1.10.1-1.fc33 updates 23 k flatpak-session-helper x86_64 1.10.1-1.fc33 updates 79 k ostree-libs x86_64 2020.8-1.fc33 updates 427 k Installing weak dependencies: flatpak x86_64 1.10.1-1.fc33 updates 1.7 M p11-kit-server x86_64 0.23.22-2.fc33 updates 199 k xdg-desktop-portal-wlr x86_64 0.1.0-2.fc33 fedora 34 k

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.