CC'ing Michael (mupdf maintainer) just so they are aware of this ticket.

Hi Ankur, and all the best to you for the new year.

I proposed to help a bit with this project, and previous maintainer "promoted" me "main admin", which was not my original request, but ... never mind :)

zathura is not a single leaf, it needs girara as the base lib., and plugins (pdf, ps, cb, djvu). That means 6 (+ 1 if pdf-mupdf is included) packages to update "in the correct order".
=> side tag, I guess... I've never done that before, but it seems easy ?

I never took the time for such a multiple upgrade... I guess this is what you request now, right ?

Do you want admin rights on the packages ?

If not, I can start with F37, but can not guarantee it will be done tomorrow ;)

I am not an heavy user of zathura, and as such I was not able to distinguish what the 0.5.2 version brings that we urgently need it i.s.o 0.4.9.
Both read and present my PDF the same way.
Rawhide is up to date.
Regards

Hi there, and best wishes to all.

My offer from bz #2125415 (creating side tags) is still valid, as is the analysis regarding interdependencies of features and versions.

Ankur is a proven packager, this implies global commit rights, that is: Ankur could do all the commits and builds if Alain agrees. (Even if not, but Ankur is one of the "good ones" :) .)

NB: Some zathura plugins continue to work without a rebuild against an updated zathura, but I would rather not bet on it and do them in order together.

First question would be whether Alain wants to update girara on F37/F36, which is technically not required for the zathura update, but which would need to be the first one to build into the side-tag, along with mupdf.

Second "batch" zathura (or first one together with mupdf, if girara stays put).

Last batch zathura plugins and Python-PyMuPDF (they do not depend on each other, but on the above).

Cheers
Michael

Hi Alain,

Thanks for your quick reply.

Sure, I'll be happy to co-maintain the package, so please add me to it. I already help co-maintain the plugins, so it'll be useful to also have access to zathura to update it all together when required. Would you be able to please add me to girara too since zathura and girara updates tend to be strongly linked?

If you can add me to the package, I can work with Michael to sort out the updates in side tags and all that (and document it here for you as future reference too, while I'm at it). As Michael notes, I'm a proven packager so I do have access to all packages, but we try not to use our proven packager access without the permission of individual maintainers. Since I do use zathura a lot, I'd rather help co-maintain its stack than use proven packager access :)

The primary feature in 0.5.2 seems to be "improved text selection"---I'd like to try that. I have ~4 zathura instances open on any day, so every new feature is quite exciting :)

https://pwmt.org/projects/zathura/changelog/0.5.2/index.html


Thanks again,

(In reply to Ankur Sinha (FranciscoD) from comment #4)
> Hi Alain,
> 
> Thanks for your quick reply.
> 
> Sure, I'll be happy to co-maintain the package, so please add me to it. I
> already help co-maintain the plugins, so it'll be useful to also have access
> to zathura to update it all together when required. Would you be able to
> please add me to girara too since zathura and girara updates tend to be
> strongly linked?
Of course !
I added you, and Michael as admin for girara and zathura. That means, the fastest of us could update the rpms in the way he likes :)
Concerning the plugins, you, Ankur, are the main admin, and I don't have rights to change plugins projects settings (which is fine by me).
> 
> If you can add me to the package, I can work with Michael to sort out the
done
> updates in side tags and all that (and document it here for you as future
> reference too, while I'm at it). As Michael notes, I'm a proven packager so
> I do have access to all packages, but we try not to use our proven packager
> access without the permission of individual maintainers. Since I do use
> zathura a lot, I'd rather help co-maintain its stack than use proven
> packager access :)
Yes, if you can share without too much of your time, how you did proceed, that would beneficial (at least to me).
> 
> The primary feature in 0.5.2 seems to be "improved text selection"---I'd
> like to try that. I have ~4 zathura instances open on any day, so every new
> feature is quite exciting :)
> 
> https://pwmt.org/projects/zathura/changelog/0.5.2/index.html
> 
> 
> Thanks again,

I also wish to share my concerns about the 2 PDF plugins (poppler or mupdf): Does it make a difference for the end user ?
The 2 plugins can be installed at the same time ?
If yes, zathura is selecting which one when opening a PDF file ?

Regards
Alain

Hi Alain,

thanks for your trust in us :)

