Hi Sean, Quoting Sean Whitton (2019-06-20 07:28:12) > [updating CC to point to the newly-filed RFP] thank you! > Thank you again for looking into this. Incidentally I'm currently writing a tool that needs PyMuPDF so I'll probably spend a bit more time on 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. Agreed. https://github.com/pymupdf/PyMuPDF/issues/312 > 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. We have a similar issue but a less severe one because this is only one package and not a whole ecosystem of them. Since the required tooling is currently missing, I guess any maintainer of PyMuPDF would need to closely follow mupdf development and trigger binNMUs as necessary. > 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. Indeed there seem to be some files in it that are just GPL-3 and not GPL-3+, namely in the demo and examples directories. d/copyright has to be adjusted accordingly. > 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. d/copyright only documents the contents of the source package. As far as I know we do not yet have means to also document the inferred license of any generated binary artifacts? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature