[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
Description: PGP signature
