Re: groff-1.23.0.5077-7dcc8 on NetBSD 11.0

"G. Branden Robinson" <[email protected]> Mon, 19 Jan 2026 19:01:29 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260120010129.wsjlcqnh5lb2n2nh@illithid>
[CCing groff@gnu to keep its developers in the loop]

At 2026-01-19T17:43:44-0700, Nelson H. F. Beebe wrote:
> The build of groff-1.23.0.5077-7dcc8 on NetBSD 11.0 stopped like this:
> 
> 	BuildFoundries: notice: copied grops font EURO
> 	BuildFoundries: notice: 
> 	The path(s) used for searching:
> 	@urwfontsdir@:%rom%Resource/Init:%rom%lib:/usr/pkg/share/ghostscript/10.06.0/Resource/Init:/usr/pkg/share/ghostscript/10.06.0/lib:/usr/pkg/share/ghostscript/10.06.0/Resource/Font:/usr/pkg/share/ghostscript/fonts:/usr/pkg/share/fonts/default/ghostscript:/usr/pkg/share/fonts/default/Type1:/usr/pkg/share/fonts/default/TrueType:/usr/lib/DPS/outline/base:/usr/openwin/lib/X11/fonts/Type1:/usr/openwin/lib/X11/fonts/TrueType:/usr/pkg/share/cups/fonts:/usr/share/fonts/type1/gsfonts:/usr/share/fonts/default/Type1:/usr/share/fonts/default/Type1/adobestd35:/usr/share/fonts/type1/urw-base35:/usr/share/fonts/urw-base35:/usr/share/ghostscript/Resource/Font:/opt/local/share/fonts/urw-fonts:/usr/local/share/fonts/ghostscript:/local/build/cc/groff-1.23.0.5077-7dcc8/font/devpdf:/local/build/cc/groff-1.23.0.5077-7dcc8/font/devpdf
> 
> 	make: *** [Makefile:19938: font/devpdf/download] Error 2

Deri James, our PDF guru and author of gropdf(1) and the BuildFoundries
script, I think will want to note this.

Versions of Ghostscript that use "%rom%" seem much more popular than
either of us expected, and this causes problems by hiding resource
availablility.  gropdf(1) expects to be able to embed fonts in PDF
documents, and there's no standard mechanism for extracting them from
the "%rom%" of a hardware device.  That's on purpose to prevent "font
piracy", a grave concern in 1980s and 1990s.   As with many instances of
economic rentierism, we're still paying the price today for techniques
of revenue extraction that their promulgators no longer exercise.

✊☭ ✊

> 	  GROFF    contrib/sboxes/msboxes.pdf
> 	gropdf: fatal error: failed to open 'download' file
> 	make[2]: [Makefile:19182: contrib/sboxes/msboxes.pdf] Error 12 (ignored)
> 
> Perhaps another missing font problem?

Indirectly.  If BuildFoundries is sufficiently stymied in its mission,
the build cannot generate a "download" file for use by gropdf(1) or
grops(1).

Time to decode that exit status!

groff(1):
Exit status
     groff exits successfully (with status 0) if either of the options
     -h or --help is specified, status 2 if the program cannot interpret
     its command‐line arguments, and status 1 if it encounters an error
     during operation.  Otherwise, groff runs a pipeline to process its
     input; if all commands within the pipeline exit successfully, groff
     does likewise.  If not, groff’s exit status encodes a summary of
     problems encountered, setting bit 2 if a command exited with a
     failure status, bit 3 if a command was terminated with a signal,
     and bit 4 if a command could not be executed.  (Thus, if all three
     misfortunes befall one’s pipeline, groff exits with status 2^2 +
     2^3 + 2^4 = 4+8+16 = 28.)  To troubleshoot pipeline problems, re‐
     run the groff command with the -V option and break the reported
     pipeline down into separate stages, inspecting the exit status of,
     and diagnostic messages emitted by, each command.

12 = 8+4 = 2^3 + 2^2 => Somebody exited nonzero _and_ somebody (else?)
got killed by a signal.

My hypothesis is that gropdf exited nonzero on purpose due to that
"fatal error", and troff(1) got signalled with SIGPIPE because the pipe
it was writing to closed when gropdf offed itself.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)