[bug #61302] Build errors

[Deri James]

Follow-up Comment #2, bug #61302 (project groff):


       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?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61302>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/