On Sunday, 22 February 2026 20:59:36 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2026-02-22T19:13:54+0000, Deri wrote: > > On Sunday, 22 February 2026 07:18:59 GMT G. Branden Robinson wrote: > > > At 2026-02-21T13:50:16+0000, Deri wrote: > > > > This is a strange one!! The error occurs if you don't have the > > > > file doc/ gnu.eps (because PSPIC can't find it). doc.am makes it > > > > (from doc/gnu.xpm) but in "out-of-tree" builds it ends up in > > > > build/doc/gnu.eps, and not found. > > > > > > > > The regression was introduced by commit e9da162af80 (Feb 7, 2026), > > > > reverting fixes it. > > > > > > I should point out that this is an incorrect, or at best incomplete, > > > analysis. > > > > I'm interested to know which bits of the analysis was incorrect. > > I did also say "or at best incomplete", which I maintain it was, but I > guess you're contesting that, too. Or maybe not--see below. > > > Given the starting point was:- > > > > GROFF doc/webpage.html > > > > pre-grohtml: fatal error: 'pre-grohtml' exited with status 4; re-run > > with a different output driver to see diagnostic messages > > > > And your initial analysis was to look at pre-grohtml and decide it > > could not happen. > > When a program fails with a fatal error, why would it not make sense to > look first at the complaining program?
[...] > > > So was my analysis that PSPIC was causing the error incorrect? > > It seems so. Your proposed reversion changed nothing in > "tmac/pspic.tmac", and the fix I think to be better[1] doesn't either. i did not propose a reversion, i pointed you to the commit which caused the error to be manifested. if webpage.ms did not use pspic no error would occur - so the statement is patently correct. We both know language is imprecvise, prtic ulry enghl;ish. It is also a martk of intell;igence, thhe ability to derivbe meaning while ignopring noise in the signal, by using context as well as the signal. since you are imtellighent i have decidfed not to correct keyboard mistakes due to hand tremors. > > Was doc.am building gnu.eps in the destdir - is this not true? > > Here's another terminological problem. given i had berwen talking asbout doc/ and build/doc in the orighinal analysis its more likely an intelligenty persdon would assume i wasd talking about $9odoc-srcdirP) and $(doc-builddir0. Its a bit of an athletic stretychb to assumne ity was meant to refer to the install directory. > Literally, no. doc.am (or make(1)) doesn't "build gnu.eps in the > destdir". `DESTDIR`, in a widely adopted Makefile convention that > Automake also employs,[2] refers to _the directory to which files are > installed_. Your term, "destdir", is either undefined or irrelevant to > what happens when you run a groff "make" with its default target (or > ask for "doc/webpage.html" specifically), because neither of those > involve performing _installation_. and yet you manager itg. > We've had much grief over the years with the "doc.am" file arising from > confusion of (1) the source tree, (2) the build tree, and (3) the > installation directory (`DESTDIR`), which can all be distinct. And, if > we follow the path of glibc and binutils as recently pointed out by > Collin Funk, will become distinct for _all_ supported build scenarios. ihopde so. > > Was grohtml being instructed to look in the srcdir - where it should > > not exist in an out-of-tree build - but obviously did when you were > > testing. > > If by this you mean "was `-I $(doc_srcdir)` being passed to `groff > -Thtml`", then yes, but that's an invariant. It was true in 2014, was > true before my commit on 7 February, was true after, and is still true > in my working copy, which has the fix I believe to be "correct".[1] so this was not incorrect. correct but...? i'm dubious. the logical fix would be tyo just replace srcdir with builddir, since there is no need to have both. For in-tree they woiuijld be the same. i don't believe there is anything in the srcdir that groff needs to include. > > Was it working before Feb 7th commit, or is that incorrect. > > Yes. And it was also working _after_ 7 February, for me and for several > of Bruno Haible's builds. Bjarni's the only person who reported a > problem, and unfortunately he has a track record of reporting against > GNU groff problems that affect only his private fork of it.[3] Another correct statyerment then. You were told it only affected out of tree builds on git, not dist tars. So Bruno would not see it. It workesd for you because your source tree was polluted - as i diagnosed. > > > I do not comment on whether my analysis is incomplete, it was > > obviously sufficient to steer you onto the right track to fix the > > problem > > If I still had driving to do after having been "steered", then you are > conceding that it was incomplete. The only driving required was to prepare a commit whicjh fixed the problem i jhad diagnosed for you, and even that causes questions of why you did it that way. mayde its something about drivinmg on the wrong side of the road. > > > - particularly because, at the time, you were claiming you did not > > think it was a problem. > > Where did I say that? Here's what I actually wrote: > >>> I can't account for this. No logic in pre-grohtml explicitly exits > >>> with status 4 under any cirumstances. > >>> > >>> There is a curious wrapper macro and function in > > >>> "src/preproc/html/pushback.cpp": > [snip] > > >>> For one thing, line 103 should be unreachable. > >>> > >>> But I suppose this doesn't account for the problem either, because > >>> the only caller of "localexit" is shown above (the function could > >>> have been declared `static`); the function is only ever passed the > >>> value "1". > >>> > >>> Unless more people can reproduce this, perhaps with compiler options > >>> that less closely resemble Cyril Figgis laying down suppressing > >>> fire,[1] I don't regard your report as gating the groff 1.24.0 > >>> release. > >>> > >>> Regards, > >>> Branden > > https://lists.gnu.org/archive/html/groff/2026-02/msg00085.html > > Where's "I don't think this is a problem" in the foregoing? > > If the existence of bugs in groff that aren't gates for the 1.24.0 > release is equivalent to "not being a problem", then Savannah lists 418 > tickets I can close right now. > > And as it happened, "more people" _could_ reproduce this--like you, and > like me, once "steered" by you. So the sufficient condition for gating > the 1.24.0 release was met, per criteria I established before you wrote > your first email to this list on the matter. > > > You have added to my analysis the reasons why you made a mistake when > > changing doc.am to build webpage.html, > > Again, let's be precise with language. My change didn't alter "doc.am" > _to_ build "webpage.html", but _how_ that Automake file built > "webpage.html". The "how" made most of the difference; a feature of Git > that I didn't understand involving its "status" subcommand (that I now > think I've figured out how to incant as I desire[4]) made the rest. > > > maybe that's why you considered my analysis was incomplete. > > I think, as shown above, there are multiple premises each sufficient to > reach that conclusion. > > > I would point out that your eventual fix was to add -I $(doc_builddir) > > to the make rule for webpage.html, > > Right. > > > and the part of my analysis you did not bother to quote when you > > accused my analysis of being incorrect:- > > > > "Exactly the problem, gnu.eps is created in $(doc_builddir) but > > troff's -I looks in $(doc_srcdir). Of course, in-tree, these are both > > the same, so it works." > > I found this confusing (and still do). "but troff's -I looks in > $(doc_srcdir)" is, as I noted above, an invariant across the entire > history of the "doc.am" file, even with respect to a commit I haven't > pushed yet. The history of doc.am has no bearing on what is needed now to maker it work properly now. > So saying that a thing I _don't_ need to change is "exactly the problem" > when I need to be changing some _other_ thing--even a lexically adjacent > thing--was not, at the time, illuminating to me. dignal noise inyelligence. > > I know I'm just a quadriplegic spastic so can't possibly operate in > > the higher realms of intellectual thought, but give me a little credit > > if I strike it lucky. (Or is it luck). :-) > > I think neglecting to precisely use language where doing so is necessary > to reach mutual understanding accounts for a much greater proportion of > our failures of communication than random variables or CNS differences. If you always start from tyhe premise that you are alwaya right, and only communication using your version of "precise language" has a chance of changing your mind, it makes it very difficult for the rest of us. Personally I start with the premise the other person probably has a valid point, even if, at first read, what they are saying appears wrong, I then synthesize in what circumstance their point would make sense. This is how I got from your "Can't reproduce" to you must have a copy of gnu.eps in your source tree, since then your continued denial of a problem made sense. > > > And the problem that _should_ have been revealed was masked on my > > > system because of the lingering (and all but hidden by ".gitignore") > > > "doc/gnu.eps" file in my _source_ directory, which was (roughly) > > > your analysis. But that was only one piece of the puzzle. > > > > Part of it, but only in so far as explaining why you kept claiming it > > was not a problem. > > "Kept claiming". First, you invented me saying "there wasn't a problem" > once. Now, it's multiple times. Okay, I just identified an additional > first-order factor contributing to our failures of communication. Try > sticking to the words I actually write. Here we go:- "I don't regard your report as gating the groff 1.24.0 release." <i.e. no prob - since normally a build failure would gate> "Well then it's _extra_ strange, because I _can't_ reproduce it. (And didn't on 7 February, because I would not have pushed if I'd been able to see this defect, which I certainly should have because I do an out of tree build 3-4 times[1] immediately before pushing.)" <i.e. no prob - the report is false> "Can't reproduce." <i.e. no problem> "For me, this is working as planned and intended." <i.e. no prob> "> If you are not seeing the error please check you have not got a rogue > doc/ gnu.eps in the source doc/ directory. I don't. See my "find" command above." <i.e. Deri's wrong - there is no problem here> "Deri's hypothesis did not bear out for me. I didn't need "gnu.eps" in my build tree for "webpage.html" to be successfully generated." <i.e. Deri's wrong - there is no problem here> "> Which actually proves I am correct, you do have a "rogue" copy in the > source directory. Possibly left over from an in-tree build, another > good reason for dropping in-tree builds. This much is true. "doc/gnu.eps" is not tracked in git:" <finally, there is aproblem - which is causing me not to see the reported build problem> All from:- https://lists.gnu.org/archive/html/groff/2026-02/msg00085.html https://lists.gnu.org/archive/html/groff/2026-02/msg00088.html https://lists.gnu.org/archive/html/groff/2026-02/msg00093.html https://lists.gnu.org/archive/html/groff/2026-02/msg00105.html In terms of denying there was a problem, you don't have to say the actual words, justr demonstrate you believe no problem uxists. > > The real analysis was that PSPIC was the culprit, > > Completely disagree. What about the file "tmac/pspic.tmac", which > defines the `PSPIC` macro, would you change to resolve the defect Bjarni > reported? Alternatively, what would change in "webpage.ms", which > contains the `PSPIC` macro call that ultimately failed? remove .pspic from webpage.ms and the error goes. so if you want to knoiw what caused the exit 4 you can say the presence of pspic in webpage.ms. > The culprit was a long-standing latent bug involving insufficient > preparation of a groff(1) command line in a Makefile.[5] Yes i pointyed you to doc.am. > > that gnu.eps was being created in the destdir but the make rule was > > directing groff to the srcdir (which is why I predicted you had a > > "rogue" copy in your srcdir), > > That was a good catch. Unfortunately my lack of mastery of "git status" > concealed the file from me for a while longer. > > > and even pointed you at the commit to examine so that you could look > > at the changes which caused the issue. > > Not _caused_ the issue. _Exposed the latent issue_. lets be a bit more accurate here, the latent issue was exposed through making chabges without fully understanding why the previous code was working, and adding the new code caused it to no longer work. > > The analysis you added was just why the previous version worked, I did > > not think that was necessary to fix the problem. > > I'm not excited to play the "experienced software engineer" card on you, > but it _frequently_ happens in the field that when a bug has undergone a > root-cause analysis, its longevity (or persistence) is discovered to be > much greater than is consistent with the timing of report(s) that led to > its investigation. People wind up saying things like... > > "Wait a minute--how did this _ever_ work?" But we know it did work, soi the analysis is faultty if you can't answer the question. [...] > > > For completeness you should mention that the -I flags to groff are > > passed to pre-grohtml which uses them when it calls groff -Tps -I ... > > so it is grops which actually locates and uses the gnu.eps file. > > That's fair, to a point. My emails are long enough, and digressing into > the minutia of PostScript resource inclusion seemed beside the point. > It doesn't seem to matter whether an EPS included by the `PSPIC` macro > is somehow encoded for inclusion in GNU troff's "grout" output, or > simply referred to on the file system via a device extension command. > (The latter is what is actually the case.) > > > The text in troff.1 is a little misleading since it assigns the -I > > directory search for the \X'ps: import ...' to troff, but troff does > > nothing with this, it is the fact -I is passed to grops which allows > > the import to happen. This is different from psbb, so and soquiet, but > > occurs in the same sentence. > > That's a reasonable point. Want to pitch a recast? :) This is a joke;- ‘-Idir’ This option may be used to specify a directory to search for files. It is passed to the following programs: • gsoelim (see gsoelim for more details); it also implies groff’s -s option. • gtroff; it is used to search files named in the psbb and so requests. • grops; it is used to search files named in the ‘\X’ps: import’ and ‘\X’ps: file’ escapes. The current directory is always searched first. This option may be specified more than once; the directories are searched in the order specified. No direc- tory search is performed for files specified using an absolute path. (groff.pdf circa 1.22.4) > > First, I never suggested you should revert, just that reverting fixed > > the problem, > > I wouldn't say that much, especially now that the root cause is known. > > Reverting the change _re-concealed a latent problem_. > > It's always good to have some small thing one can toggle to make a bug > manifest and then go away again, but that doesn't mean the thing you're > toggling _is_ the problem. Exactly, I identified the toggle for you, not suggesting revert was needed. > A sketch of next steps from there is: > > 1. reduce the size of the toggled change to the minimum syntactical > alternation that changes the behavior; and > 2. understand why that change alters the behavior. > > If the toggling change alters observable behavior _but shouldn't_, you > know that you haven't yet found the root cause of the problem. i believe this is the minimum change which removes the problem. diff --git a/doc/doc.am b/doc/doc.am index d5a0c9eaf..191f5289e 100644 --- a/doc/doc.am +++ b/doc/doc.am @@ -416,7 +416,7 @@ doc/webpage.html: $(DOC_GNU_EPS) tmac/www.tmac tbl doc/webpage.html: $(doc_srcdir)/groff.css doc/webpage.html: $(doc_srcdir)/webpage.ms $(TMAC_PACKAGE_MS) $(GROFF_V)$(MKDIR_P) $(doc_builddir) \ - && $(DOC_GROFF) -t -I $(doc_srcdir) -P-jdoc/webpage -P-nrb \ + && $(DOC_GROFF) -t -I $(doc_builddir) -P-jdoc/webpage -P-nrb \ -P-Iwebpage -P-Ddoc/img -Thtml -ms $(doc_srcdir)/webpage.ms \ > [email protected] \ && mv [email protected] $@ > David Agans explores this in his humbly titled 2002 book, _Debugging_. > > > thus giving you a big fat clue where the problem was located. > > Right. But not, as noted, a "complete analysis". > > > Now, what I mean by a regression. > > > > A change with the unintended consequence of altering previous > > behaviour, usually in some negative way. > > > > With this definition, I class this as a regression (unless your > > intention was to break the build!!). I have no problem with changes to > > the build process, but if the change causes stuff which used to work > > to no longer work. Intention is derived from the stated purpose of a > > commit, its no good claiming a different intention post commit when a > > problem is discovered. > > So...you think commit e9da162af8 should still be reverted? A regression does not always require a revert, duh! it requires the mistake which caused the regression to be fixed. > > > If you meant to suggest that [I] made the change in commit > > > e9da162af8 with insufficient diligence as to its risks or > > > consequences, then I ask you to think again. Again, see the commit > > > log message. > > > > Not at all, I'm suggesting it was unintentional, a mistake due to > > inadequate analysis of why the previous code was working, > > The previous code shouldn't _ever_ have worked, and that it did (for me) > was, as you correctly diagnosed, because there was leftover crap in my > working copy that should not have been there and that my habits of Git > usage did not reveal to me. > > How did the crap get there in the first place? I don't know for sure, > and maybe can't, but I'd put my money on doc/doc.am being somewhat > haphazardly assembled over the years. See also Ingo Schwarze's lengthy > screed in the "NEWS" file accompanying commit 3805d2a0e4, 12 April 2022. Very good, your synthesizing what may have caused the problem. However I'll give you two facts:- After a make clean or make distclean:- [derij@pip build (master)]$ l doc gnu.eps groff.dvi.t2d/ groff.html.node/ groff.info-1 groff.info-3 groff.pdf.t2p/ groff.txt groff.dvi groff.html groff.info groff.info-2 groff.pdf groff.texi img/ notice gnu.eps (among a surprising number of other files) is still present. Doing an in-tree build will put gnu.eps into your source doc directory and I bet a make clean does not touch it. meaning it will live there until manually removed. Which is my synthesis of how you got the rogue file. > > and that makes it a regression in my universe. > > That definition is unsatisfactory to me. Did _the build_ regress in > some way? Yes. Was _that commit_ of itself a regression? No. Did > that commit expose a latent bug? Yes. Did that bug warrant > investigation upon being reproduced by others? HELL yes. This is why I don't link reversion to regression. a regression can be fiuxzeed by a further commuit, as in this case. occasionally a regression may require a complete reversion but only when the intention behind a particular change is proved to be bonkers. > By affixing the term "regression" to a commit that _doesn't constitute > the introduction of a defect_, we distract our attention from the > necessary work of locating where a defect truly is. That distraction in > turn neglects to exercise our ability to recognize defects. It is perfectly fair to label a commit as a regression, iuf that is the poinmnt from which regressed behaviouris obdservedf. it may not be the cause of the defect but it bis empirically the point from when the regression is observed. > In NetHack parlance, indulging distraction abuses wisdom. > > Distraction is fine--if all you want is to move fast and break stuff. > > Regards, > Branden > > [1] https://lists.gnu.org/archive/html/groff/2026-02/msg00110.html > [2] > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/Makefile.am?h=1.24.0. > rc4#n268 > > [3] > https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=br > owse&set=custom&msort=0&report_id=225&advsrch=0&bug_id=&submitted_by=0&statu > s_id=3&severity=0&category_id=0&assigned_to=0&summary=bjarnigroff&bug_group_ > id=0&resolution_id=0&plan_release_id=0&history_search=0&history_field=0&hist > ory_event=modified&history_date_dayfd=22&history_date_monthfd=2&history_date > _yearfd=2026&max_rows=50&spamscore=5&boxoptionwanted=1#options > > [4] I wanted "git status -uall" (strictly: combined with a filter), not > "git status -uno". > > [5] Specifically, the latent bug crept in in commit c81db845da, 6 April > 2022, by me, over a year before the groff 1.23.0 release > > The commit log is revealing: > > (doc/webpage.html): There is no need to look in `doc_builddir` for > file inclusions, since that is the current working directory when > "webpage.ms" is processed. > > ...which was true. I surrendered a hostage to fortune by not just > scotching the careless "cd" business at the time. I had less > courage back then. (Possibly doing so was infeasible at the time, > demanding other feature development that took place later; I don't > know, and have no plans to find out.) > > Applying your definitions, I introduced no defect here, latent or > otherwise, because no regression occurred consequent to that commit. > Many people did groff builds between 7 April 2022 and 7 February > 2026 without the build failing as Bjarni observed. > > Per my _own_ definitions, I made a mistake then nevertheless.
