bugGNU roff - Bugs: bug #61302, [tests] non-portable use of echo

 
 

bug #61302: [tests] non-portable use of echo

Submitter:  Deri James <deri>
Submitted:  Wed 06 Oct 2021 10:35:06 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Build/Installation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 28 Oct 2021 05:28:10 AM UTC, comment #8: 

The only groff problems turned out to be my non-portable use of echo in some test scripts.

I see the pnmcrop diagnostics on Mac OS X as well, but they are harmless; the images linked by the pic-*.html and webpage.html files look intact and correct.  It appears that some versions of pnmcrop ignore the command's `-quiet` flag, which pre-grohtml is definitely passing to it.  So, not our problem.


commit 244e55f660e33cdb84cec3baea7eca69279cf579
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Oct 9 17:51:50 2021 +1100

    [tests]: Fix portability problems in 2 tests.

    * src/roff/groff/tests/break_zero-length_output_line_sanely.sh:
    * tmac/tests/s_PN-works.sh: Migrate from `echo` to `printf` for test
      inputs containing backslashes to be interpreted literally.

    Fixes part of <https://savannah.gnu.org/bugs/?61302>.  Thanks to Deri
    James for identifying the problem.


G. Branden Robinson <gbranden>
Group administrator
Sat 09 Oct 2021 05:09:12 PM UTC, comment #7: 

Well the psselect fix was accepted upstream very quickly.

https://github.com/rrthomas/psutils/commit/77c2ec947dd5c6525d313f4065533488fa345f10

Deri James <deri>
Group Member
Sat 09 Oct 2021 03:17:07 PM UTC, comment #6: 

Hi Branden,

I was confused in thinking just having libuchardet available would be sufficient for groff to use it, you are correct, I needed to install the devel package as well. Maybe the message about uchardet could mention it requires the devel package.

[root@pip ~]# urpmq -l lib64uchardet-devel
/usr/include/uchardet
/usr/include/uchardet/uchardet.h
/usr/lib64/libuchardet.a
/usr/lib64/libuchardet.so
/usr/lib64/pkgconfig/uchardet.pc


It look like all the problems identified previously are either fixed or have no detrimental effect.

============================================================================
Testsuite summary for GNU Troff 1.23.0.rc1.1321-b74fa-dirty
============================================================================
# TOTAL: 84
# PASS:  81
# SKIP:  0
# XFAIL: 3
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

Deri James <deri>
Group Member
Sat 09 Oct 2021 02:45:35 PM UTC, comment #5: 

Hi Branden,

I have diagnosed the problem with the perl version of psselect and reported it upstream.

https://github.com/rrthomas/psutils/issues/38

While eventually this will fix the problem, I'm not sure how long it will take to work through. Maybe we should open a new groff issue specifically for this problem, i.e. Problems building webpage.html, where I could put a patch which fixes the problem for psselect (remember it is a perl script so simple patch is enough).

Deri James <deri>
Group Member
Sat 09 Oct 2021 10:47:40 AM UTC, comment #4: 


commit 244e55f660e33cdb84cec3baea7eca69279cf579
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Oct 9 17:51:50 2021 +1100

    [tests]: Fix portability problems in 2 tests.

    * src/roff/groff/tests/break_zero-length_output_line_sanely.sh:
    * tmac/tests/s_PN-works.sh: Migrate from `echo` to `printf` for test
      inputs containing backslashes to be interpreted literally.

    Fixes part of <https://savannah.gnu.org/bugs/?61302>.  Thanks to Deri
    James for identifying the problem.


G. Branden Robinson <gbranden>
Group administrator
Sat 09 Oct 2021 06:42:47 AM UTC, comment #3: 

Hi, Deri!

comment #2:

I'm trimming out the pnmutils and psselect stuff for now as those seem exceptionally thorny, and/or to have arising from behavior changes across versions.  Always a joy to deal with... :-/


>     Package 'uchardet', required by 'virtual:world', not found
>     configure:21802: WARNING: uchardet library not found, preconv might not work properly
>
> This is the uchardet issue you noted.  Is it common for libuchardet to be installed without its pkg-config support in place?  A more traditional Autoconf test might be useful, I admit.


>
> Very few of the rpms on my system include a *.pc file for pkg-config. For example the lib64uchardet0 rpm contains these files:-
>
> root@pip ~]#rpmq -l lib64uchardet0
> /usr/lib/.build-id
> /usr/lib/.build-id/3b
> /usr/lib/.build-id/3b/223b77034781d372e29bb70be3f320cdcf65ea
> /usr/lib64/libuchardet.so.0
> /usr/lib64/libuchardet.so.0.0.7
>
> Even on a debian type system (osmc), admittedly this is a stripped back version of debian, so may not have the dpkg hooks which may generate the .pc file whilst installing, I don't know how it works. The ucharget.pc does not exist anywhere, even though the library is installed:-
>
> osmc@osmc3:~$ dpkg -L libuchardet0
> /.
> /usr
> /usr/lib
> /usr/lib/arm-linux-gnueabihf
> /usr/lib/arm-linux-gnueabihf/libuchardet.so.0.0.6
> /usr/share
> /usr/share/doc
> /usr/share/doc/libuchardet0
> /usr/share/doc/libuchardet0/changelog.Debian.gz
> /usr/share/doc/libuchardet0/copyright
> /usr/lib/arm-linux-gnueabihf/libuchardet.so.0


I'd expect pkg-config-related .pc files to be in packages called `-dev` (Debian) or `-devel` (Red Hat), because they're only useful on platforms where development happens.


$ dpkg -L libuchardet-dev | grep -F .pc
/usr/lib/x86_64-linux-gnu/pkgconfig/uchardet.pc



>      FAIL: tmac/tests/s_PN-works.sh
>     ==============================
>
>     FAIL tmac/tests/s_PN-works.sh (exit status: 1)
>
> Can you have a look at the body of the test and try to reproduce it with test-groff in your build?  It's really simple and I can't imagine what might have gone wrong.  This test does not fail on HEAD.


>
> This is a strange one!!
>
> If you change the first line to #!/bin/bash (which is my default shell), the test fails. The reason is because under bash the two back slashes (\\n[PN]) are not consumed by the shell, so groff is emitting "This is page \n[PN]." which is not what you want. Under dash one of the back slashes is consumed before being passed to groff, so you get a test pass.
>


>      FAIL: src/roff/groff/tests/break_zero-length_output_line_sanely.sh
>     ==================================================================
>
>     troff: <standard input>:10: warning [p 0, 0.0i, div 'A', 0.0i]: can't break line
>     troff: <standard input>:11: warning [p 1, 0.0i]: can't break line
>     FAIL src/roff/groff/tests/break_zero-length_output_line_sanely.sh (exit status: 1)
>
> This one bears close examination too.  Are you on a branch?  Did you somehow not get commit 69efbe0a (4 September)?


>
> Another dash/bash difference, change to bash and test fails, remove the grep and the reason is obvious - different output from groff.


Yup.  I got sloppy and used `echo` with embedded quoted backslashes, which is unfortunately not portable.  I've just changed the tests to use `printf` and checked those tests with both dash and bash and they work now.

I'll push fixes for these tests momentarily.

> Well I think I've diagnosed all the reasons why the build and checks have problems on non-debian flavours. I'm not sure if these dashisms are portable to non-linux systems.


Fortunately I don't think we're dealing with dashisms here, but rather the old, old problem of `echo` being unreliable.

> I'll pursue the psselect issue a little more. I will try to find out whether it is all groff documents with eps files embedded which confuse psselect, or whether it is something particular about the workflow which produces gnu.eps. One question, I can't find any versions on my system, on old disks which included webpage.html, is this relatively new?


It shipped in the "groff" (but not groff-base) package in Debian's groff 1.22.4 packages, and I think it goes back much farther than that (before my time).  Lines 107-114 in doc/doc.am date back to a Bertrand commit (migrating groff to Automake) in September 2014.

What distributors ultimately decide to ship is another question.  :-/

I'm marking this ticket as "In Progress" since we're both working on things, though you've grabbed the more difficult tasks.

G. Branden Robinson <gbranden>
Group administrator
Fri 08 Oct 2021 10:55:35 PM UTC, comment #2: 


       GROFF    doc/pic.html
    [2] [1] Wrote 1 pages
    pnmcrop: The image is entirely background; there is nothing to crop.

This is bad news.  I don't get these.  Something is going wrong in/around grohtml.  I expect your copy of the HTML version of the pic manual is missing all of its images and is therefore nearly useless.  That's a showstopper.  I broke but then fixed grohtml over the course of a couple of days, though I don't remember seeing these exact diagnostics.  If you're on a branch (sboxes?) make sure you have commit 991aa9da (30 July).  But don't get your hopes up--I suspect you do have it because you're seeing errors from the pnm* suite, and another change of mine around the same time made these changes visible (98367a84, 26 July).


As far as I know I am on an up to date "master", this is what git log shows me:-

4d3cde4d (HEAD -> master, origin/master, origin/HEAD) doc/groff.texi (ms): Sync with doc/ms.ms.
3e38de40 [docs]: Fix ms documentation nits.
d7749b68 groff_man*(7): Fix content nits.
a8109f73 [grotty]: Slightly refactor.
966161e0 [man]: Fix oversight and improve `MR` test.
e81d3b03 grotty(1): Fix content nit.
b74fa48b groff_man*(7): Mention .OP as a deprecated macro.
835038b8 grotty(1): Use "that" with restrictive clause.
999f5083 [man]: Add `MR` macro for man page xrefs.
12aa38c7 NEWS: Add OSC 8 testing guidance.
a7c10cf9 [man]: Fix Savannah #61279.
d02e369f Regression-test Savannah #61279.
a460ba98 [man]: Rename internal macro.
a0e55321 groff_man*(7): Fix terminology nit.
85cd0195 [docs]: Correct claim re: ms(7)'s ".NH S".

On top of this I have staged the changes to add the pdf boxes mom requires. See sboxes.patch.


     GROFF    doc/pic.html
    [2] [1] Wrote 1 pages
    pnmcrop: The image is entirely background; there is nothing to crop.

This is bad news.  I don't get these.  Something is going wrong in/around grohtml.  I expect your copy of the HTML version of the pic manual is missing all of its images and is therefore nearly useless.  That's a showstopper.  I broke but then fixed grohtml over the course of a couple of days, though I don't remember seeing these exact diagnostics.  If you're on a branch (sboxes?) make sure you have commit 991aa9da (30 July).  But don't get your hopes up--I suspect you do have it because you're seeing errors from the pnm* suite, and another change of mine around the same time made these changes visible (98367a84, 26 July).


I think this is a version issue:-

[derij@pip build (master)]$ pnmcrop --version
pnmcrop: Using libnetpbm from Netpbm Version: Netpbm 10.87.1
pnmcrop: Built at 2020-02-16 03:42:12
pnmcrop: Built by iurt
pnmcrop: BSD defined
pnmcrop: RGB_ENV='RGBDEF'
pnmcrop: RGBENV= 'RGBDEF' (env vbl is unset)

The actual png is fine and the html looks Ok.

I believe what is happening is that the pnmcut (which precedes the pnmcrop), has actually removed all the white pixels outside the figure, so pnmcrop has nothing to do. The message is confusing but I suspect it is searching for "background, i.e. pixels it can crop, but can't find anything. The man page says:-

-blank-image={abort|pass|minimize|maxcrop}
abort
program fails, with explanatory message (default)
no modification to image
pass
This determines how pnmcrop handles an image which is entirely background (blank), a case
where cropping doesn’t make much sense.
minimize
output is a single pixel (of the background color)

So a fix may be to include the pass flag in the invocation. However, I am not sure whether a call to pnmcrop is even needed, given that pnmcut has removed the excess white pixels! I suspect it is a case of belt and braces. To debug this I changed the TRUE to FALSE in two calls to xtmpfile in pre-html.cpp. This leaves the two temporary files worked on in /tmp.


     GROFF    doc/webpage.html
    [1] [1] Wrote 1 pages
    pnmcut: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
    pnmcrop: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
    pnmtopng: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
    Calling 'pnmcut 100 119 702 182 < /tmp/groff-page-2lqna3 | pnmcrop -quiet | pnmtopng -quiet -background rgb:f/f/f -transparent rgb:f/f/f> img/webpage-1.png
    ' returned status 256
    [2] [1] Wrote 1 pages
    GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
    Calling 'echo showpage | gs -q -dBATCH -dSAFER -dDEVICEHEIGHTPOINTS=792 -dDEVICEWIDTHPOINTS=700 -dFIXEDMEDIA=true -sDEVICE=pnmraw -r100 -dTextAlphaBits=4 -dGraphicsAlphaBits=4  -sOutputFile=/tmp/groff-page-2lqna3 /tmp/groff-ps-3FDKs6 -
    ' returned status 256
    sh: line 1: /tmp/groff-page-2lqna3: No such file or directory
    pnmcrop: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
    pnmtopng: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
    Calling 'pnmcut 103 322 137 224 < /tmp/groff-page-2lqna3 | pnmcrop -quiet | pnmtopng -quiet -background rgb:f/f/f -transparent rgb:f/f/f> img/webpage-2.png
    ' returned status 256

This looks bad and I'm guessing it has a similar cause as the pic.html trouble.  Your version of gs (9.53.3) is newer than mine
(9.27).


This was a tough one!!

The failure is due to the version of psselect used. On my system it is:-

[derij@pip build (master)]$ urpmq -i psutils
Name        : psutils
Version     : 2.04
Release     : 1.mga8
Group       : Publishing
Size        : 111868                       Architecture: noarch
Source RPM  : psutils-2.04-1.mga8.src.rpm
URL         : https://github.com/rrthomas/psutils
Summary     : PostScript utilities
Description :
Utilities for manipulating PostScript documents.
Page selection and rearrangement are supported, including arrangement into
signatures for booklet printing, and page merging for n-up printing.

And on a debian flavour system it is:-

osmc@osmc3:~$ apt-cache show psutils
Package: psutils
Version: 1.17.dfsg-4
Installed-Size: 190
Maintainer: Ian Jackson <ijackson@chiark.greenend.org.uk>
Architecture: armhf
Depends: libc6 (>= 2.7), libpaper1
Recommends: ghostscript
Description-en: PostScript document handling utilities
 This collection of utilities is for manipulating PostScript
 documents.  Page selection and rearrangement are supported, including
 arrangement into signatures for booklet printing, and page merging
 for n-up printing.
 .
 The following programs are included in psutils: epsffit, extractres,
 fixdlsrps, fixfmps, fixmacps, fixpsditps, fixpspps, fixscribeps,
 fixtpps, fixwfwps, fixwpps, fixwwps, getafm, includeres, psbook,
 psmerge, psnup, psresize, psselect, pstops, showchar
 .
 Some programs included here (psmerge) behave differently if gs is
 available, but all programs work without it.
Description-md5: d3e83aa8e0c39f8e84452a2efc781c5b
Multi-Arch: foreign
Homepage: https://github.com/rrthomas/psutils
Tag: devel::lang:perl, devel::library, implemented-in::c,
 implemented-in::perl, interface::commandline, role::devel-lib,
 role::program, scope::utility, use::converting, use::editing,
 use::printing, works-with-format::postscript, works-with::text
Section: text
Priority: optional
Filename: pool/main/p/psutils/psutils_1.17.dfsg-4_armhf.deb
Size: 56938
MD5sum: 79df32f549beacd1ddbff2d714d5f3ca
SHA256: 129cf7d7274835a31286d9fbfa708c5dc06d70ab2114eb2d215a00e19fd8eac3

This version is compiled executable, whilst the later version is a perl script. The problem is triggered by the inclusion of gnu.eps. The perl version barfs at this an proceeds to copy all pages to the output file creating a postscript file which makes "gv" barf a ghostscript error on the second page, which should not be there because psselect -p1 should output just a single page! This took a while to figure out! I suggest we park this error for now and I will try to figure out what is wrong with the perl version.


    Package 'uchardet', required by 'virtual:world', not found
    configure:21802: WARNING: uchardet library not found, preconv might not work properly

This is the uchardet issue you noted.  Is it common for libuchardet to be installed without its pkg-config support in place?  A more traditional Autoconf test might be useful, I admit.


Very few of the rpms on my system include a *.pc file for pkg-config. For example the lib64uchardet0 rpm contains these files:-

root@pip ~]#rpmq -l lib64uchardet0
/usr/lib/.build-id
/usr/lib/.build-id/3b
/usr/lib/.build-id/3b/223b77034781d372e29bb70be3f320cdcf65ea
/usr/lib64/libuchardet.so.0
/usr/lib64/libuchardet.so.0.0.7

Even on a debian type system (osmc), admittedly this is a stripped back version of debian, so may not have the dpkg hooks which may generate the .pc file whilst installing, I don't know how it works. The ucharget.pc does not exist anywhere, even though the library is installed:-

osmc@osmc3:~$ dpkg -L libuchardet0
/.
/usr
/usr/lib
/usr/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf/libuchardet.so.0.0.6
/usr/share
/usr/share/doc
/usr/share/doc/libuchardet0
/usr/share/doc/libuchardet0/changelog.Debian.gz
/usr/share/doc/libuchardet0/copyright
/usr/lib/arm-linux-gnueabihf/libuchardet.so.0


     FAIL: tmac/tests/s_PN-works.sh
    ==============================

    FAIL tmac/tests/s_PN-works.sh (exit status: 1)

Can you have a look at the body of the test and try to reproduce it with test-groff in your build?  It's really simple and I can't imagine what might have gone wrong.  This test does not fail on HEAD.


This is a strange one!!

If you change the first line to #!/bin/bash (which is my default shell), the test fails. The reason is because under bash the two back slashes (\\n[PN]) are not consumed by the shell, so groff is emitting "This is page \n[PN]." which is not what you want. Under dash one of the back slashes is consumed before being passed to groff, so you get a test pass.


     FAIL: src/roff/groff/tests/break_zero-length_output_line_sanely.sh
    ==================================================================

    troff: <standard input>:10: warning [p 0, 0.0i, div 'A', 0.0i]: can't break line
    troff: <standard input>:11: warning [p 1, 0.0i]: can't break line
    FAIL src/roff/groff/tests/break_zero-length_output_line_sanely.sh (exit status: 1)

This one bears close examination too.  Are you on a branch?  Did you somehow not get commit 69efbe0a (4 September)?


Another dash/bash difference, change to bash and test fails, remove the grep and the reason is obvious - different output from groff.

Well I think I've diagnosed all the reasons why the build and checks have problems on non-debian flavours. I'm not sure if these dashisms are portable to non-linux systems.

I'll pursue the psselect issue a little more. I will try to find out whether it is all groff documents with eps files embedded which confuse psselect, or whether it is something particular about the workflow which produces gnu.eps. One question, I can't find any versions on my system, on old disks which included webpage.html, is this relatively new?

Deri James <deri>
Group Member
Thu 07 Oct 2021 05:17:47 AM UTC, comment #1: 

Hi Deri,


BuildFoundries: notice: Generated U-PR...
afmtodit: both Upsilon and Upsilon1 map to *U at /home/derij/groff-git/groff/build/afmtodit line 6441.
BuildFoundries: notice: Generated U-S...


This has "always" been there, but about a year ago I made the complaining program identify itself (3b680c85).  It's ignorable, though I'd like to do something about it.  I guess we should pick one of these Adobe glyphs for our *U character--whichever one is more useful for scientific/mathematical use of Greek, I reckon, and tell users they'll need to get the other via the \N escape sequence.


  YACC     src/preproc/pic/pic.cpp
/home/derij/groff-git/groff/build/../src/preproc/pic/pic.ypp:63.1-7: warning: POSIX Yacc does not support %expect []8;id=b5627ee30005cdb64161b23e00000000;https://www.gnu.org/software/bison/manual/html_node/Diagnostics.html#Wyacc\-Wyacc]8;;\]
   63 | %expect 2
      | ^~~~~~~
/home/derij/groff-git/groff/build/../src/preproc/pic/pic.ypp:1391.11-1396.17: warning: rule useless in parser due to conflicts []8;id=b5627ee30005cdb64161b23e00000001;https://www.gnu.org/software/bison/manual/html_node/Diagnostics.html#Wother\-Wother]8;;\]
 1391 |         | ORDINAL LAST object_type relative_path
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


I see these all the time.  They're "harmless", like the afmtodit warning, but I'd like to fix them some day.


  GROFF    doc/pic.html
[2] [1] Wrote 1 pages
pnmcrop: The image is entirely background; there is nothing to crop.


This is bad news.  I don't get these.  Something is going wrong in/around grohtml.  I expect your copy of the HTML version of the pic manual is missing all of its images and is therefore nearly useless.  That's a showstopper.  I broke but then fixed grohtml over the course of a couple of days, though I don't remember seeing these exact diagnostics.  If you're on a branch (sboxes?) make sure you have commit 991aa9da (30 July).  But don't get your hopes up--I suspect you do have it because you're seeing errors from the pnm* suite, and another change of mine around the same time made these changes visible (98367a84, 26 July).


  GROFF    doc/automake.pdf
troff: ../doc/automake.mom:56: error: can't transparently output node at top level


These have been a fixture of mom(7) for a long time; we're resigned to telling people to ignore them.


  GROFF    doc/webpage.html
