So, I finally resolved my build issues. Here's 2.4.1_alpha1 for SnowLeopard. It makes that ptty resize option on by default to workaround the bug in xterm/ptty. It installs in /opt/X11, /Library/Launch*, /Applications/Utilities/ XQuartz.app This release is the first to allow differnt X11 servers to "own" $DISPLAY. You can pick which X11 server will actually "own" it by disabling the others' startx LaunchAgents. You will notice (after logout/login) that $DISPLAY now has "org.macosforge.xquartz" in its filename which identifies XQuartz.app as the owner. That being said, SL's X11 assumes that it owns $DISPLAY. If you run X11.app while it's not the owner, it will actually trigger XQuartz.app to start and wait forever for its own startup notification. Hopefully I can get X11 a SoftwareUpdate in a future dot release of OSX to update this (or you can do it on your own by copying over a new X11.bin into X11.app). X11 servers that don't "own" DISPLAY will unset DISPLAY and their children will continue to use the traditional DISPLAY values (":1", ": 2", etc). I did not update the release notes in the .pkg, so you'll need to check the site for a full changelog: http://xquartz.macosforge.org/trac/wiki/ChangeLog Here's the dmg: http://static.macosforge.org/xquartz/downloads/SL/X11-2.4.1_alpha1.dmg Note: X11 alpha/beta updates will only be released for SL. rcs will be rolled for both Leo and SL. It's just not worth the extra overhead. Thanks, Jeremy
Hi Jeremy, Sounds great. Just so I don't do something stupid, could you detail the configure options needed to replicate this setup when building from source (for xserver)? Perhaps an update to the wiki could be in order? :) -- Pelle Johansson 17 sep 2009 kl. 03.47 skrev Jeremy Huddleston:
So, I finally resolved my build issues. Here's 2.4.1_alpha1 for SnowLeopard.
It makes that ptty resize option on by default to workaround the bug in xterm/ptty. It installs in /opt/X11, /Library/Launch*, /Applications/Utilities/ XQuartz.app
This release is the first to allow differnt X11 servers to "own" $DISPLAY. You can pick which X11 server will actually "own" it by disabling the others' startx LaunchAgents. You will notice (after logout/login) that $DISPLAY now has "org.macosforge.xquartz" in its filename which identifies XQuartz.app as the owner.
That being said, SL's X11 assumes that it owns $DISPLAY. If you run X11.app while it's not the owner, it will actually trigger XQuartz.app to start and wait forever for its own startup notification. Hopefully I can get X11 a SoftwareUpdate in a future dot release of OSX to update this (or you can do it on your own by copying over a new X11.bin into X11.app).
X11 servers that don't "own" DISPLAY will unset DISPLAY and their children will continue to use the traditional DISPLAY values (":1", ":2", etc).
I did not update the release notes in the .pkg, so you'll need to check the site for a full changelog:
http://xquartz.macosforge.org/trac/wiki/ChangeLog
Here's the dmg:
http://static.macosforge.org/xquartz/downloads/SL/X11-2.4.1_alpha1.dmg
Note: X11 alpha/beta updates will only be released for SL. rcs will be rolled for both Leo and SL. It's just not worth the extra overhead.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sep 17, 2009, at 09:51, Pelle Johansson wrote:
Hi Jeremy,
Sounds great. Just so I don't do something stupid, could you detail the configure options needed to replicate this setup when building from source (for xserver)? Perhaps an update to the wiki could be in order? :)
all modules: --prefix=/opt/X11 xinit: remove the --with-launchagents-dir=... --with-launchdaemons-dir=..., so it defaults to /Library instead of /System/Library xinit and xserver: add --with-launchd-id-prefix=org.macosforge.xquartz to set the identifier If you want to use sparkle, you also need to add --enable-sparkle to xserver's configure. What wiki page needs updating? --Jeremy
17 sep 2009 kl. 19.25 skrev Jeremy Huddleston:
xinit and xserver: add --with-launchd-id-prefix=org.macosforge.xquartz to set the identifier
Hrm, and --with-apple-application-name=XQuartz I assume...
If you want to use sparkle, you also need to add --enable-sparkle to xserver's configure.
What wiki page needs updating?
DeveloperInfo is missing instructions for the 1.6 branch. -- Pelle Johansson
On Sep 17, 2009, at 10:38, Pelle Johansson wrote:
17 sep 2009 kl. 19.25 skrev Jeremy Huddleston:
xinit and xserver: add --with-launchd-id-prefix=org.macosforge.xquartz to set the identifier
Hrm, and --with-apple-application-name=XQuartz I assume...
Oh, yep... I forgot that one.
If you want to use sparkle, you also need to add --enable-sparkle to xserver's configure.
What wiki page needs updating?
DeveloperInfo is missing instructions for the 1.6 branch.
Thanks.
Jeremy, I installed 2.4.1_alpha1 on a brand new computer with pre-installed SL. I had done no other additions to the system. I noticed that the tail end of the "path" variable was set to "/usr/X11R6/bin /opt/X11/bin /opt/X11/bin". Hence the 2.4.1_alpha1 X11 binaries would not be used. Also /opt/X11/bin is repeated twice. Otherwise I see no problems with the alpha1. Regards -John On Wed, Sep 16, 2009 at 6:47 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
So, I finally resolved my build issues. Here's 2.4.1_alpha1 for SnowLeopard.
It makes that ptty resize option on by default to workaround the bug in xterm/ptty. It installs in /opt/X11, /Library/Launch*, /Applications/Utilities/XQuartz.app
This release is the first to allow differnt X11 servers to "own" $DISPLAY. You can pick which X11 server will actually "own" it by disabling the others' startx LaunchAgents. You will notice (after logout/login) that $DISPLAY now has "org.macosforge.xquartz" in its filename which identifies XQuartz.app as the owner.
That being said, SL's X11 assumes that it owns $DISPLAY. If you run X11.app while it's not the owner, it will actually trigger XQuartz.app to start and wait forever for its own startup notification. Hopefully I can get X11 a SoftwareUpdate in a future dot release of OSX to update this (or you can do it on your own by copying over a new X11.bin into X11.app).
X11 servers that don't "own" DISPLAY will unset DISPLAY and their children will continue to use the traditional DISPLAY values (":1", ":2", etc).
I did not update the release notes in the .pkg, so you'll need to check the site for a full changelog:
http://xquartz.macosforge.org/trac/wiki/ChangeLog
Here's the dmg:
http://static.macosforge.org/xquartz/downloads/SL/X11-2.4.1_alpha1.dmg
Note: X11 alpha/beta updates will only be released for SL. rcs will be rolled for both Leo and SL. It's just not worth the extra overhead.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sep 19, 2009, at 00:25, John Koren wrote:
Jeremy,
I installed 2.4.1_alpha1 on a brand new computer with pre-installed SL. I had done no other additions to the system. I noticed that the tail end of the "path" variable was set to "/usr/X11R6/bin /opt/X11/bin /opt/X11/bin". Hence the 2.4.1_alpha1 X11 binaries would not be used. Also /opt/X11/bin is repeated twice.
Yeah, the "ordering" is due to the /etc/paths.d file... X11 is the "/ usr/X11" one... XQuartz is the "/opt/X11" one... too bad we didn't prefix those with numbers... hmm... any idea why it's coming up twice? is /usr/X11 in there twice? why is /usr/X11R6/bin in there and not /usr/X11 ?
On 21 Sep 2009, at 05:43, Jeremy Huddleston wrote:
On Sep 19, 2009, at 00:25, John Koren wrote:
Jeremy,
I installed 2.4.1_alpha1 on a brand new computer with pre-installed SL. I had done no other additions to the system. I noticed that the tail end of the "path" variable was set to "/usr/X11R6/bin /opt/X11/bin /opt/X11/bin". Hence the 2.4.1_alpha1 X11 binaries would not be used. Also /opt/X11/bin is repeated twice.
Yeah, the "ordering" is due to the /etc/paths.d file... X11 is the "/ usr/X11" one... XQuartz is the "/opt/X11" one... too bad we didn't prefix those with numbers...
hmm...
any idea why it's coming up twice? is /usr/X11 in there twice? why is /usr/X11R6/bin in there and not /usr/X11 ?
Same problem here: is there a reasonable way to make /opt/X11 come before /usr/X11 in PATH other than by hand?
you can rename the files in /etc/paths.d On Oct 28, 2009, at 05:05, vmrsss wrote:
On 21 Sep 2009, at 05:43, Jeremy Huddleston wrote:
On Sep 19, 2009, at 00:25, John Koren wrote:
Jeremy,
I installed 2.4.1_alpha1 on a brand new computer with pre-installed SL. I had done no other additions to the system. I noticed that the tail end of the "path" variable was set to "/usr/X11R6/bin /opt/X11/bin /opt/X11/bin". Hence the 2.4.1_alpha1 X11 binaries would not be used. Also /opt/X11/bin is repeated twice.
Yeah, the "ordering" is due to the /etc/paths.d file... X11 is the "/usr/X11" one... XQuartz is the "/opt/X11" one... too bad we didn't prefix those with numbers...
hmm...
any idea why it's coming up twice? is /usr/X11 in there twice? why is /usr/X11R6/bin in there and not /usr/X11 ?
Same problem here: is there a reasonable way to make /opt/X11 come before /usr/X11 in PATH other than by hand? _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Hi guys, This release doesn't auto-launch XQuartz on my Snow Lep system when I start an X client. I've verified that DISPLAY is set properly (i.e. it's set by launchd). It looks like the system X11 is getting mixed into things, because after launching an X client I end up with processes like this (note the /usr/X11/bin/fc-cache): [n8gray@golux]% allps | grep X11 root 49459 0.0 0.0 31 /opt/X11/lib/X11/xinit/privileged_startx -d /opt/X11/lib/X11/xinit/privileged_startx.d n8gray 53007 3.1 0.0 31 /bin/sh /opt/X11/bin/startx n8gray 53012 1.9 0.0 31 /bin/bash /opt/X11/bin/font_cache root 53029 2.7 0.0 31 /bin/bash /opt/X11/bin/font_cache -s n8gray 53045 13.1 0.1 33 /usr/X11/bin/fc-cache n8gray 53091 0.6 0.0 31 /opt/X11/bin/xinit /opt/X11/lib/X11/xinit/xinitrc -- /opt/X11/bin/X :0 -nolisten tcp -auth /Users/n8gray/.serverauth.53007 n8gray 53102 0.0 0.0 31 grep --color=auto X11 Do I have to disable the system's X11 launch agent? I've tried the following: [n8gray@golux]% launchctl list | grep startx - 0 org.x.startx - 1 org.macosforge.xquartz.startx [n8gray@golux]% sudo launchctl unload -w /System/Library/LaunchAgents/org.x.startx.plist Password: launchctl: Error unloading: org.x.startx Ok, I just randomly discovered that the key is to NOT use sudo when unloading that launch agent, no thanks to launchctl's lame error non-messages. Still, it doesn't seem to help. I've even tried moving /usr/X11 aside and symlinking it to /opt/X11. Nothing works. Console reports these messages: 9/30/09 5:25:54 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Done 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] font_cache: Scanning user font directories to generate X11 font caches 9/30/09 5:26:02 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Scanning system font directories to generate X11 font caches 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] font_cache: Updating FC cache 9/30/09 5:26:02 PM defaults[3646] The domain/default pair of (org.macosforge.xquartz.X11, dpi) does not exist 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] xauth: creating new authority file /Users/n8gray/.serverauth.3609 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] Xquartz: Could not find a new enough X11.app LSFindApplicationForInfo() returned 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] X11.app = /Applications/Utilities/XQuartz.app 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] Version = 2.4.10 (0), Expected Version > 2.3.0 or 2.1.6 9/30/09 5:26:02 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Updating FC cache 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] font_cache: Done 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] giving up. 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] /opt/X11/bin/xinit: Connection refused (errno 61): unable to connect to X server 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] /opt/X11/bin/xinit: No such process (errno 3): Server error. 9/30/09 5:26:04 PM com.apple.launchd.peruser.504[255] (org.macosforge.xquartz.startx[3609]) Exited with exit code: 1 9/30/09 5:26:05 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Done 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] font_cache: Scanning user font directories to generate X11 font caches 9/30/09 5:26:12 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Scanning system font directories to generate X11 font caches 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] font_cache: Updating FC cache 9/30/09 5:26:12 PM defaults[3807] The domain/default pair of (org.macosforge.xquartz.X11, dpi) does not exist 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] xauth: creating new authority file /Users/n8gray/.serverauth.3771 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] Xquartz: Could not find a new enough X11.app LSFindApplicationForInfo() returned 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] X11.app = /Applications/Utilities/XQuartz.app 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] Version = 2.4.10 (0), Expected Version > 2.3.0 or 2.1.6 9/30/09 5:26:12 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Updating FC cache 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] font_cache: Done 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] giving up. 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] /opt/X11/bin/xinit: Connection refused (errno 61): unable to connect to X server 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] /opt/X11/bin/xinit: No such process (errno 3): Server error. 9/30/09 5:26:14 PM com.apple.launchd.peruser.504[255] (org.macosforge.xquartz.startx[3771]) Exited with exit code: 1 Any suggestions? Thanks, -n8 On Wed, Sep 16, 2009 at 6:47 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
So, I finally resolved my build issues. Here's 2.4.1_alpha1 for SnowLeopard.
It makes that ptty resize option on by default to workaround the bug in xterm/ptty. It installs in /opt/X11, /Library/Launch*, /Applications/Utilities/XQuartz.app
This release is the first to allow differnt X11 servers to "own" $DISPLAY. You can pick which X11 server will actually "own" it by disabling the others' startx LaunchAgents. You will notice (after logout/login) that $DISPLAY now has "org.macosforge.xquartz" in its filename which identifies XQuartz.app as the owner.
That being said, SL's X11 assumes that it owns $DISPLAY. If you run X11.app while it's not the owner, it will actually trigger XQuartz.app to start and wait forever for its own startup notification. Hopefully I can get X11 a SoftwareUpdate in a future dot release of OSX to update this (or you can do it on your own by copying over a new X11.bin into X11.app).
X11 servers that don't "own" DISPLAY will unset DISPLAY and their children will continue to use the traditional DISPLAY values (":1", ":2", etc).
I did not update the release notes in the .pkg, so you'll need to check the site for a full changelog:
http://xquartz.macosforge.org/trac/wiki/ChangeLog
Here's the dmg:
http://static.macosforge.org/xquartz/downloads/SL/X11-2.4.1_alpha1.dmg
Note: X11 alpha/beta updates will only be released for SL. rcs will be rolled for both Leo and SL. It's just not worth the extra overhead.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (5)
-
Jeremy Huddleston
-
John Koren
-
Nathan Gray
-
Pelle Johansson
-
vmrsss