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

Attachment: signature.asc
Description: PGP signature

Reply via email to