[1] [1] Wrote 1 pages
pnmcut: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
pnmcrop: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
pnmtopng: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
Calling 'pnmcut 100 119 702 182 < /tmp/groff-page-2lqna3 | pnmcrop -quiet | pnmtopng -quiet -background rgb:f/f/f -transparent rgb:f/f/f> img/webpage-1.png
' returned status 256
[2] [1] Wrote 1 pages
GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
Calling 'echo showpage | gs -q -dBATCH -dSAFER -dDEVICEHEIGHTPOINTS=792 -dDEVICEWIDTHPOINTS=700 -dFIXEDMEDIA=true -sDEVICE=pnmraw -r100 -dTextAlphaBits=4 -dGraphicsAlphaBits=4  -sOutputFile=/tmp/groff-page-2lqna3 /tmp/groff-ps-3FDKs6 -
' returned status 256
sh: line 1: /tmp/groff-page-2lqna3: No such file or directory
pnmcrop: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
pnmtopng: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
Calling 'pnmcut 103 322 137 224 < /tmp/groff-page-2lqna3 | pnmcrop -quiet | pnmtopng -quiet -background rgb:f/f/f -transparent rgb:f/f/f> img/webpage-2.png
' returned status 256


This looks bad and I'm guessing it has a similar cause as the pic.html trouble.  Your version of gs (9.53.3) is newer than mine
(9.27).


mkdir -p ./contrib/sboxes/
./test-groff -M../contrib/sboxes -ms -msboxes -Tpdf ../contrib/sboxes/msboxes.ms > contrib/sboxes/msboxes.pdf


This reminds me that I still owe you some work in this area.


configure:21717: checking pkg-config is at least version 0.9.0
configure:21720: result: yes
configure:21739: checking for UCHARDET
configure:21746: $PKG_CONFIG --exists --print-errors "uchardet >= 0.0.1"
Package uchardet was not found in the pkg-config search path.
Perhaps you should add the directory containing `uchardet.pc'
to the PKG_CONFIG_PATH environment variable
Package 'uchardet', required by 'virtual:world', not found
configure:21749: $? = 1
configure:21763: $PKG_CONFIG --exists --print-errors "uchardet >= 0.0.1"
Package uchardet was not found in the pkg-config search path.
Perhaps you should add the directory containing `uchardet.pc'
to the PKG_CONFIG_PATH environment variable
Package 'uchardet', required by 'virtual:world', not found
configure:21766: $? = 1
configure:21780: result: no
Package 'uchardet', required by 'virtual:world', not found
configure:21802: WARNING: uchardet library not found, preconv might not work properly


This is the uchardet issue you noted.  Is it common for libuchardet to be installed without its pkg-config support in place?  A more traditional Autoconf test might be useful, I admit.

I didn't see anything else that jumped out at me in config.log, but the file is huge.  Please call out anything I missed.

Moving on to the test suite log...


FAIL: tmac/tests/s_PN-works.sh
==============================

FAIL tmac/tests/s_PN-works.sh (exit status: 1)


Can you have a look at the body of the test and try to reproduce it with test-groff in your build?  It's really simple and I can't imagine what might have gone wrong.  This test does not fail on HEAD.


FAIL: src/roff/groff/tests/break_zero-length_output_line_sanely.sh
==================================================================

troff: <standard input>:10: warning [p 0, 0.0i, div 'A', 0.0i]: can't break line
troff: <standard input>:11: warning [p 1, 0.0i]: can't break line
FAIL src/roff/groff/tests/break_zero-length_output_line_sanely.sh (exit status: 1)


This one bears close examination too.  Are you on a branch?  Did you somehow not get commit 69efbe0a (4 September)?

The bad news(?) is that HEAD is green for me, so I'll need your help to chase these down.

G. Branden Robinson <gbranden>
Group administrator
Wed 06 Oct 2021 10:35:06 PM UTC, original submission:  

Before doing a git push Branden suggested a "make check" which resulted in several errors. So I have not done the push I was going to do to support Peter's mom changes.

I attach the log of make which has several issues, plus the test-suite log. The config log also has an issue because it does not recognise that I have libuchardet installed (I suspect because the test invoked will only reliably work on debian type systems, and fails if the library has been built from source, or not from a debian package). Other library checks build a test program which includes the library and tries to compile it, which is more portable.

Deri James <deri>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52063:  Make.log added by deri (30KiB - text/x-log)
file #52064:  config.log added by deri (202KiB - text/x-log)
file #52065:  test-suite.log added by deri (2KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by deri (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-10-28 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
        SummaryBuild errors [tests] non-portable use of echo
    2021-10-09 gbranden StatusNeed Info In Progress
    2021-10-07 gbranden StatusNone Need Info
        Assigned toNone gbranden
    2021-10-06 deri Attached File- Added Make.log, #52063
        Attached File- Added config.log, #52064
        Attached File- Added test-suite.log, #52065

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code