Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
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 signature.asc Description: signature
Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
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 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 >
Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
[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
Bug#930761: RFP: PyMuPDF -- python bindings for MuPDF
Package: wnpp Severity: wishlist * Package name: pymupdf Version : 1.14.16 Upstream Author : Ruikai Liu and Jorj X. McKie * URL : https://github.com/pymupdf/PyMuPDF * License : GPL-3 Programming Lang: Python Description : python bindings for MuPDF josch provides this long description: Allows one to access files in PDF, XPS, OpenXPS, CBZ, EPUB, and FB2 (e-books) formats, and it is known for its top performance and high rendering quality. . PDF manipulation and generation functions are available, including metadata and bookmark maintenance, document restructuring, annotation / link handling and document or page creation. -- Sean Whitton signature.asc Description: PGP signature
Bug#930755: ITP: q2-metadata -- QIIME 2 plugin for working with and visualizing Metadata
Package: wnpp Owner: Liubov Chuprikova Severity: wishlist * Package name: q2-metadata Version : 2019.4.0 Upstream Author : QIIME 2 development team * URL : https://qiime2.org/ * License : BSD-3-clause Programming Lang: Python Description : QIIME 2 plugin for working with and visualizing Metadata QIIME 2 is a powerful, extensible, and decentralized microbiome analysis package with a focus on data and analysis transparency. QIIME 2 enables researchers to start an analysis with raw DNA sequence data and finish with publication-quality figures and statistical results. Key features: * Integrated and automatic tracking of data provenance * Semantic type system * Plugin system for extending microbiome analysis functionality * Support for multiple types of user interfaces (e.g. API, command line, graphical) . QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome analysis pipeline. QIIME 2 will address many of the limitations of QIIME 1, while retaining the features that makes QIIME 1 a powerful and widely-used analysis pipeline. . QIIME 2 currently supports an initial end-to-end microbiome analysis pipeline. New functionality will regularly become available through QIIME 2 plugins. You can view a list of plugins that are currently available on the QIIME 2 plugin availability page. The future plugins page lists plugins that are being developed. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/q2-metadata
Bug#921347:
That's nice. Hope we can get that to unstable soon. On June 19, 2019 8:40:47 PM GMT+02:00, Peter Zahradnik wrote: >On 6/18/19 3:52 PM, Dawid Dziurla wrote: >> What's the status of packaging? >> >> I would love to see this software in Debian. >Hi, > >I've uploaded new version to mentors, there are still some lintians >warnings which needs to be fixed >https://mentors.debian.net/package/platformio > >Peter
Bug#921347:
On 6/18/19 3:52 PM, Dawid Dziurla wrote: What's the status of packaging? I would love to see this software in Debian. Hi, I've uploaded new version to mentors, there are still some lintians warnings which needs to be fixed https://mentors.debian.net/package/platformio Peter
Processed: ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps
Processing commands for cont...@bugs.debian.org: > retitle 930557 ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, > smart borders, smart gaps Bug #930557 [wnpp] ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps Bug #909646 [wnpp] RFP: i3-gaps -- A fork of i3wm tiling window manager with more features, including gaps. Ignoring request to change the title of bug#930557 to the same title Changed Bug title to 'ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps' from 'RFP: i3-gaps -- A fork of i3wm tiling window manager with more features, including gaps.'. > owner 930557 Socrates Tzagiousis Bug #930557 [wnpp] ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps Bug #909646 [wnpp] ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps Owner recorded as Socrates Tzagiousis . Owner recorded as Socrates Tzagiousis . > End of message, stopping processing here. Please contact me if you need assistance. -- 909646: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909646 930557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930557 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: RFP: qmodbus -- Qt-based ModBus master application
Processing commands for cont...@bugs.debian.org: > retitle 930358 RFP: qmodbus -- Qt-based ModBus master application Bug #930358 [wnpp] qmodbus: Qt-based ModBus master application Changed Bug title to 'RFP: qmodbus -- Qt-based ModBus master application' from 'qmodbus: Qt-based ModBus master application'. > End of message, stopping processing here. Please contact me if you need assistance. -- 930358: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930358 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930723: ITP: arduino-sanguino -- atmega644 files for use with Arduino
Package: wnpp Severity: wishlist Owner: 3-D printer team <3dprinter-gene...@alioth-lists.debian.net> * Package name: arduino-sanguino Version : 1.0.0 Upstream Author : Kristian Sloth Lauszus * URL : http://lauszus.github.io/Sanguino/ * License : GPL-3+ Programming Lang: C++ Description : Platform files for Arduino to run on ATmega644 This package contains files for compiling programs for the ATmega644 microcontroller. This is useful for people who want to use the Arduino programming environment with the atmega644 microcontroller as the target hardware. I will maintain this within the 3-D printer team.
