Thanks to Robert, Nate, Tadziu, Oliver, and Dale for the replies--I asked for help, and got it!
I'll cover the good news first. Any system experiencing this problem can patch in a workaround (that I have already committed to groff Git's master branch) that requires only the editing of a text file. Here it is: https://git.savannah.gnu.org/cgit/groff.git/diff/src/devices/xditview/GXditview.ad?id=99a550d1e770d66894922d0e2ca7e6695435c624 This won't fix the menu, but it does make available the printing dialog, which is the only item in the menu that didn't have a keyboard accelerator. The accelerator is the "p" key with any modifier pressed: Shift, Control, Alt, or Meta. (An unmodified "p" retreats the page view, like PageUp.) To see what the other accelerators are, consult the gxditview(1) man page. At 2023-07-27T11:54:13-0400, Robert Goulding wrote: > I tried to do this, but gxditview was not on my system (Crostini on a > Chromebook = Debian 11 (bullseye). > > So I compiled again from source, [...] At 2023-07-27T12:46:29-0400, Robert Goulding wrote: > OK, I managed to compile gxditview. Left-clicking brings up the menu; > none of the items are selectable. Okay, so we see the bug on Debian 11 (bullseye), now termed "old-old-stable". According to the Debian Package Tracking System (PTS),[1] that release had the following X support libraries relevant to gxditview. libx11 2:1.6.7-1+deb10u2 libxaw 2:1.0.13-1 libxmu 2:1.1.2-2 libxt 1:1.1.5-1 At 2023-07-27T12:04:31-0500, Nate Bargmann wrote: > I can confirm the menu is not responsive on Debian Bullseye but does > work properly on Bookworm, at least I can select the Open and Quit > items and get the expected result (Groff 1.22.4 on both). That's a good enough test. So, bullseye bad, bookworm good. Here are the bookworm versions (oldstable): libx11 2:1.7.2-1 (security update: 2:1.7.2-1+deb11u1) libxaw 2:1.0.13-1.1 libxmu 2:1.1.2-2 libxt 1:1.2.0-1 libxmu stayed the same so we can probably rule that library out. > The menu also works similarly on an up-to-date Arch Linux system > (Groff 1.23). "Up-to-date" is a moving target, but as of right now that appears to mean: libx11 1.8.6-1 libxaw 1.0.15-1 libxmu 1.1.4-1 libxt 1.3.0-1 All I can infer from this is that it seems likely that the X libraries had this gxditview-affecting problem for a while and then fixed it. Hrm. I see a problem. repology.org and the Debian Package Tracker seem to have different ideas of which suite is which. That's not good. Nevertheless, as we'll see below, this source of noise in the data need not foreclose an informed guess at the problem. At 2023-07-27T19:05:20+0200, Tadziu Hoffmann wrote: > gxditview from 1.22.4 freshly compiled on Opensuse 15.4 works > (all menu items). [...] > Also, this is straight X11, no Wayland involved. Great news. If you build groff 1.23.0 there, you'll be moving faster than official Opensuse. ;-) Assuming "openSUSE Leap 15.4" (repology.org's name for it) is the same thing, I see the following package versions. libx11 1.6.5-? libxaw 1.0.13-? libxmu 1.1.2-? libxt 1.1.5-? This is _really_ close to Debian bookworm (or whatever had libx11 1.7.2 in stable, this being the only difference among the 4 libraries)! Apart from vendor versioning (which repology.org doesn't put in front of you), the only difference is in libX11, which is fundamental enough to do the trick. Hypothetically, libX11 grew a bug after 1.6.5 but before 1.6.7 was tagged. At 2023-07-27T20:26:37+0200, Oliver Corff wrote: > I tried gxditview on a Linux Fedora 38 installation (out-of-the-box, > groff 1.22.4), everything works as expected. Left click into canvas, > menu opens, I can select items and they behave as expected. [...] > I tried a second Fedora 38 box with vanilla installation, and that > shows the problem you described. > > For now, I cannot say where the problems are but I ran into library > problems with another application, too. Skewed field updates of package versions seem a likely explanation for two different Fedora 38 boxes--unless both are administered rigorously by the same person or team. libX11 is never done getting caught with security problems, so I'm starting to guess that what happened was that a CVE came out, and an initial fix had undesired side effects. But let's eyeball Fedora 38's collection of packages. release updates libx11 1.8.4-? 1.8.6-? libxaw 1.0.14-? n/a libxmu 1.1.4-? n/a libxt 1.2.1-? n/a This most closely resembles Nate's up-to-date Arch Linux system. Makes sense since a web search tells me Fedora 38 is the current release. There _does_ seem to have been a security update to Fedora 38's libX11 last month. https://lwn.net/Articles/935144/ You might be well placed to see if this is a difference between your two Fedora 38 boxes. At 2023-07-27T22:29:23-0700, Dale Snell wrote: > I tried this on a Fedora f33 w/XFCE (yes, I know it's old; I'm lazy) > and groff 1.22.4. I can start gxditroff with no trouble, but the menu > is completely unresponsive. Okay. Let's get Fedora 33 into the mix. release updates libx11 1.6.12-? 1.7.2-? libxaw 1.0.13-? n/a libxmu 1.1.3-? n/a libxt 1.2.0-? n/a Well, this is the same version of libX11 as security-updated Debian bookworm (according to the PTS) or to Debian bullseye (according to repology.org), and has the same problem. I find myself pretty frustrated with repology's and the Debian PTS's clashing views of what the suites are, and also with the Debian Release Team's embrace of release code names starting with "b" for _three releases in a row_, which is a pretty vicious trick to play on my poor old brain with its shallow mnemonic hash buckets. Nevertheless, the pace of X development is sufficiently glacial that I can reach a hypothesis: libX11 went wrong for a while, and then got fixed. For now I will leave as an exercise for the reader a Git bisection of libX11, with gxditview rebuilt against it and its pop-up menu tested at each iteration. Here's where to start.[2] Thanks to everybody who replied for supplying enough data points for me to rule out a groff bug. Other frustrations aside, knowing a problem isn't groff's fault keeps my blood pressure where the doctor wants it. Regards, Branden [1] https://tracker.debian.org/pkg/$PKG [2] https://gitlab.freedesktop.org/xorg/lib/libx11/
signature.asc
Description: PGP signature