Bug 734952 – app-text/pdfgrep-2.1.2 fails tests

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Agostino Sarubbo 2020-07-31 14:19:33 UTC]

https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: app-text/pdfgrep-2.1.2 fails tests.
Discovered on: amd64 (internal ref: tinderbox)

NOTE:
This machine uses a clang/LLVM toolchain.
If you think that this issue is strictly related to clang/LLVM please block bug 408963. If you think that this issue isstrictly related to the LLD linker, please block bug 731004.

[Comment 1 Agostino Sarubbo 2020-07-31 14:19:39 UTC]

Created attachment 651850 [details]
build.log

build log and emerge --info

[Comment 2 Florian Schmaus 2020-08-02 13:11:52 UTC]

I could reproduce this on my system. Looking at pdfgrep.log shows, for example, for the failing "Context after" test in context.exp, the following pdfgrep output:

Running ./pdfgrep.tests/context.exp ...
spawn /home/flo/data/code/pdfgrep/src/pdfgrep --color=never -A1 one|five /tmp/pdfgrep_test
s.8HVMmpQ1NI/lines.pdf
line   one
line   two
--
line   five
line   six
FAIL: Context after

where the expected output is

"line one
line two
--
line five
line six"

Note that there is only a single space between 'line' and (one|two|five|six). I still need to investigate if the additional whitespace is already in the original PDF create by pdfgrep testsuite, or if it's only in pdfgrep's output.

[Comment 3 Florian Schmaus 2020-08-11 12:30:26 UTC]

The pdfgrep developer and I are currently investigating this.

[Comment 4 Sam James 2021-05-14 17:37:23 UTC]

Some rough thoughts:
- play with libpcre* use flags
- libpcre1 vs libpcre2 if it supports both
- try upgrading various libraries in a Debian container
- what about in a vanilla Gentoo docker container? reproducible then?