[bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1)

[Jelle Licht <jlicht@posteo.net>]

Hello Andy,

I have some additional questions about your updated patch.

Andy Tai <atai@atai.org> writes:

> updated patch attached
>> > -       (file-name (git-file-name name version))
>> > +              (commit commit)
>> > +              ;; Fetch git submodules
>> > +              (recursive? #t)))
>>
>> Instead of stating what the code does, would you consider adding a
>> comment why this is needed?
>>
>
> commented as suggested

I was unclear in my message: Of course there are some submodules that
are being fetched; why should we fetch them in the first place? From
a cursory glance, they seem required to do stuff such as running the
tests, which in this iteration of the patch are not being run.

FWIW, leaving out the `recursive? #t' still allows me to build
tesseract-ocr: could you try and see if it makes a difference in your
use of tesseract?

>> >      (inputs
>> > -     `(("leptonica" ,leptonica)))
>> > +     `(  ("cairo" ,cairo)
>> > +         ("icu" ,icu4c)
>> > +         ("leptonica" ,leptonica)
>> > +         ("pango" ,pango)))

I just built the package: no references are made to cairo, icu4c and
pango, and tesseract seems to build fine without them: is there a
specific reason why these were added to the inputs?

>> > +    (native-inputs
>> > +     `(("autoconf" ,autoconf)
>> > +       ("autoconf-archive" ,autoconf-archive)
>> > +       ("automake" ,automake)
>> > +       ("googletest" ,googletest)
>> > +       ("libtool" ,libtool)
>> > +       ("pkg-config" ,pkg-config)))
>> >      (arguments
>> >       '(#:configure-flags
>> >         (let ((leptonica (assoc-ref %build-inputs "leptonica")))
>> > -         (list (string-append "LIBLEPT_HEADERSDIR=" leptonica "/include")))))
>> > +         (list (string-append "LIBLEPT_HEADERSDIR=" leptonica "/include")))
>> > +       ;; some test, applybox_test fails to build
>> > +       #:tests? #f))
>>  2 nits: Is it possible to patch or disable only the failing tests?
>
> tests failing to build probably due to some issue with parallel
> builds; did not dig into it as probably will take much time; will be
> TODO if time allows)

I'll defer to someone with more experience with tesseract, as I have no
experience to speak of on whether this leads to us having a (subtly)
broken package.

Adding the following arguments might help to validate your assumption:
`#:make-flags (list "-j" "1")'.

Thanks,
 - Jelle