Hi Stephen, At 2026-11-12T22:56:03-0800, Stephen Gildea wrote: > > When you get time, I'm curious to know details of the build failure > > you're seeing. > > This was on Ubuntu 24.04 on an amd64 laptop. I don't think it > was so much that I have an obscure system as that I had an old > compiler that was missing some modern include file. > If you want details, I'm happy to try again and send you logs.
Hmm, not obscure at all, but I know of only other Ubuntu-related groff
build failure. Nelson H. F. Beebe reported it to me privately this
week. I'm awaiting his permission to quote him on that and several
other issues in a reply that loops in this list, but I don't think
there's any harm in quoting the groff test suite's own output.
% cat test-hdtbl.sh.trs
:test-result: FAIL
:global-test-result: FAIL
:recheck: yes
:copy-in-global-log: yes
% cat test-hdtbl.sh.log
checking /local/build/cc/groff-1.25.0/contrib/hdtbl/examples/fonts_n.ps
for 46 pages
...FAILED; found 0 page(s), expected 46
checking /local/build/cc/groff-1.25.0/contrib/hdtbl/examples/fonts_x.ps
for 46 pages
...FAILED; found 0 page(s), expected 46
FAIL contrib/hdtbl/examples/test-hdtbl.sh (exit status: 1)
If that's what you're seeing, then (1) yes, there has been another
report, but (2) I have no idea what's causing this. Some kind of font
embedding problem, possibly--replying with the "configuration summary"
spit out by the "configure" script of the corresponding build might
help. Here's what that looks like.
GNU roff version 1.25.0.70-23101 configuration summary
----------------------------------------------------------------------
installation directory prefix : /home/branden/groff-HEAD
C++ compiler and options : g++ -g -O2
C compiler and options : gcc -g -O2
Perl interpreter version : 5.36.0
Ghostscript command : gs
URW fonts directory : /usr/share/fonts/type1/urw-base35/
gropdf service level : full
X11 support : enabled
X11 app defaults directory :
/home/branden/groff-HEAD/lib/X11/app-defaults
default paper format : letter
'groff -l' uses print spooler : lpr
preconv can use uchardet library : yes
can build groff.{info,html,txt} : yes
can build groff.{dvi,pdf} : yes
----------------------------------------------------------------------
Your details will differ.
> > You don't have to edit the man page sources, and I would not advise
> > you to hurriedly do so. You could alter your test.
>
> I've released a new version of xlbiff to Debian with both
> changes: I've taken the style advice where it made sense in
> the manual pages, and I've altered my test to not fail where I
> choose to ignore groff's style advice.
I checked out what you've done and I see your reason for it. I may have
some good news for you later in this message.
> > [-ww]: I gave this quite a bit of thought.
>
> Yes, I can see the problem with "warn all", and I appreciate both the
> effort you have put into making useful warning categories for us
> authors and the time you took to explain your thinking here.
My pleasure! I have my own strange ideas regarding what "good UX" is.
> One way to control the proliferation of meaningless "all" categories
> might be to use version-correlated names: "-w w1.24" could mean
> "w as known to groff 1.24", "-w w1.25" could mean "w as known to groff
> 1.25", etc.
That would be easy to implement if all that happened with our warnings
was essentially tacking them onto a list of monotonically increasing
length. For instance, the task would be straightforward if they were
contained in a vector of structs, something like this.
static const struct troff_warning troff_warnings[] = {
{ 1, WARN_CHAR, "cannot format input character code" },
{ 2, WARN_CHAR, "skipping hyphenation exception word containing
non-character" },
/* many more */
// groff 1.24
{ 101, WARN_STYLE, "right brace escape sequence is nilpotent" },
// groff 1.25
{ 102, WARN_STYLE, "end of sentence detected before end of text line" }
};
...but in fact GNU troff's source code organizes its warnings nothing
like this.
Warnings change categories and get withdrawn, too. Whole categories
disappear as well. Here are some examples from our NEWS file, not
restricted to the most recent release (1.25.0).
NEWS:
* The formatter now enables the "delim", "syntax", and "escape" warning
categories by default.
* The formatter supports a new warning category, "style". It is used
to diagnose input that is non-idiomatic or likely to produce an
unexpected result (or none at all), but is not invalid.
* When the `substring` request is given two index arguments whose
magnitudes both exceed the operand string, macro, or diversion's
length, it now ignores the request (and issues a warning in category
"range"), leaving the operand (first request argument) unchanged
instead of emptying it.
* When the `ti` request is given no arguments, the formatter now
cancels any pending temporary indentation. (Formerly, it did nothing
in any troff, except, in GNU troff, issuing a warning in category
"missing".)
* GNU troff now implements saturating rather than wrapping integer
arithmetic. Where before overflow would cause an error diagnostic
and abort evaluation of the expression, the formatter now emits a
warning diagnostic in the "range" category and continues evaluation.
* The "number" warning category has been withdrawn. The diagnostic
that formerly used it has been promoted to an error.
* The "el" warning category has been withdrawn. If enabled (which it
was not by default), the formatter would emit a diagnostic if it
inferred an imbalance between `ie` and `el` requests. Unfortunately
its technique wasn't reliable and sometimes spuriously issued these
warnings, and making it perfectly reliable did not look tractable.
We recommend using brace escape sequences `\{` and `\}` to ensure
that your control flow structures remain maintainable.
* The "right-brace" warning category has been withdrawn. If enabled
(which it was not by default), the formatter would emit a diagnostic
in exactly one circumstance: when a numeric expression was expected
(as, for instance, the second argument to an `nr` request) but a
right brace escape sequence `\}` was encountered instead. This
diagnostic still issues, but it is now an error.
Implementing a simulator within GNU troff to reproduce the warning
behavior of historical versions of GNU troff would be an enormous amount
of work, including, as you may have guessed, a parallel arithmetic
expression evaluator that permits integer overflow.
> > As you might have noticed, GNU troff's warnings now identify the
> > warning category they belong to,
>
> I did notice, and this is a lovely feature. I'm a big fan of
> diagnostics packed with helpful info for debugging.
That's been a major objective of mine since I started working on GNU
troff's source code in earnest in 2020.
Here's the good news I promised.
I noticed that you wanted the style warnings off because you had a block
of verbatim text that you share among multiple files, and one instance
of it appears in the man page. I won't scold you about a DRY violation
because that wouldn't solve the problem; even if you soelim(1)ed this
specimen of text into your man page at build time--part of generating
xlbiff.1 from xlbiff.1.in, for example--that wouldn't suppress the
warning.
But an item pretty high on my priority list for 1.26 is extension of the
syntax of the `warn` request to invite use by humans instead of only
machines that are comfortable speaking in bit vectors encoded as decimal
integers.
I invite you to read over <https://savannah.gnu.org/bugs/?68242> and let
us know what you think.
The predicted result is that you could do something like the following
in your man page, at no detriment to portability.[1]
diff --git a/xlbiff.man.in b/xlbiff.man.in
index 2412668..8e89760 100644
--- a/xlbiff.man.in
+++ b/xlbiff.man.in
@@ -37,11 +37,15 @@ message content.
.B xlbiff
can also beep or play a custom sound.
.PP
+.\" Temporarily shut off style warnings on groff 1.26 and later.
+.nr saved-warnings \n[.warn]
+.if \n(.g&\n(.x=1&\n(.y>25 .warn -style
Clicking the left mouse button anywhere in the window causes it
to vanish. It will also vanish if the mailbox becomes empty.
.B xlbiff
stays out of your way when there is no new mail and pops
up only when something requests your attention.
+.warn \n[saved-warnings]
.PP
Features:
.PD 0
Regards,
Branden
[1] Why not guard the requests that save and restore the warning vector?
Because they are (on net) idempotent on older groffs and provoke no
diagnostics from DWB 3.3, Heirloom Doctoools, Solaris 10, Plan 9
from User Space troff, nor from mandoc(1). I checked.
signature.asc
Description: PGP signature
