control: reassign -1 wnpp control: forcemerge 841404 -1 Dear James,
On Mon, Mar 26 2018, James R. Barlow wrote: > In v6.0.0, which addresses and hopefully fixes #888917, I have introduced a > new dependency on PyMuPDF (Python bindings for MuPDF). Unfortunately PyMuPDF > isn't available in Debian as yet (I have checked there is no python3-pymupdf). Thank you for working on that bug! > The build procedure should go like this: > > - download/unpack MuPDF to mupdf/ > - download/unpar PyMuPDF to pymupdf/ > - cp pymupdf/fitz/_mupdf_config.h mupdf/include/mupdf/fitz/config.h > - export CFLAGS=-fPIC > - make HAVE_X11=no HAVE_GLFW=no HAVE_GLUT=no > - patch pymupdf/setup.py to point library_dirs and include_dirs to the > output of mupdf/ build > > The reason for this circumlocution is that the vendor of MuPDF, Artifex, > does not provide or support dynamic libraries or a stable ABI, and > compiling the Python bindings requires a dynamic library. Perhaps as a way > to warn people about their stance, they don't enable -fPIC by default and > link their application statically. > > This means that unfortunately, one cannot link to libmupdf-dev (and > actually, I'm not sure if libmupdf-dev serves any purpose at all, unless > it were rebuilt with -fPIC). Certainly if the maintainers of this > package could be persuaded to build it with -fPIC that would make this > much easier. > > I did try to build with it with Debian sid against the libmupdf-dev > library. The error, as with Ubuntu, is: > relocation R_X86_64_PC32 against symbol `fz_empty_irect' can not be > used when making a shared object; recompile with -fPIC If we followed this build procedure then there would be two copies of mupdf in Debian: in the mupdf package and in the pymypdf package. This is disallowed by Debian Policy 4.13 because it makes it harder to apply security updates. And for any libraries that read PDFs, security is a real concern (see the mupdf bug list: there have been several CVEs). Further, Policy 10.2 explicitly forbids building static libraries with -fPIC, unless an exception thought warranted in discussion on our main development mailing list. I think this might be a case where we can argue for that exception, but I'm going to need to do some reading before I can be sure that that's what we should do. So unfortunately OCRmyPDF is probably going to be out-of-date in Debian for a while. > I'm happy to help with the packaging of this dependency, and I got it the > process working for Python binary wheels already. However, I don't really > know much about Debian processes and policy. Thanks. The best place to start would probably be our libraries policy, section 10.2 of Debian Policy.[1] And the following relevant bugs: #617253, #719351, #841403. [1] https://www.debian.org/doc/debian-policy/ -- Sean Whitton
signature.asc
Description: PGP signature
