Hi Colin, As you noted in 2009, this is no longer a problem with the Debian package.
$ dpkg -L groff | grep /img | xargs test -f && echo | cksum \ | awk '/$2 == 0/ {print "$3 is empty"}' This produces no errors apart from complains from cksum about operating on a couple of directories. > You'll find that this has gone away for now, but that's only because I > switched from doing my maintainer uploads on powerpc to doing them on > i386, and it seems to work properly when I build it on my laptop. On > the i386 build daemon, no dice. On all of the Ubuntu build daemons, no > dice. On the other hand *some* of the Debian build daemons seem to > get it right. I can't reproduce it in a debootstrapped Ubuntu chroot > with just the build-dependencies installed. I have no idea why any of > this is. > > The error message during build is as follows (unfortunately rather > uninformative): > > Calling `pnmcut 108 293 583 52 < /tmp/groff-page-sONKf1 | pnmcrop > -quiet | pnmtopng -background white -transparent white > > img/pic1.png' returned status 256 That sure _looks_ like a wait(2)-encoded exit status which at the shell level would be '-1', indicating a command not found. I can't be sure, but it sure _looks_ like one of the PNM tools must have been unavailable. groff's build system has been converted to Automake since 2009 but I still see no evidence of an Autoconf check for the PNM tools. That seems like an upstream defect. If you'd like, we can reimagine this one as an upstream bug. > With any luck this mail will serve as notes to myself in case I manage > to figure it out later. Any thoughts after having had some time to cogitate? :) Regards, Branden
signature.asc
Description: PGP signature