[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