[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1)
From: |
Jelle Licht |
Subject: |
[bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1) |
Date: |
Tue, 09 Feb 2021 12:56:42 +0100 |
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
- [bug#46377] [PATCH] gnu: tesseract-ocr: update to 4.1.1, Andy Tai, 2021/02/08
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1, Andy Tai, 2021/02/08
- Message not available
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/08
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Jelle Licht, 2021/02/08
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/08
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1),
Jelle Licht <=
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/09
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Jelle Licht, 2021/02/09
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/09
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/10
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/10
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Jelle Licht, 2021/02/11
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/11
- bug#46376: [PATCH] gnu: tesseract-ocr: update to 4.1.1), Jelle Licht, 2021/02/13
- [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1), Andy Tai, 2021/02/13
Message not available