Urania

I was trying to upgrade wine within MacPorts when I realized I had forgotten to upgrade Xquartz after my upgrade to MacOS 10.5.3 on my Mac Pro. So I checked, Xquartz has been upgraded to version 2.2.3. Since version 2.2.1 (which I talked about in my blog here).

• Upgraded the freetype library to version 2.3.6, which fixes “A bunch of potential security problems have been found [and fixed in this release”
• Upgraded to pixman library to version 0.11.4.
• Xquartz fixes from xorg-server-1.3.0-apple21, the key fix being support for monitor hotplugging, although several security fixes also occurred.

Again, if you upgrade MacOS (say to version 10.5.4, which is supposed to be released soon in order to support iPhone G3 and MobileMe), you will likely need to reinstall Xquartz (unless Apple has upgraded their X11 installation to match Xquartz).

The Xquartz project is a useful one for Leopard users of astronomical applications because of the dependence of most astronomical applications on X11. A few days ago (what can I say, its finals and I am swamped with exam writing and grading) they released version 2.2.1. It contains all the tweaks that made it into the previous version and also includes

• All packages updated to versions intended to ship as part of X11R7.4 (as of 2008.04.21).
• Fixed multiple crash-causing bugs in the server.
• Fixed cmd-tab to properly move all windows forward when entering X11.app.
• Cleaned up multi-monitor support (still not completely bulletproof) [I have 2 monitors, so this is a big one for me].

As I have noted before, Apple includes some of the work done in this project in OSX updates, so it is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

Immediately after installing SAOImage DS9 5.2, I had a major failure of the application and initially I just thought it was some sort of build bug. This is what I posted at that time:

[HOLD OFF ON THIS UPDATE! I have discovered that at least on one of my systems, this version of ds9 is refusing to run properly. It launched once, but when I attempted to check the “About SAOImage DS9”, it triggered the following error:

 “An internal error has been detected local header mismatch couldn't open “zvfsmntpt/doc/sun.gif”: no such file.

(this occurred in both Aqua and X11 versions). Furthermore, all future attempts to launch ds9 (again, either Aqua or X11) fail with the following error:

Error in startup script: couldn't read file “./zvfsmntpt/src/ds9.tcl”: no such file or directory  

Even removing the preferences file at ~/.ds9.prf didn’t help.]

Apparently, my problems with SAOImage DS9 in Leopard are a known issue. If you configure the built-in Firewall to “Set access for specific services and applications” so that you can approve “holes” in your firewall on an Application by Application basis, your first launch of SAOImage DS9 will irreparably damage the application!  Unfortunately, Apple implements the application firewall in part by modifying the Application package of the Application you are running by digitally signing it if it was not digitally signed by the developer (adding a file called CodeResources to the Application package). According the Apple’s documentation on this:

If you run an unsigned application not in the Application Firewall list, you will be presented with a dialog with options to Allow or Deny connections for the application. If you choose Allow, Mac OS X 10.5 will sign the application and automatically add it to the Application Firewall list. If you choose Deny, Mac OS X 10.5 will sign the application, automatically add it to the Application Firewall list and deny the connection.

So basically,Apple doesn’t warn you in the dialog box that comes up that it has whatever decision you make, it will modify the application by digitally signing it and it doesn’t give you a way to avoid this. This is, in my opinion, is an incredibly boneheaded move on Apple’s programmer’s part. They readily admit that

  Some applications check their own integrity when they are run without using code signing.

They suggest the application firewall will try to automatically detect these and avoid modifying them, but they should give you, the user, the option instead of making the decision via some internal algorithm.  MacOS X shouldn’t assume its OK to change an application. In the case of SAOImage DS9, they are irreparably damaging the application without leaving you a way to avoid the damage once you trigger the application firewall. Shame on you Apple. The only way to fix it is to reinstall the application!

So when I figured this out (a tip of the hat to this post on IRAF.net). I reinstalled the SAOImage DS9 executables (both Aqua and X11 versions) and before launching them, I set the Firewall (via the Security Pane of the System Preferences) to “Allow all incoming connections” (this is the default mode, so it is as secure as MacOS Tiger was). Everything now appears to work just fine.

Personally, I believe an application that fails its checksum should present a message indicating that is the problem instead of just crapping out, but in this case, the fault lies mostly with Apple. Apple is damaging applications by making this critical decision in the background, without user intervention!

[See my more recent post warning about MacOS X Firewall settings and how they can destroy the SAOImage DS9 executable during its first launch! This problem is avoidable by tweaking the Firewall settings, but once you have launched SAOImage DS9 with the bad settings, the application is damaged can can't be relaunched again. A reinstallation is the only solution, so it is a good idea to avoid this problem.]

The folks in Cambridge have kept busy. They have released SAOImage DS9 version 5.2. The versions for MacOS X include the following:

• Aqua 10.4 Tiger (Universal)
• Aqua 10.5 Leopard (Universal)
• X11 10.4 Tiger (Universal)
• X11 10.5 Leopard (Universal)

The rather extensive changes are detailed in the release notes here, but the notable ones to me include:

• ANALYSIS: for MacOSX tiger, wrap cmds with shell and PATH.
• GUI: change default directory for standard dialog to $HOME.
• ANALYSIS: add /sw/bin to default path for MacOSX. While unstated in the release notes, this is clearly an attempt to support Fink, which places its installation in the /sw directory.
• GUI: ds9 will now start in the users home directory for MacOSX Aqua users when invoked from a double click and the default dialog box is Motif or Windows.
• MACOSX: fixed a problem with printing non standard colors.
• MACOSX: restore postscript printing.
• REGIONS: apply WCS to fits regions if present.
• GUI: add support for user configured button bar.
• CATALOGS: add support for simbad.
• IMEXAMINE: added support for key stroke events.
• Although unstated in their release notes, they are now apparently providing universal binaries instead of PPC and Intel binaries for MacOS X.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine.

[This originally linked to version 2.2.0, but there was a security related bug in version 2.2.0, so this release has appeared to replace it.]

The Xquartz folks have updated Xquartz to version 2.2.0.1. Xquartz is an effort to provide a better X11 server for Leopard than Apple provides, being proactive in providing fixes Apple will likely include later. The release notes are long and cover a bunch of updates to various items, including:

• Added informational output when falling through to failsafe startup in X11.app
• Unsetenv(DISPLAY) when falling through to failsafe startup in X11.app
• Exposé now works as expected
• X11 works better with spaces

I suspect the discussion of ‘failsafe’ startups is to provide a more informational failure than what was happening before for people like myself who transitioned from previous MacOS X installations and had been manually forcing the DISPLAY variable to point to :0.0, which is somewhat standard in the Unix world.

I’d recommend grabbing this Xquartz update and applying it if you use Leopard and astronomical software. Its a double-click install. Apple does watch this project (one of the developers is Apple’s X11 developer), and as noted on the Xquartz site:

Apple included some of the work done in this project in their 10.5.2 update and will likely include further changes in possible future updates of 10.5.x. It is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

In other words, while some of these fixes will likely end up in the official MacOS released by Apple, if you want them now, use Xquartz. Furthermore, since Xquartz does over-write Apple’s default X11 install, this means that if Apple upgrades X11 in a future patch, you could end up with a broken install if you used Xquartz. Personally, I haven’t had a problem, but I suggest you keep the Xquartz package around, and re-install it after any future MacOS X updates.

I have taken part of my day to get my main web server upgraded to MacOS X 10.5 (aka Leopard). I spent quite a bit of time waiting, removing programs I knew were incompatible, and so on. Still, this upgrade was not without a few bumps:

• Check Hardware Compatibility: My Sonnet Tempo SATA X4P card (which I use to provide an external SATA [eSATA] interface for my RAID of data drives) was incompatible with Leopard and would cause the installer to hang. I finally discovered a firmware upgrade was available that fixed this. This was a stupid rookie mistake. Rule of Thumb: Always check the non-Apple hardware for updates before making a major OS X upgrade.
• Watch out for /home: I had been using a symbolic link from /home to /Users because in my old Unix days, I hardcoded a lot of my software to look for my home directory in /home. Leopard expects /home to be available as mount point for the automount service, so getting with the modern era and not relying on /home to point to /User is required if you adopt Leopard.
• Rebuild Web Server Configuration: One problem I was prepared for is that the web server was updated to Apache2. This in itself was not bad, but the configuration files for Apache (version 1) were stored in /etc/httpd and the new configuration files for Apache2 are in /etc/apache2 and they were NOT migrated. I don’t fault Apple for not migrating the files, but I kicked this around on my laptop quite a bit in order to tweak the configuration files back to something I liked. One thing I immediately did was that this MacOS comes with PHP 5.2.4 preinstalled, but not enabled in Apache2. I enabled it by editting the /etc/apache2/httpd.conf file (which you might have to create) and uncommenting the line with # LoadModule php5_module (by removing the ‘#’ symbol from the beginning of the line). Once that was done, I restarted the Apache2 server and all my PHP code (including this blog) was running again.
• Tweak MySQL for Leopard: The PHP 5.2.4 included with MacOS X is compiled with support for MySQL. This is nice in that you can just download the MySQL package installer and quickly get a LAMP server running. However, it was set up with the MacOS X Server version of MySQL in mind, which means it expects the socket to be in a different location than the vanilla MySQL. This can be solved by either tweaking the MySQL configuration (as outlined in the MySQL section of the blog post at http://remysharp.com/2007/10/27/lamp-in-leopard-osx-105-php5-and-apache-22/ ) or by tweaking the PHP configuration by editing the /etc/php.ini file (if it doesn’t exist, first copy /etc/php.ini.default to /etc/php.ini) and search for the line containing mysqli.default_socket = to read
  

  mysqli.default_socket = /private/tmp/mysql.sock
  

  This solution seemed more straight forward, so I did this.
• Reinstall MacPorts: Since I am aficionado of MacPorts, I reinstalled it and rebuilt all the ports. Some of the issues I had before with MacPorts on Leopard on my MacBook Pro cropped up again on my PowerMac G5, notably
• • gv still needs to be patched as I noted here.
  • sqlite3 still does know about its dependence on nawk.
  • xterm doesn’t install unless you update your X11 installation using the latest version of Xquartz (currently at version 2.1.4).
• Update to latest version of Xquartz: Since I don’t like X11 headaches, I updated to the latest version of Xquartz (currently at version 2.1.4).

So the adventure continues. Back to research, I have invested about 5 hours of my spring break into this upgrade, that is enough for now.

The folks behind SAOImage DS9 have now released version 5.1. The big change I’ve noticed since the last version is that version 5.1 works without issues under Leopard’s new X11 implementation. Of course, the disadvantage is you now must download a version compatible with your OS version as well as your CPU.

• If you want the Aqua (MacOS X native version, download the appropriate one of the following files. If you want to use the Aqua-native version from IRAF, you will need to access the command-line binary within the SAOImage DS9.app application bundle as “SAOImage\ DS9.app/Contents/MacOS/ds9“.
  • MacOSX 10.4 Tiger Aqua Interface, Universal (PPC and Intel)
  • MacOSX 10.5 Leopard Aqua Interface, Universal (PPC and Intel)
• If you want the X11-based command line driven version
  • Darwin PPC 10.4 Tiger version
  • Darwin Intel 10.4 Tiger version
  • Darwin PPC 10.5 Leopard version
  • Darwin Intel 10.5 Leopard version

More detailed release notes are available here. See my previous post on SAOImage DS9 5.0 to see how it is possible to upgrade the binaries included with SciSoft OSX.

The latest XQuartz release (2.1.1) finally fixes one of the major annoyances I was having with X11 under Leopard. Because the X11.app program under Leopard is really an xterm launcher, starting X11 always started an xterm window. This has now been fixed. All you need to do is install the new XQuartz package (WARNING: Because this changes the launch daemon settings, you will need to restart the computer afterwards) and then once you have rebooted, type the following command into the terminal:

defaults write org.x.X11 app_to_run /usr/bin/true

And you have xterm-free X11 again. Furthermore, this updates xterm as well, so even though I don’t want xterm to launch automatically with X11, I am happy to have it updated.

I decided I should clean up my laptop’s left over digital crap, so I went through my /usr/local directories cleaning out ancient libraries installed two OSes ago (after making a backup first). I decided I would try reinstalling MacPorts under Leopard, if only to build it clean and remove the old source code siting around from various revisions to the packages over time.First, I installed MacPorts from the disk image for Leopard. Then I attempted to install my usual suspects: sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem Long story short, almost everything works but there were a few key packages that failed to build under MacOS X 10.5.1. This also reminded me that when a package fails to build, you should “port clean” the package (see examples below) before attempting to rebuild it:

• I discovered that teTeX failed to build. This appears to be due to an undeclared dependancy on openmotif. So after the failed install, I just did ansudo port clean --work teTeX; sudo port install openmotif teTeXand teTeX installed just fine.
• In attempting to build subversion I discovered that one of the packages subversion needs, sqlite3, fails to install on Leopard. This appears to be due to an undeclared dependancy on nawk (MacPorts Report Ticket #13500). So again, all I had to do was:sudo port clean --work sqlite3; sudo port install nawk subversionand it worked. I should note that a fairly recent version of subversion now comes with Leopard, version 1.4.4 (as opposed to 1.4.5 with MacPorts).
• gv fails to install unless you patch it. This was reported to MacPorts (Bug Report Ticket #13095). [If you check that bug ticket, you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.]
• osxutils fails almost immediately with a series of errors about conflicting types. Since osxutils did a lot of meta-data manipulation, I am not completely surprised it is broken under Leopard. I have submitted a bug report to MacPorts.
• xterm fails to build. This is irritating because I haven’t had time to confirm is the old xterm Tektronix emulation bug present in the Tiger version of xterm is still present. [This appears to have been cleared up with MacPorts 1.6 if you install Xquartz over the Apple installed X11 server. Doing this is a good idea anyway.]
• wine fails to build (already reported elsewhere). This has already been reported in MacPorts Bug Report Ticket #13488. I wonder if this is related to the possibility being mentioned of Leopard having unreported support for Windows binary execution. [Wine version 0.9.51 DOES compile under Leopard just fine.]
• I can’t build g95 because odcctools fails to compile. This has been reported in MacPorts Bug Report Ticket #13148. [This appears to have been fixed as of January 24, 2008.]
• xephem fails to build because lesstif builds but fails to install. Actually lesstif installed fine once I moved /usr/share/aclocal/ac_find_motif.m4 out of the way. I don’t know if that file was there from my previous install of lesstif. Once lesstif was out of the way, xephem failed to build. Interestingly, MacPorts has version 3.7, I downloaded the source for xephem 3.7.2 from the Clear Sky Institute website, compiled it following the installation instructions without a hitch. I submitted a bug report as MacPorts Bug Report Ticket #13524 (turned out my bug report was a duplicate of MacPorts Bug Report Ticket #13498). This has been fixed, see this post. [This appears to have been fixed as of March 3, 2008.]

I’m actually surprised the number of packages that failed to compile seems pretty small.

Found this nice blog documenting Leopard and X11 issues. On there I found a note that the updated XQuartz package [link now points to page for newer packages] with various fixes for Leopard has been released. I’ll be trying it out shortly.

Well, I think I have ironed out most of my issues with X11 and I am actually very happy with it. But if you are not as happy, check out the X11-Users FAQ. It contains information about how to tackle the following:

• If you really hate the new way X11 uses a custom DISPLAY environmental variable to trigger launchd to launch X11.app, the FQ contains information on how to disable the launchd trigger and then revert to the Tigerish behavior of manually launching X11.app (HINT: Don’t use /Applications/Utilities/X11.app, use /usr/X11/X11.app instead.
• Information on installing Tiger’s X11 on Leopard. Apparently, it can be done without clobbering Leopard’s X11 install.

Really, very useful, even if you don’t mind the new X11, since it illuminates a bit about how this X11 has bee changed. Oh, and it looks like future X11 updates will be made available at a new MacForge website. I hope a nicer set of packages for X11 is available soon, the only big irritation has been my X11 windows slipping under the menubar!

So this weekend I decided to take advantage of the long weekend and between bites of turkey with the family, I decided to upgrade my laptop to Leopard (MacOS 10.5). I had been reading about the various issues with Leopard before the upgrade, so among the things I did in anticipation of Leopard was

• I uninstalled Unsanity’s Application Enhancer.
• I removed X11.app from my automatic launch items in the Accounts Preferences Pane Login Items. X11 is extensively refreshed under MacOS 10.5, so you don’t want to autolaunch X11.app any more.
• I upgraded Cisco’s VPN software to the latest version distributed by my campus (you want Cisco VPN Client 4.9.01 (0090)).
• I did a quick search of the various applications I run and looked for “Leopard” upgrades via MacUpdate.
• Finally, I researched the incompatibility of Adobe Acrobat with MacOS X 10.5. I discovered that while the AdobePDF printer driver broken under the new OS, you can use Apple’s built in PDF capability (specifically “Save as PDF-X”) capability to create the PDF, which can then import and edit just fine in Acrobat.

Having done all that, I decided to bite the bullet and install the upgrade. First thing I did was back up the entire internal drive to an external drive (which I had formatted with Disk Utility to make sure it was capable of booting an Intel Mac) using Carbon Copy Cloner. Once the drive was cloned, I ignored the overhyped warnings from MacFixIt.com (who I won’t link to, because they were bought out, they definitely sold out as a source of accurate help) and instead followed the Apple recommended procedure of just doing an upgrade to my previous Tiger installation. I figured if worst came to worse, I would recover from the backup drive (in my mind, the backup is the critical step, not how you choose to upgrade). So approximately 80 minutes later my laptop finished its upgrade and rebooted. Some notes on my initial issues with the new OS.

• The new dock doesn’t bug me as much as some (John Siracusa does the best analysis of the problems with the new Dock in his extensive ArsTechnica review of Leopard), but maybe its because I thought the old dock was broken enough as a launcher that I use QuickSilver instead (which works fine under Leopard).
• Leopard finally handles virtual memory use nicely, removing old files in the /var/vm directory once the memory has been released.
• I don’t like the translucent menubar, but there exist various free applications to get rid of those and the changed dock.
• The new OS nuked all my installed printers. Not a huge deal, but I have to re-install all my printers again. I kind of understand why this might of happened, but it was a pain.
• I had to use Disk Utility to Repair Permissions before my Widgets behaved properly, but now, they actually seem to run better than before (less delay in accessing them).
• I patched IDL to version 6.4.1, seems to work now.
• I knew from Ben Bayer’s (Apple’s X11 guy) postings on the matter that
  

  Biggest architectural change in Leopard for X11: Switched from XFree86 codebase (based on, IIRC, X11R6.8) to X.org codebase (X11R7.2)

  Biggest user-visible change: launchd support for X11. The only situation where you should need to manually start X11.app is if you are only running remote X11 applications.

  The way that this is accomplished is by some slight-of-hand with the $DISPLAY variable — if you look, it should be something like “/tmp/ launch-vbXRyu/:0″. If an X client connects to this, it will actually connect to launchd, which will start Xquartz if needed and pass the client’s socket to the server.

  All of that should be invisible to you; the X client library (libX11.dylib) was modified to support this, and all X11 applications link against this library. “DISPLAY=:0″ would still work if X11.app is already running, but it will not trigger X11 to launch.

  So in other words, we are not supposed to set the shell environmental variable DISPLAY to “:0″. Well, I removed all the times I set it from .tcshrc, .bashrc, .login, etc and it still remained stubbornly set until I remembered trying to get Carbon Emacs working a few months back required my setting environmental variables to my entire session using the ~/.MacOSX/environment.plist file. I opened it, removed the DISPLAY variable from the list of those set for the entire session, and viola. Almost everything worked as advertised except:

• SAOImage DS9 refused to launch because of the non-standard DISPLAY variable. I initially hacked around this by launching an xgterm (from IRAF) and setting the DISPLAY variable in it to “:0″ then launching ds9 within that xgterm session. I did this all in one line via: 

  xgterm -geometry 80x45+40+30 -sb -e 'setenv DISPLAY :0; ds9 -fifo ~/iraf/dev/imt1 -geometry 800x800+600+30 &'

  where I was connecting to my IRAF pipes (thus the ‘fifo’ command line entry). However, I emailed the SAOImage DS9 folks on Thanksgiving and they replied same day to tell me about the new ds9 darwin 5.1beta. That fixed the launch issues with ds9. Apparently getting the Aqua version updated is a bit trickier, so its not done yet.
• I had to uninstall the MacPorts version of xephem, but installing it manually from the source worked just fine.
• I installed the unofficial updates to X11 from Xdarwin (see MacSingularity for some notes). The biggest issues this fixes are (1) the focusing problem of X11 windows behind Aqua windows not always being “focusable” and a (b) bug in X11 that caused several programs using the Gimp Toolkit (aka gtk) to crash. NOTE: These updates have been superceeded by those on the MacForce XQuartz updates site.

All in all, I like the new upgrade, the most useful feature for me being the QuickLook interface and the just generally better networking behavior. I also think there has been a lot of thought put into nips and tucks (such as where the Firewall controls are now, in the “security” prefpane instead of “sharing”). More reports from the field as my usage of IRAF and ds9 under Leopard continues.