[Xquartz-dev] Bugfixes for 2.5.0_rc1

Eeri Kask Eeri.Kask at inf.tu-dresden.de
Mon Mar 22 03:22:39 PDT 2010


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



>> (2) xmodmap, which in previous X11-versions configured some keys out
>> of .xinitrc now doesn't do it from there anymore, out of no apparent
>> reason.  So each day in the office now begins with running this
>> xmodmap by hand out of some xterm; e.g. in order to change
>> left-alt-option from mode-switch back to Alt_L, and few others.  How
>> to revert this change?
> 
> 
> xmodmap is run every time the key layout changes (including on startup).
> There are internal issues which make it difficult to support the
> old way.
> As it is now, if you put your changes into ~/.Xmodmap, it should be run
> whenever the keyboard layout gets updated (such as on startup).
> My guess is you were doing this differently.


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


and things like this by means of the $HOME/.Xmodmap file.



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

The problem with (1) is, that on all other OS'es I am working with
the .xinitrc (which is NFS-mounted to everywhere here) method works
well (and has always worked well), and they together out-vote OSX's
method of now by their sole number.  Nurturing two X11-startup
methods in parallel is not favourable.


>> (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 looks like both ssh-parties
access the same $HOME/.Xauthority file.  Looking hypothetically,
what happens if they both decide to exclusively lock that file, and
proceed only if they both succeed, which cannot be achieved?


>> (6) Some applications leave clutter on screen analogous to the bug I
>> reported
>>
>>  http://lists.freedesktop.org/archives/xorg/2008-August/037802.html
>>
>> but now without xcompmgr running.  So it appears it is probably Xorg
>> but not a compositing-extension issue...
> 
> 
> Please file a bug report with your sample app (http://xquartz.macosforge.org)
> 
> When did you start seeing this behavior?


At that time 2008 I was not yet using MacOSX, and after reporting
then I forgot about it.  Now while upgrading to Xquartz 2.5.0_rc1 I
was looking for something else but stepped in (this report and) that
little program again.  So I don't know if the bug is present in
2.4.x too.  If it is helpful I'll put 2.4.0 back again and test.

I'll tweak that little test program and then file a bug.


>> (7) Something like once per week or few weeks the old server 2.4.?
>> could be crashed by the ancient xless, if this has changed now
>> remains to be observed.  :-)
> 
> 
> Do you recall the backtrace?  Look in /Library/Logs/CrashReporter


Here I count twenty crash-report-files to this bug since 2009-09-29,
I'll pack them together and file a bug in few days.

Greetings,

    Eeri Kask


P.S. Now with 2.5.0_rc1 the xclipboard (i.e. cut+paste) works even
across remote ssh-tunneled X11-applications which is really great,
huge thanks! :-)



More information about the Xquartz-dev mailing list