Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2019-06-21 Thread Sean Whitton
Hello, On Thu 20 Jun 2019 at 08:34AM +02, Johannes Schauer wrote: > 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

Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2019-06-21 Thread Sean Whitton
Hello, On Wed 19 Jun 2019 at 11:42PM -07, James R Barlow wrote: > 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 >

Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2019-06-20 Thread Johannes Schauer
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

Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2019-06-20 Thread James R Barlow
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

Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2019-06-19 Thread Sean Whitton
[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

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2018-05-18 Thread Sean Whitton
Hello, On Fri, May 18 2018, James R. Barlow wrote: > I ended up deciding to remove PyMuPDF (apart from optional tests in > the test suite, anyway) from the next major release of ocrmypdf - I'll > still need your support with some new dependencies, but I think I've > found a solution that should

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2018-03-31 Thread Sean Whitton
Hello, On Sat, Mar 31 2018, James R Barlow wrote: > Hello Sean, > > As promised ocrmypdf v6.1.2 makes pymupdf optional but recommended. My > continuous integration tests check with and without pymupdf. > > The only major regression without pymupdf is that with all of: > 1) an input file

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2018-03-26 Thread Sean Whitton
Hello, On Mon, Mar 26 2018, James R Barlow wrote: > Thanks for the information. That's a worryingly high wall to climb and > I'm concerned about implications for other platforms as well. > > I would appreciate if you can see about getting an exception, but I > think I will change PyMuPDF to an

Processed: Re: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

2018-03-26 Thread Debian Bug Tracking System
Processing control commands: > reassign -1 wnpp Bug #894068 [ocrmypdf] ocrmypdf: New dependency on PyMuPDF for v6.0.0 Bug reassigned from package 'ocrmypdf' to 'wnpp'. No longer marked as found in versions v6.0.0. Ignoring request to alter fixed versions of bug #894068 to the same values