I should mention that ocrmypdf no longer has an immediate use for PyMuPDF - I went the route of creating pikepdf, Python bindings for qpdf, and this is library is now in Debian thanks to Sean's work on packaging it. I don't think I would use PyMuPDF if it were available. pikepdf overlaps the core of PyMuPDF but is not a competing library, offering low level PDF manipulation and much in the less way of content generation.
As such the original basis for this ticket is gone. I just want to make sure people aren't putting effort into this ticket for ocrmypdf alone. If other people want to see PyMuPDF added to Debian for their own reasons, that's quite fine. -James On Wed, Jun 19, 2019 at 10:28 PM Sean Whitton <spwhit...@spwhitton.name> wrote: > [updating CC to point to the newly-filed RFP] > > Hello Johannes, > > Thank you again for looking into this. > > On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote: > > > after my struggles in #930212 I now figured out how to compile stuff > against > > the static library in libmupdf-dev. As a result I managed to package > PyMuPDF. > > You can see the result here: > > > > https://salsa.debian.org/python-team/modules/pymupdf > > > > It's mostly Lintian-clean and just waiting for somebody who feels like > > maintaining it in the future. :) > > I've had a look at your repo. I've got a few questions and comments > (relevant to whomever wants to take ownership of the ITP and upload this > to NEW). > > A tool called SWIG, with which I'm unfamiliar, was used to generate > fitz/fitz.py from the files fitz/*.i, but this tool does not get run > during the package build. There could be updates to SWIG, including > security updates, which would change fitz.py. It seems to me that we > want to run SWIG during the package build to ensure that fitz.py > reflects all improvements made to SWIG since pymupdf upstream ran that > tool when releasing pymupdf. > > Secondly, how do you foresee us triggering binNMUs to rebuild this > package when the static library in libmupdf-dev changes? We would need > to be sure that this package gets rebuilt if a security update was made > to libmupdf-dev, for example, or the vulnerable version of mupdf would > still be present in this package. PDF libraries tend to get CVEs, to > put it mildly. I'm worried we've the same sort of problem as discussed > in #928227. > > Finally, I noticed that the project looks to be GPL-3 not GPL-3+, though > I haven't looked through every file in the source. I also haven't > thought carefully about the implications of statically linking a project > that's under the AGPL. I think that we can do it, but I'm not sure > quite what license the binary package will end up with, and quite how to > document that in d/copyright. > > -- > Sean Whitton >
