Bug#1023273: Old version is not working

2022-11-14 Thread James R Barlow
The current maintainer of ocrmypdf and pikepdf is looking for a new maintainer, if someone else is able. On Sun, Nov 13, 2022 at 6:06 AM Anton Gladky wrote: > The newer 14 version of ocrmypdf is needed to suppor the > ghostscript 10. > > I have checked and can confirm, that 14.0.1 is working

Bug#976092: ocrmypd fails autopkg tests in testing

2020-11-29 Thread James R Barlow
This is almost certainly a problem with how Debian is compiling or linking ghostscript with libjbig2dec. This error would be reproducible with: gs -sDEVICE=pngmono -o out.png any_pdf_that_contains_a_jbig2_image.pdf Debian's test suite for ghostscript is just a simple smoke test, so ocrmypdf

Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest

2019-09-09 Thread James R Barlow
Sean Whitton and I confirmed the issue still occurs with Ghostscript 9.28rc2. I reported the issue with Ghostscript here: https://bugs.ghostscript.com/show_bug.cgi?id=701552 On Fri, Sep 6, 2019 at 1:58 AM Jonas Smedegaard wrote: > > Quoting James R Barlow (2019-09-06 10:15:59) > > O

Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest

2019-09-06 Thread James R Barlow
On Thu, Sep 5, 2019 at 11:57 PM Jonas Smedegaard wrote: > > Quoting Sean Whitton (2019-09-06 06:20:47) > > On Sat 31 Aug 2019 at 03:58PM +02, Jonas Smedegaard wrote: > > > > > Possibly some of the other tools uses undocumented insecure > > > ghostscript calls which was recently removed. > > > > >

Bug#934035: ocrmypdf: FTBFS in stretch (failing tests)

2019-08-06 Thread James R Barlow
The issue here is that we have an old version of ocrmypdf (4.3.5) with a backported version of Ghostscript (9.26) and the latter's behavior has changed in a way that breaks the test. I recommend disabling the test and documenting a caveat that certain metadata may not be preserved in output

Bug#903627: ocrmypdf: contains workaround for old version of python3-ruffus which should not be used with current python3-ruffus

2018-07-12 Thread James R Barlow
I backported the fixes related to python3-ruffus 2.7, python 3.7 support, and a few other minor changes from 7.0.0. I released it just now as 6.2.2, so that should take care of it. Let me know if there are any further issues. On Thu, 12 Jul 2018 at 01:03 Sean Whitton wrote: > Package: ocrmypdf

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

2018-03-25 Thread James R. Barlow
Package: ocrmypdf Version: v6.0.0 Severity: serious Tags: newcomer Justification: fails to build from source (but built successfully in the past) Dear Sean, In v6.0.0, which addresses and hopefully fixes #888917, I have introduced a new dependency on PyMuPDF (Python bindings for MuPDF).

Bug#888917: ocrmypdf fails to run it's testsuite

2018-01-31 Thread James R Barlow
Upstream here. The reason the suite fails like that is that mandatory-for-testing dependencies were also removed. The test suite runs on Travis CI in 10-12 minutes. On Debian CI, 15 minutes. For comparison ffmpeg, another compute intensive CLI program, takes 10 minutes. This is an OCR program