Package Details: fvwm 2.7.0-5

Git Clone URL: https://aur.archlinux.org/fvwm.git (read-only, click to copy)
Package Base: fvwm
Description: Fvwm2 - a virtual window manager. Only gets serious bugfixes. New version is Fvwm3.
Upstream URL: http://www.fvwm.org
Licenses: custom, GPL-2.0-only
Submitter: arojas
Maintainer: lquidfire
Last Packager: lquidfire
Votes: 11
Popularity: 0.000043
First Submitted: 2021-05-08 08:42 (UTC)
Last Updated: 2024-05-13 07:11 (UTC)

Latest Comments

1 2 Next › Last »

lquidfire commented on 2024-05-08 07:26 (UTC) (edited on 2024-05-12 12:52 (UTC) by lquidfire)

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.

jose1711 commented on 2024-05-06 22:05 (UTC)

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

grepfor commented on 2022-09-06 21:20 (UTC)

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.

grepfor commented on 2022-09-06 21:10 (UTC)

@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.

grepfor commented on 2022-09-06 20:49 (UTC) (edited on 2022-09-06 20:59 (UTC) by grepfor)

@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.

anne commented on 2022-09-06 20:24 (UTC)

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.

anne commented on 2022-09-06 20:10 (UTC)

@grepfor Downgrading libx11 and then restarting only fvwm didn't work, but restarting Xorg seems to fix the problem in fvwm. At least, I removed "Style * !Icon", got icons, and the window manager is still running normally. Next, I will try re-enabling my dynamic icon controls in my homegrown FvwmEvent module.

anne commented on 2022-09-06 19:23 (UTC)

@bidulock Sorry about the delay. I've switched to fvwm-git (2.6.9.r8.g527ea301-1) , and it has the same problem. I'm going to switch back, and then try the libx11 downgrade.

grepfor commented on 2022-09-04 22:36 (UTC)

@anne Seeing similar hang symptoms on my setup, running 2.6.9-3, but was able to reproduce under simpler conditions than the ones you describe. Eventually bisected it to this update:

 libx11-1.8.1-2 -> libx11-1.8.1-3

which occurred around July 6. So that would be consistent with your observation that it broke for you after your July 15 update.

Simply downgrading libX11 to 1.8.1-2 fixed it for me, suggest trying that. (Downgrading should be harmless in other respects.)

However, it still leaves open the interesting question of why that seemingly-benign libx11 upgrade interacted badly with fvwm 2.6.9-3, yet nobody else is reporting issues with other window managers. [FYI: The libx11 upgrade simply removed the --disable-thread-safety-constructor option from the PKGBUILD].

If you do try the libx11 downgrade as described above, please post a comment here with the results, so I can file a more informative git issue on it. Thanks!

FYI: I have not tried fvwm-git.

bidulock commented on 2022-08-08 01:36 (UTC)

@anne there have been some recent bugfix commits, did you try fvwm-git from the AUR to see if it has the same problem?

1 2 Next › Last »