[Xquartz-dev] Bugfixes for 2.5.0_rc1

Jeremy Huddleston jeremyhu at apple.com
Mon Mar 22 12:13:45 PDT 2010


On Mar 22, 2010, at 03:22, Eeri Kask wrote:

> Am 03/20/2010 03:00 PM, xquartz-dev-request at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5820 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20100322/65193b65/attachment.bin>


More information about the Xquartz-dev mailing list