search

mjg / mupdf-spec

mupdf packaging for Fedora
https://copr.fedorainfracloud.org/coprs/mjg/mupdf-git
0 stars 0 forks source link

new version released #14

Closed ousia closed 1 year ago

ousia commented 2 years ago

@mjg,

version 1.19 has been released (https://mupdf.com/release_history.html).

Many thanks for your help.

mjg commented 2 years ago

Yes, the built went fine already. I need to coordinate the push with other packagers, and I'll see whether I make a copr round trip before - forgot about my reliable copr user, sorry ;)

mjg commented 2 years ago

copr done, including zathura-pdf-mupdf :)

mjg commented 2 years ago

Additional info:

ousia commented 2 years ago

MuPDF-1.19 seems to include Python (and C) bindings.

Is it possible to include them in the build?

mjg commented 2 years ago

MuPDF-1.19 seems to include Python (and C) bindings.

Is it possible to include them in the build?

You mean the Python and C++ bindings which were introduced as experimental in MuPDF-1.18.0? I'm still wondering where there is any documentation on building these... Unless you count the source of setup.py, as far as python is concerned. Artifex decided to use pipcl and seems to focus on building wheels for pip.

On the other hand we always had python-PyMuPDF packaged in Fedora (and available elsewhere). I have no idea why Artifex introduced their own bindings and how they compare (where is the doc?). Again, the usual mindset.

In any case, I think that first we should solve the library problem in Fedora, i.e. package the library as a properly versioned shared library (.so). Any hints or PRs on that are welcome.

Artifex' bindings use the .so, but I have no clue how that ends up "in" the wheel or is used otherwise.

mjg commented 2 years ago

OK, so I managed to build some bindings, but only by fixing manually a lot of the things which Artifex did "in a special way" when they use python-clang. They hardcode expectations which are met only on some systems, it seems.

Turned out that the build script for the python bindings generates the c++ binding - not only as a prerequisite of swig, but in general. And there seems to be no install target and the lang docs goes all over the place. Oh well.

So, I can happily report that I got the bindings to work locally (python test scripts work) but proper packaging will take more time:

In summary, I should push mupdf 1.19.0 without any extra changes first (once PyMuPDF has caught up, which is about now) so that any potential hick-ups can be isolated to the 18/19 switch and OCR introduction. Then we have a good base (and maybe parallel progress) for the lib change and then for the bindings. Sounds like a plan?

ousia commented 2 years ago

Version 1.20.0-rc1 has been released (https://git.ghostscript.com/?p=mupdf.git;a=commit;h=fc80410aa8a1d89fd546053a7da45c7961423a43 and https://mupdf.com/releases/index.html).

Many thanks for your packaging work.

mjg commented 2 years ago

So, situation regarding the bindings etc is unchanged. But I've built mupdf 1.20.0-rc1 in the linked copr. Let me know how things go!

mjg commented 1 year ago

Forgot to close since 1.21 is built. New bindings still on the radar. Also upcoming: Repo rename and more frequent fedora builds off upstream's master (and, possibly release) branches. We'll see how that goes ...