On Wed, 25 Apr 2018 10:51:09 +0200 Graham Inggs wrote:
> I agree, and with the upload of leptonlib 1.75.3-4, the tests are now
> run during the build [3], and failure here will result in a failed
> build. Builds of leptonlib were successful on all architectures [4]
> except sparc64, which is notor
Hello,
On Fri, May 04 2018, Jeff Breidenbach wrote:
> Tesseract in Debian just added a build time smoke test AND Stefan
> fixed the big-endian problem. Should be live tomorrow in Sid. Assuming
> that works well, Graham should be able to re-activate the disabled
> OCRMyPDF tests. Note that this is
Tesseract in Debian just added a build time smoke test AND Stefan fixed
the big-endian
problem. Should be live tomorrow in Sid. Assuming that works well, Graham
should be
able to re-activate the disabled OCRMyPDF tests. Note that this is Debian
only; Ubuntu
18.04 is out the door so no longer perti
Hello Graham,
On Wed, Apr 25 2018, Graham Inggs wrote:
> We agreed on marking the tests failing on big-endian XFAIL as a
> short-term solution.
>
> Sean, I'm not sure if you want to include this in the Debian packaging
> of ocrmypdf as well, but here [1] it is.
Thank you (and Jeff) for your work
Hi
On 24/04/2018 23:32, Jeff Breidenbach wrote:
> Recommend we talk in real time. Will send you contact details by
> private email.
Jeff, thanks for contacting me, it is much appreciated!
We agreed on marking the tests failing on big-endian XFAIL as a
short-term solution.
Sean, I'm not sure
Great to see the most recent test run passed, even if it is with liberal
application of "expect failure". The Canonical powers that be should be
appeased for the moment. I appreciate the last minute effort to get this,
and Tesseract, into the next Ubuntu.
Thinking about the failures, I suspect tha
Am 25.04.2018 um 03:37 schrieb Dan Bloomberg:
> There's an endianness.h file in leptonica/src. Does it say BIG_ENDIAN
> or LITTLE_ENDIAN on your s390?
It says BIG_ENDIAN on my emulated S390X with Debian Testing.
Is arrayaccess.h correct for big endian machines? The 16 and 32 bit
accessors look s
Given the date, it sounds like we have an emergency situation.
I'm really stuck here. My only known access to a big endian is an emulator
with Wheezy.
http://create.stephan-brumme.com/big-endian/
That's good enough for checking suspicious parts of Leptonica. I tried and
found nothing. But i
Hi Jeff
On 3 January 2017 at 20:24, Jeff Breidenbach wrote:
> Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited to
> take a look if someone can give him access to a big endian machine.
I note this bug is still open, so I assume this is still the case.
If so, would you pl
Sorry, I wasn't aware of the guest account thing. Probably my fault for not
reading
email carefully enough. I am a Debian Developer and will sponsor this
request. Fill
out the information "Information guest needs to supply to sponsoring DD"
and I will
sign it.
https://dsa.debian.org/doc/guest-acco
On 01/04/17 08:03, Graham Inggs wrote:
On 3 January 2017 at 20:24, Jeff Breidenbach wrote:
Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited to
take a look if someone can give him access to a big endian machine.
It is possible for non-DDs to request temporary access to
On 3 January 2017 at 20:24, Jeff Breidenbach wrote:
> Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited to
> take a look if someone can give him access to a big endian machine.
It is possible for non-DDs to request temporary access to porterboxes,
see https://dsa.debian.or
I've just uploaded 1.74.1-1 to Debian, which contains something
similar to Sean's patch.
Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited
to
take a look if someone can give him access to a big endian machine.
There are no known endian problems with Tesseract 3 or Leptonica, but if any
are definitively found they will get immediate attention.
I am not going to
I'm the ocrmypdf upstream author.
First, be aware that the output of OCR and autorotate is cached in the test
suite and the results are persisted between test cases and runs of the test
suite in the tests/cache folder. The cache hit/miss check is not smart
enough to pick up changes that aren't ref
Control: tags -1 - patch
I've just tried running ocrmypdf's test suite against the recently
released leptonlib 1.74.0 on powerpc and I get the same results I did
with 1.73 and Sean's patch, i.e. the following three tests fail:
test_autorotate[hocr]
test_autorotate[tesseract]
test_autorotate_thres
I built leptonlib 1.73-6 including Sean's patch on powerpc and s390x.
I then ran ocrmypdf's test suite against it.
Test results went from:
tests/test_hocrtransform.py .
tests/test_main.py
...F..ss.F.
tests/test_pageinfo.py
Package: liblept5
Version: 1.73-6
Severity: normal
Tags: patch
Dear maintainer,
liblept looks to be broken on big endian architectures. This was
discovered by means of the OCRmyPDF test suite. It's failing on
s390x,[1] the broken files are emitted at the stage where OCRmyPDF
invokes liblept cod
18 matches
Mail list logo