[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