Zathura needs plugins to do anything, and there only seems to be the package zathura-plugins-all available. This is broken, all the plugins are missing:
sudo dnf install zathura-plugins-all
Last metadata expiration check: 0:48:08 ago on Tue 23 Aug 2022 10:05:48 BST.
Error:
Problem: conflicting requests
- nothing provides zathura-cb needed by zathura-plugins-all-0.4.9-1.el9.x86_64
- nothing provides zathura-pdf-poppler needed by zathura-plugins-all-0.4.9-1.el9.x86_64
- nothing provides zathura-ps needed by zathura-plugins-all-0.4.9-1.el9.x86_64
- nothing provides zathura-djvu needed by zathura-plugins-all-0.4.9-1.el9.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
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.
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:
@mjq I downloaded zathura-pdf-mupdf-0.3.9-1.el9.x86_64.rpm from your link and it works perfectly! If you could push that into EPEL9 then we will have a fully working Zathura for PDF, XPS, OpenXPS, CBZ, EPUB, and FictionBook 2 :)
I don't know why the plugins in the broken bundle favor zathura-pdf-poppler over zathura-pdf-mupdf? zathura-pdf-mupdf seems vastly superior, and I assume they would conflict if both installed?
THANKS for the build! Is it missing anything? It seems perfect, I hope it can make it out into the wild soon :)
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).
It all started with me being a new maintainer of girara where I was asked to port it to EPEL9.
Then came zathura, I ported to EPEL9, but I did not realize the plug-ins were separate packages (OK, I did not search a lot :). I volunteer to co-maintain the plug-ins too (I plan to have them updated where needed).
The idea is the following: as long as the .spec file is the same for Fedora and EPEL, why not having an EPEL branch.
But I have a Fedora env. and don't have an EPEL one (or could I ?). So I am not able to test what I build for EPEL :(
This update has been submitted for testing by avigne.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
This update has been submitted for stable by bodhi.
FEDORA-EPEL-2022-d28c890a7c ejected from the push because "Cannot find relevant tag for zathura-0.4.9-1.el9. None of ['epel9', 'epel9-pending'] are in ['epel9-next-testing', 'epel7-testing', 'dist-5E-epel-testing', 'f27-modular-updates-testing', 'eln-updates-testing', 'f30-modular-updates-testing', 'f28-modular-updates-testing', 'f28-container-updates-testing', 'f30-container-updates-testing', 'epel8-testing', 'f30-flatpak-updates-testing', 'f36-updates-testing', 'f32-modular-updates-testing', 'f29-modular-updates-testing', 'f29-container-updates-testing', 'f29-flatpak-updates-testing', 'f22-updates-testing', 'f21-updates-testing', 'f25-updates-testing', 'f24-updates-testing', 'f23-updates-testing', 'f26-updates-testing', 'f31-modular-updates-testing', 'dist-6E-epel-testing', 'f32-flatpak-updates-testing', 'f36-container-updates-testing', 'f27-updates-testing', 'f28-updates-testing', 'f30-updates-testing', 'f29-updates-testing', 'epel8-modular-updates-testing', 'f32-updates-testing', 'epel9-testing', 'f37-container-updates-testing', 'f34-updates-testing', 'f31-updates-testing', 'f31-container-updates-testing', 'f31-flatpak-updates-testing', 'f34-modular-updates-testing', 'f32-container-updates-testing', 'epel8-next-testing', 'f35-updates-testing', 'f35-modular-updates-testing', 'f33-updates-testing', 'f34-container-updates-testing', 'f33-modular-updates-testing', 'f33-container-updates-testing', 'f33-flatpak-updates-testing', 'f35-container-updates-testing', 'f36-modular-updates-testing', 'f35-flatpak-updates-testing', 'f36-flatpak-updates-testing', 'f34-flatpak-updates-testing', 'f38-container-updates-testing', 'f37-flatpak-updates-testing', 'f37-updates-testing', 'f38-updates-testing']."
This update has been submitted for stable by bodhi.
This update has been pushed to stable.
Zathura needs plugins to do anything, and there only seems to be the package
zathura-plugins-allavailable. This is broken, all the plugins are missing:Also, the https://pwmt.org/projects/zathura-pdf-mupdf/ plugin is missing, this is superior to
zathura-pdf-poppleras it also enables reading ebooks.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.
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/
@mjq I downloaded
zathura-pdf-mupdf-0.3.9-1.el9.x86_64.rpmfrom your link and it works perfectly! If you could push that into EPEL9 then we will have a fully working Zathura for PDF, XPS, OpenXPS, CBZ, EPUB, and FictionBook 2 :)I don't know why the plugins in the broken bundle favor
zathura-pdf-poppleroverzathura-pdf-mupdf?zathura-pdf-mupdfseems vastly superior, and I assume they would conflict if both installed?THANKS for the build! Is it missing anything? It seems perfect, I hope it can make it out into the wild soon :)
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).
It all started with me being a new maintainer of girara where I was asked to port it to EPEL9. Then came zathura, I ported to EPEL9, but I did not realize the plug-ins were separate packages (OK, I did not search a lot :). I volunteer to co-maintain the plug-ins too (I plan to have them updated where needed).
The idea is the following: as long as the .spec file is the same for Fedora and EPEL, why not having an EPEL branch. But I have a Fedora env. and don't have an EPEL one (or could I ?). So I am not able to test what I build for EPEL :(
Keep my in touch...