You can install both pdf plugins without conflict. zathura parses available plugins and registers filetypes. Since mupdf sorts before poppler, you get the following debug output:
```
error: plugin: filetype already registered: application/pdf
error: Could not register plugin '/usr/lib64/zathura/libpdf-poppler.so'
```
I.e. the first one registering for a filetype (mime type) wins.

I don't know how to select a plugin (other than installing only one).

The two engines (mupdf, poppler) are quite different. Often, one has a problem with a specific pdf construct and the other has not. For common use cases they should be equivalent. mupdf is said to be fast. I vaguely remember that their font loading mechanism is different, which can result in different font substitutions if a font is not embedded. mupdf is by Artifex, the makers of ghostscript. poppler is used as the pdf backend by cairo.

I guess zathura does not necessarily expose all features of the engines (such as digital signatures).

You basically say, only one is "needed" and working, and the choice between the 2 plugins is really an end user (unconscious ?) choice.

I stick to the comment in zathura spec files (which was here before my "era") :

# poppler is preferred over mupdf
Suggests:          zathura-pdf-poppler

and I will not address zathura-pdf-mupdf stuff.


You may also find in zathura-pdf-poppler.spec :
Conflicts:        zathura-pdf-mupdf < 0.3.3

which does not prevent to install the 2 plugins, nowadays :)

(In reply to Alain V. from comment #7)
> You basically say, only one is "needed" and working, and the choice between

Yes, in the sense that zathura cannot display any file type without plugins and uses exactly one plugin per filetype.

> the 2 plugins is really an end user (unconscious ?) choice.

Conscious in the sense that the user decides which to install. Unconscious if the user simply installs all of them (and ends up using mupdf), or the "all" meta-package (and ends up using poppler).

> 
> I stick to the comment in zathura spec files (which was here before my
> "era") :
> 
> # poppler is preferred over mupdf
> Suggests:          zathura-pdf-poppler

"Preferred" probably because of the quality/readiness back then.

Technically, there is no preferences, I checked zathura's sources: zathura scan all available plugins, and the first one registering a filetype wins. So, if you have only one plugin dir, this isprobably by sort order.

> and I will not address zathura-pdf-mupdf stuff.
> 
> 
> You may also find in zathura-pdf-poppler.spec :
> Conflicts:        zathura-pdf-mupdf < 0.3.3
> 
> which does not prevent to install the 2 plugins, nowadays :)

Maybe zathura errored out on multiple pdf plugins back then? I don't know.

If you think it helps the user experience we could have -pdf-mupdf and -pdf-poppler conflict each other. This will interact with -plugins-all, though. But maybe there is no problem:

"Novice" users will install -plugins-all and get a working pdf plugin (poppler).
Users looking for mupdf will install zathura-pdf-mupdf, maybe on top of -all-, and this will activate that plugin (for alphabetical reasons ...).
If they want to switch back to poppler, the natural thing is uninstalling zathura-pdf-mupdf; this will "activate" zathura-pdf-poppler (if it is still installed).

So, while the mechanism may be questionable, the user experience sounds OK.

We could certainly make the two conflict, and folks can switch using `dnf swap` and all that---or we could leave things as they are and allow users to install both with mupdf being loaded first. (I'd expect Zathura users to be fairly technically advanced enough to be able to pick what plugins they want to use).

Michael: should I create side tags for F36 and F37 to get us started here?

Thanks for all your help folks :)

(In reply to Ankur Sinha (FranciscoD) from comment #9)
> We could certainly make the two conflict, and folks can switch using `dnf
> swap` and all that---or we could leave things as they are and allow users to
> install both with mupdf being loaded first. (I'd expect Zathura users to be
> fairly technically advanced enough to be able to pick what plugins they want
> to use).
> 
> Michael: should I create side tags for F36 and F37 to get us started here?

Yes please.

I remember vaguely that I needed commit rights, definitely for building into the tag, but maybe also for submitting the update from the tag. So it's better you do this. I'll build mupdf and python-PyMuPDF into the tags then. Just let me know if you want to do zathura-pdf-mupdf (once mupdf is built), or I'l follow up with that.

> Thanks for all your help folks :)

Same :)

Sure, here are the side tags:

$ fedpkg --release f37 request-side-tag
Side tag 'f37-build-side-61729' (id 61729) created.
Use 'fedpkg build --target=f37-build-side-61729' to use it.
Use 'koji wait-repo f37-build-side-61729' to wait for the build repo to be generated.

