Bug#564943: potential fix in cvs
Andrea and Marco, thanks for your efforts! On Sat, Oct 23 2010 at 19:23, Andrea Bolognani wrote: Marco has released 0.9.27, and I have updated the Debian packaging. Dmitry and Hannes, please test this release and let me know if it fixes the bug for you. Tried the package from http://alioth.debian.org/~ab-guest/ The bug did not go away. sleep still helps. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Mon, Apr 26 2010 at 02:30, Andrea Bolognani wrote: So, as I mentioned above, I have two X servers from stable with two different drivers and one scrotwm from testing, which connects to X server via tcp socket. So the version of Xlib (or related libraries) used by the X server is differen than the one loaded by scrotwm. As far as I understand, there is no Xlib version corresponding to a particular version of X server, they are not synchronized. By the way, if we are right and the bug is some way related to X protocol implementation, the solution may either help in migrating to xcb -- another X client library upstream developers are going to use in future releases. With “same thing”, you mean “the bug goes away”, right? Sorry.. No, the only way I got rid of the bug is starting scrotwm from a terminal with DISPLAY variable properly set. However, if we manage to make certain you’re hitting the bug only because you have an arguably not so common setup, and the same turns out to be true for Hannes, I will consider downgrading the severity of this bug. I disagree that my setup is not so common -- tcp socket is actually the second (of 2) way to connect to X server. And -- please don't forget about it -- scrotwm works well with all of my mixed library versions when started from another terminal. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Mon, Apr 26 2010 at 21:53, Dmitry Derjavin wrote: And -- please don't forget about it -- scrotwm works well with all of my mixed library versions when started from another terminal. We have a workaround! Adding 'sleep 1' before scrotwm invocation in .xsession script helps. It looks like a race condition. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Mon, Apr 19 2010 at 14:57, Andrea Bolognani wrote: It seems like Xorg is undergoing a lot of updates and changes, lately, so I wonder — like Hannes did — if the bug wasn’t triggered by some bug in the underlying infrastructure, with video drivers being the most likely cause due to KMS and related changes. I think it's not video drivers, because I tried to run scrotwm with two X servers -- one on Nvidia and another on ATI with the same result. In both cases it was 1:7.3+20 from stable. Scrotwm itself was installed on both stable and testing. And, by the way, 0.9.23 still has the bug. Do both of you still get the bug? Yes. Hannes, did you try to start scrotwm from an X terminal? If either of you does, I’ll get in touch with the upstream maintainer. Yes, please do it. I have no more ideas. Thanks! -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Sat, Apr 24 2010 at 15:23, Andrea Bolognani wrote: I think it's not video drivers, because I tried to run scrotwm with two X servers -- one on Nvidia and another on ATI with the same result. In both cases it was 1:7.3+20 from stable. Scrotwm itself was installed on both stable and testing. So, if I understand correctly, you have a mixed stable/testing setup, with Xorg from stable and scrotwm from testing Yes. and another one which is pure stable, except from scrotwm, which is obviously not available from stable? Yes, it is pure stable, but it acts as an X server only. All the clients, including window managers are installed on the first box, which is mixed stable/testing. So, as I mentioned above, I have two X servers from stable with two different drivers and one scrotwm from testing, which connects to X server via tcp socket. Could it be that this mixed setup is the cause of the bug? I’ve ran scrotwm on several pure testing setups, some with Intel and some other with Nvidia graphics, without hitting the bug. Today I set up a container with pure testing inside and tried to run scrotwm from it. Same thing. So, it looks like you're right -- X server upgrade may help. But now scrotwm is the only window manager I tried which does not work properly with xorg from stable. Maybe we should not work around and leave the bug unsolved, while we have a test case. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Tue, Mar 16 2010 at 23:07, Andrea Bolognani wrote: I can reproduce the bug when starting scrotwm from .xsession with xdm. But if I run it manually from any terminal with properly set $DISPLAY -- screen, xterm, VT -- it works just perfectly. Steps to reproduce: - create ~/.xsession with the only line containing 'xterm'; - log in to xdm session; - type 'scrotwm' it the xterm window. Unfortunately, as I’ve noted earlier in the bug report, I’m unable to reproduce the bug, so the only thing I can do is to collect as much info as possible and forward it upstream. I know, thank you for your time! I thought Hannes could try the steps mentioned above. Maybe it will help with his setup either. - Are you hitting this bug on amd64? No, it's pure i586 Lenny/Squeeze mixed setup. Maybe the problem is in some Lenny libraries, but unfortunately it is impossible to update the box to Squeeze now to check. Installed versions of libraries (according to ldd) scrotwm depends on: libx11-6/stable uptodate 2:1.1.5-2 libxrandr2/stable uptodate 2:1.2.3-1 libc6-i686/stable upgradeable from 2.7-18 to 2.7-18lenny2 libxcb-xlib0/stable uptodate 1.1-1.2 libxcb1/stable uptodate 1.1-1.2 libxext6/stable uptodate 2:1.0.4-1 libxrender1/stable uptodate 1:0.9.4-2 libxau6/stable uptodate 1:1.0.3-3 libxdmcp6/stable uptodate 1:1.0.2-3 - What kind of video card do you have? ATI RV280, 'radeon' driver. - How do you run scrotwm to hit the bug? from user's .xsession script, invoked by xdm. - Can you see any error in ~/.xsession-errors when you run scrotwm the “wrong” way? No. It only prints: Welcome to scrotwm V0.9.22 etc.. By the way, yes -- I've checked 0.9.22 as well. And the most interesting thing -- some time ago I faced the same problem when accidentally pressed M-S-x trying to close Iceweasel Downloads window. All Iceweasel windows disappeared and none of the key bindings worked. And now it looks like I can reproduce it: - open an Xwindow session; - start scrotwm from a terminal as described above; - start Iceweasel on an empty workplace (Important -- if there are any other windows, it doesn't work!); - download a file, Downloads window should stay opened; - make Downloads window active; - press M-S-x. Scrotwm then may be restarted from any terminal. Hope it will help. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
I can reproduce the bug when starting scrotwm from .xsession with xdm. But if I run it manually from any terminal with properly set $DISPLAY -- screen, xterm, VT -- it works just perfectly. Steps to reproduce: - create ~/.xsession with the only line containing 'xterm'; - log in to xdm session; - type 'scrotwm' it the xterm window. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
