Arch Linux User Repository

Then it needs to be LicenseRef-custom

Please use spdx license identifier.

I will be orphaning this package due to time constraint. I recommend installing FVWM3, which is the version under active development.

Hi @jose1711, thank you for reporting this. I'll look into it before the end of the week!

Meanwhile: Did you try build this in a clean chroot?

=====

Update 2024-05-12: I can build this package locally, as well as in a clean chroot. You might want to post in the forums to resolve the problem you are facing with iconv.h.

failing to build:

Ficonv.c:36:2: error: #error libiconv in use but included iconv.h not from libiconv
   36 | #error libiconv in use but included iconv.h not from libiconv
      |  ^~~~~
make[2]: *** [Makefile:574: Ficonv.o] Error 1
make[2]: Leaving directory '/data/jose/.cache/paru/clone/fvwm/src/fvwm-2.7.0/libs'
make[1]: *** [Makefile:511: all-recursive] Error 1
make[1]: Leaving directory '/data/jose/.cache/paru/clone/fvwm/src/fvwm-2.7.0'
make: *** [Makefile:452: all] Error 2

Btw, this bug was reported (tersely) by Klaus Ethgen to the FVWM mailing list (fvwm@fvwm.org) on July 30. I even saw that post at the time, but somehow didn't make the connection to the symptoms I was seeing.

If you follow the threads mentioned in Klaus' email you can learn a lot more about its history. It evidently was affecting a few other WMs as well.

@anne The simplest recipe I found for demonstrating the bug is to just to run pinentry-qt from the commandline of an xterm which is running under fvwm, and then give it the "getpin" command, i.e.

$ pinentry-qt
OK Pleased to meet you
getpin

On my system, doing the above pops the QT dialog window, and you can then type into that dialog window, and after you hit <cr> in the dialog window, focus returns to the xterm window, and you have normal keyboard interaction with the xterm. But the mouse is completely dead: No pointer is visible and button presses do nothing. Only way out that I found was via SIGUSR2 or SIGKILL.

@anne What you say makes sense, if the X server had been started while the "old" (upgraded) libX11.so was still in /usr/lib: In that case, just restarting fvwm while leaving the X server (Xorg) running would not be expected to load the "new" (downgraded) libX11.so into the dynamic cache. Restarting Xorg would bring in the new libX11.so. So that makes sense.

Fwiw: This issue was fixed in fvwm3-git about a month ago, in this commit:

https://github.com/fvwmorg/fvwm3/commit/5c17c83df4605d2d97999740cf180af983298896

However, the fix apparently hasn't yet made its way into "plain" fvwm3-1.0.X.

I tried fvwm3-git with my existing fvwm-2.6.9 config setup, and to my delight, it worked right out of the box. No behavioral differences observed (yet!) from fvwm2. The only mod needed was to change the name of the fvwm executable in .xinit to fvwm3 instead of fvwm. So if you're willing to take a shot at doing that, you may end up as I did with a working setup sans this bug and a "free bonus" upgrade to fvwm3 as well.

My FvwmEvent module (that updates icons and other styles) now works too. For now, I've added libx11 to "IgnorePkg" in /etc/pacman.conf, though I hope a real fix will become available eventually.

@grepfor, I'd be curious to know what your "simpler conditions" for reproduction were. Did they involve turning off icons? Because with respect to your question as to why other window managers are unaffected, I believe that most of them use taskbars, not icons that can be placed anywhere on the screen.