Package: ocrmypdf
Version: v6.0.0
Severity: serious
Tags: newcomer
Justification: fails to build from source (but built successfully in the past)

Dear Sean,

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

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

The make options and replacement of the header file in mupdf are all 
disabling features unnecessary for PyMuPDF's purposes. It shrinks the 
binary from 30 MB to 3 MB.

The PyMuPDF developers describe their build process here:
https://github.com/rk700/PyMuPDF/wiki/Ubuntu-Installation-Experience

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.

Regards,
James

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.119-boot2docker (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages ocrmypdf depends on:
pn  ghostscript                   <none>
pn  icc-profiles-free             <none>
pn  liblept5                      <none>
ii  python3                       3.6.5~rc1-1
pn  python3-cffi-backend-api-max  <none>
pn  python3-cffi-backend-api-min  <none>
pn  python3-img2pdf               <none>
pn  python3-pil                   <none>
ii  python3-pkg-resources         39.0.1-1
pn  python3-pypdf2                <none>
pn  python3-reportlab             <none>
pn  python3-ruffus                <none>
pn  qpdf                          <none>
pn  tesseract-ocr                 <none>
ii  zlib1g                        1:1.2.8.dfsg-5

Versions of packages ocrmypdf recommends:
pn  unpaper  <none>

Versions of packages ocrmypdf suggests:
pn  img2pdf          <none>
pn  ocrmypdf-doc     <none>
pn  python-watchdog  <none>

Reply via email to