[Xquartz-dev] 2.3.2_rc4

[Jeremy Huddleston]

On Dec 20, 2008, at 21:51, Mike Meyer wrote:

> Jeremy Huddleston wrote:
>> I know I said this with 2.3.2_rc3, but this time I really mean it.   
>> I expect 2.3.2_rc4 to be our last rc before the final release, so  
>> please give it a good pounding.
>> http://static.macosforge.org/xquartz/downloads/X11-2.3.2_rc4.dmg
>
> This is the first version of X for OSX I've tried in a while; the  
> original leopard version drove me to alternative solutions.

> Anyway, I downloaded this. Then upgraded to to OSX 10.5.6 as it  
> required. Installed this on top of the existing X11 (mistake?)

No, that's fine and expected.

> . After watching font_cache fail a few times, I fixed the obvious  
> problems in it, and rebooted. From there, verify that my environment  
> is reasonable for this version and run xterm:
>
> mbook% echo $DISPLAY
> /tmp/launch-HWJiRa/:0
> mbook% which xterm
> /usr/X11R6/bin/xterm

weird... is /usr/X11R6 a symlink to /usr/X11 as expected?  Why is /usr/ 
X11R6 in your path?  You should just have /usr/X11 in your path from / 
etc/profile...

> mbook% ls -l $(which xterm)
> -rwxr-xr-x  1 root  wheel  733156 Dec 17 22:35 /usr/X11R6/bin/xterm

Based on the date, I'm assuming /usr/X11R6 is a symlink, so that's  
fine...

> That hangs, and the console starts logging the following block of  
> messages repeatedly:
>
>
> 12/21/08 12:21:04 AM org.x.startx[485] font_cache: Scanning user  
> font directories to generate X11 font caches
> 12/21/08 12:21:04 AM org.x.startx[485] font_cache: Updating FC cache
> 12/21/08 12:21:04 AM org.x.privileged_startx[331] font_cache:  
> Scanning system font directories to generate X11 font caches
> 12/21/08 12:21:04 AM defaults[513]
> The domain/default pair of (org.x.X11, dpi) does not exist

That's weird, that should be going to /dev/null ... I'll double check  
that...

>
>
> 12/21/08 12:21:04 AM org.x.startx[485] xauth:  creating new  
> authority file /Users/mwm/.serverauth.485
> 12/21/08 12:21:04 AM org.x.startx[485] xauth: (argv):1:  bad display  
> name "mbook.local:0" in "list" command
> 12/21/08 12:21:04 AM org.x.startx[485] xauth: (stdin):1:  bad  
> display name "mbook.local:0" in "add" command

This looks like the problem... for some reason startx is creating the  
xauth command incorrectly...  any idea why that would be?  Try  
editing /usr/X11/bin/startx to put in some debug spew around xauth to  
figure out what it's doing...

> 12/21/08 12:21:04 AM org.x.startx[485] Xquartz: X11.app = / 
> Applications/Utilities/X11.app/Contents/MacOS/X11
> 12/21/08 12:21:04 AM org.x.startx[485] Xquartz: Starting X server: / 
> Applications/Utilities/X11.app/Contents/MacOS/X11 --listenonly
> 12/21/08 12:21:05 AM org.x.privileged_startx[331] font_cache:  
> Updating FC cache
> 12/21/08 12:21:06 AM org.x.startx[485] waiting for X server to begin  
> accepting connections
> 12/21/08 12:21:06 AM org.x.startx[485] waiting for X server to begin  
> accepting connections
> 12/21/08 12:21:06 AM org.x.startx[485] font_cache: Done
> 12/21/08 12:21:07 AM org.x.privileged_startx[331] font_cache: Done
>
> There's a long sequence of messages that look like this:
>
> 12/21/08 12:21:20 AM org.x.startx[485] .

Yea, it's trying to connect, but it has a bad auth certificate because  
of the xauth failure above...

> 12/21/08 12:21:04 AM org.x.startx[322] xauth: (argv):1:  bad display  
> name "mbook.local:0" in "remove" command

What is 'which xauth' ?

> and then the process starts all over again.

Yeah, that's launchd trying to start org.x.startx because there's  
something in the DISPLAY socket that needs to be read.

> While some of the things in here look like they might cause problems  
> eventually (i.e. - xauth), the only thing that looks like it might  
> cause the server to fail is the bootstrap_look_up failure....

No, that lookup failure thing is completely harmless...