On Mar 22, 2010, at 03:22, Eeri Kask wrote:
Am 03/20/2010 03:00 PM, xquartz-dev-request@lists.macosforge.org schrieb:
(1) Each time I log in (and launch X11) I am asked (sorry for sloppy English translation) something about ... "Do I want to allow remote applications to access X11, an option which can be tuned in firewall options too" ... or something. So each day in the office begins with a click on "yes, I do". How to automate this buttonclick?
My guess is that you have a 3rd party firewall installed, and you should check that software.
I'll take a look at it later, but the fact is, this behaviour appeared only a week ago after installing 2.5.0_rc1. (I am running OSX 10.5.8 --- each time I am even asked for a root password to make a change to somewhere but it apparently is discarded after each session.)
There is absolutely NOTHING in XQuartz that should be doing that. Do you have the exact text of the request (you can probably take a screen shot with cmd-shift-4).
If I remember correctly, Xorg 1.6.x (or 1.5.x, I don't know anymore) had this or analogous 'behaviour' too (i.e. on other OS'es than MacOSX) but after installing 1.7.x the 'old' behaviour appeared recovered which was a really good advancement.
One of the problems with the above suggestion is, I don't know how to implement
if test "Darwin" = "`uname -s`" then echo 'keycode 66 = Alt_L' | xmodmap - echo 'keycode 69 = Alt_R' | xmodmap - else echo 'keycode 115 = Meta_L' | xmodmap - echo 'keycode 116 = Meta_R' | xmodmap - fi
mkdir ~/.xinitrc.d cat > ~/.xinitrc.d/10-xmodmap_prep.sh <<EOF #!/bin/bash if [[ \"\$(uname -s)\" == "Darwin" ]] ; then echo 'keycode 66 = Alt_L' echo 'keycode 69 = Alt_R' else echo 'keycode 115 = Meta_L' echo 'keycode 116 = Meta_R' fi > ~/.Xmodmap EOF chmod 755 ~/.xinitrc.d/10-xmodmap_prep.sh
(3) This is older bug: after logging in X11 starts xterm at top-left, despite the presence of ${HOME}/.xinitrc which is run too and sets up the session correctly. How to disable this xterm-starting?
1) Please transition to using ~/.xinitrc.d rather than ~/.xinitrc, so you can inherit any fixes from us.
2) defaults write org.macosforge.xquartz.X11 app_to_run /usr/bin/true
The variant (2) above would be the ultimate solution if it only worked on OSX-10.5.8...
There, you need org.x.X11 instead.
(4) New bug: Starting remote X11 applications by
ssh -f remotehost remote-application
now apparently succeeds only with the first remote application, further applications often result in something like
Warning: No xauth data; using fake authentication data for X11 forwarding. /usr/bin/xauth: error in locking authority file /home/eeri/.Xauthority X11 connection rejected because of wrong authentication. Error: cannot open display: localhost:11.0
This works for me. It looks like your remote filesystem does not support locking. I added a fix for that last year. What version of libXau is installed on your remote system? Try updating to libXau 1.0.3:
The NFS-server (from where the $HOME filesystem comes from) has libXau 1.0.4 so it cannot be this.
It's not the NFS server that matters. It's the client side that matters. The system that you are running your X11 application on needs to have libXau 1.0.4