$ fedpkg --release f36 request-side-tag
Side tag 'f36-build-side-61731' (id 61731) created.
Use 'fedpkg build --target=f36-build-side-61731' to use it.
Use 'koji wait-repo f36-build-side-61731' to wait for the build repo to be generated.

To check if a build has been tagged in a side tag (documented here: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#creating_a_side_tag):
koji wait-repo --build package-build-nvr  <side tag>

The order, to confirm:

1. girara
2. zathura
3. zathura plugins (except pdf-mupdf)
4. mupdf
5. python-PyMuPDF
6. zathura-pdf-mupdf

Should I update girara and kick off builds now to get us going?

Cheers,

I do agree with the order, even if I think girara and mupdf have nothing in common, and could be built "at the same time" ?
I think for F37, the rawhide spec files should be OK.
I don't now if they build without a problem when F36.

For me to understand:
1. girara : You build it with this fedpkg command, in a Shell, then issue the "koji wait" command : Your shell is then "blocked" till you can go to step 2 ? 
How long does it take ? Can I close the shell ? 
If I close the shell, how do I know if I am good to go, by issuing same "koji wait" command ?

Then I have to "koji wait" for all the subsequent steps ?
2. ...


Further down the road, I understand bohdi will "pack" the different builds into a single update. How Do I test the result then ? Installing "the side tag" ? All the packages altogether ?
I never dare to do such things ;) Thank you for your help...

To confirm: mupdf is independent of everything else here and can go into the side-tag at the "same time" (i.e. initially) as girara. I'll do that now so that the plugin can follow once zathura is built.

Thanks Michael. I see mupdf and PyMuPDF built already. I've queued up girara and zathura builds and will queue up the plugins when these are done.

Avign: yeh, for builds that depend on one another one sort of does need to wait for a build to finish before kicking off a new one. The releng folks probably have scripts to help with this which they use for the mass-rebuilds.

For the time being, I'm using this:

# in the directory where I have all my Fedora repos
for pkg in girara zathura ; do pushd "$pkg" && git checkout rawhide && git pull && git checkout f37 && git merge rawhide && git push && fedpkg build  --target=f37-build-side-61729 && popd ; done

One could use `fedpkg build --nowait ...` but then it would require using `koji wait-repo --build ...`. There's no getting around waiting as far as I know.

I used byobu/tmux, so I just open another "window" there and run the same for F36 too.

One can follow the progress of the side tags over koji here:

https://koji.fedoraproject.org/koji/builds?tagID=61729  (F37)

and here

https://koji.fedoraproject.org/koji/builds?tagID=61731   (F36)

Cheers,

I forgot to add---to test the packages, we usually build them on COPR first, install them, and test them etc. One can use `fedpkg copr-build ...` instead of `fedpkg build` to test them out over COPR.

I think we've completed F37. Michael, you had already built:

- mupdf
- python-PyMuPDF

and, I've built:

- girara
- zathura
- zathura-ps
- zathura-djvu
- zathura-pdf-poppler
- zathura-pdf-mupdf
- zathura-cb

If we've not forgotten any packages, I can push these as a new update in Bodhi.

For F36, girara and zathura are built. Queuing up the plugins now.

Cheers,

F36 builds also completed in the side tag now. I'll let you folks have a look before pushing updates. Hopefully, I haven't messed anything up :D

Thanks again,

Testing on my F37, I'm seeing these messages on starting up zathura:

error: Could not find 'zathura_plugin_4_5' in plugin /usr/lib64/zathura/libcb.so - is not a plugin or needs to be rebuilt.
error: Could not find 'zathura_plugin_4_5' in plugin /usr/lib64/zathura/libps.so - is not a plugin or needs to be rebuilt.
error: Could not find 'zathura_plugin_4_5' in plugin /usr/lib64/zathura/libdjvu.so - is not a plugin or needs to be rebuilt.


I think I need to rebuild these, looks like they pulled on the older zathura version. Bumping and rebuilding now. I'll go double-check all F36 builds also.

FEDORA-2023-89af703e2f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-89af703e2f

FEDORA-2023-ddf0b6a3cf has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ddf0b6a3cf

FEDORA-2023-ddf0b6a3cf has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ddf0b6a3cf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ddf0b6a3cf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-89af703e2f has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-89af703e2f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-89af703e2f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-89af703e2f has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-ddf0b6a3cf has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.