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

I have been an avid Firefox user for quite some time. But when I moved to Intel-based Macs, I discovered that that Schubert’s PDF Browser Plugin didn’t work on Intel Macs (except if I placed Firefox in Rosetta mode, running its PPC code in emulation). hat project appears to have died on the vine, with no updates in abut 2 years. Furthermore, Adobe has insisted on making its inline PDF plugin Safari-only. This always struck me as rather redundant, since Apple has used Mac OS X’s Quartz graphics engine to allow viewing of PDFs inline in Safari. This, combined with Firefox’s longer launch times, made me slowly shift to using Safari about 80% of the time.

Yesterday, Firefox 3 was released. I have been using the betas for the last month and have been happy with its improved speed and functionality. Its part of the reason I am back to about a 50/50 split in Safari vs. Firefox use. Today, the other show fell in the form of this posting on MacOS X Hints:

There is now a Firefox extension named firefox-mac-pdf, available for Firefox 3 under OS 10.5 that utilizes the built-in PDF support in OS X to display PDFs in-browser. In my testing, it appears to work very well. It doesn’t have the nifty fading bezel that the Safari PDF viewer does, but it supports all the same keyboard shortcuts and you get the standard Mac OS PDF contextual menu when you control-click on a displayed PDF.

Its interface is not quite as easy to use as Schubert’s plugin, but it works. I now have inline PDF viewing in Firefox and things are better in the world again.

Saving PDFs: The one issue I noticed is there was no seemingly obvious way to save the PDF once you were viewing it. Nothing in the contextual menu allowing “Save as…” for example. Turns out it was easier to save the PDF than I imagined. In the “Issues” page for firefox-max-pdf I found this exchange which included the solution:

Currently there are two ways of saving the PDF:

1. File->Save Page As menu
2. The apple-s (command-s) keyboard shortcut

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!

One of my favorite little programs is LaTeXit.  It allows you to typeset LaTeX equations outside of a text editor and then drag the results into programs like Keynote or Pages.  It was not fully compatible with Leopard and my fix was a kludge that could break other programs.  Pierre Chatelier has released updated LaTeXit to version 1.15.0, which restores Leopard compatibility.  Notably, you can now use the default0 /etc/profile file without fear.

[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 got an email today noting that osxutils now installs correctly in MacPorts under MacOS 10.5 Leopard.  I have tested it and this appears to be correct, the commands:

sudo port -d selfupdate
sudo port -d sync
sudo port install osxutils 

did indeed install osxutils as promised.   I also noticed they upgraded from version 1.6 to 1.7, maybe that was all that was necessary.  All the MacPorts packages I used in Tiger now work in Leopard. Now if I could only get a proper recompile of PHP working under Leopard.

I am having an interesting problem. In my last post, I noted that on some Macs with Leopard installed, deactivating the lines calling /usr/libexec/path_helper in the /etc/profile file fixed LaTeXit hanging at launch. A bit more investigation by Antonio Molins (posted in the comments to that post) revealed it was possible to add an ASCII file in the /etc/paths.d directory. We could create a file called /etc/paths.d/macports containing the only the line

/opt/local/bin

and it should automatically add everything in macports to most user’s PATH variables. However, when I tried this, all my calls to /usr/libexec/path_helper -s always locked up the command.

Some further investigation revealed new user accounts on my Macs didn’t have this problem. I surmised that since I was setting up the PATH and MANPATH variables in my environment at login, that this could apparently lock up path_helper. Since I use tcsh by default (instead of Apple’s default bash shell), I issued the following two commands from the command line

unsetenv PATH
unsetenv MANPATH 

and sure enough path_helper worked without an issue. So something is buggy in path_helper, or at least hypersensitive to pre-existing PATH environmental variables. I’ll have to investigate this more later. One thing I did discover is that

/usr/libexec/path_helper -c 

will produce the commands to set up tcsh’s environment.

/usr/libexec/path_helper -s 

returns those for the default bash shell.

[A better fix to this problem is to upgrade to LaTeXit 1.15, which was released on April 16, 2008.  It fixes the problems with Leopard and allows you to keep the default /etc/profile file for Leopard.]

Apparently, LaTeXIt, which I use to generate equations with Latex which can then be copied into Apple’s Keynote and Pages documents, locks up on launch a vanilla install of Leopard. This post on MacOSXHints.com provides a hack, but it wasn’t that nice, since it involves re-installing a particular version of latex. It turns out the solution was really much simpler and shows up in the comments on that page. In the comments, user Paolo Bosetti notes that

There is actually a much easier workaround: simply change your /etc/profile commenting the following lines (add the “#” at the begining):

# if [ -x /usr/libexec/path_helper ]; then

# eval `/usr/libexec/path_helper -s`

# fi

and adding the following two:

PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin:/usr/X11/bin"

export PATH

Why so? Apple changed the Leopard way to set the PATH variable, and now it uses the /usr/libexec/path_helper command, which seems having troubles with LaTeXiT spawned bash scripts. If you make this modification to your /etc/profile, you are simply dropping the new path_helper in favour of the plain old way to set the PATH variable.

This also explains why I wasn’t seeing this on my laptop, since it kept the old /etc/profile file during the upgrade.

Another user comments that the fix could also be done without hacking the /etc/profile but instead just changing ~/.profile such that /opt/local/bin appears in the path last, since /usr/libexec/path_helper is supposed to read ~/.profile. However, I was unable to get this approach to work.

Since switching to Leopard on my server earlier this week, I have noticed that file transfers over the Ethernet LAN at work are insanely slow. I frequently synchronize files (over AFS File Sharing) over an Ethernet LAN between my server and my MacBook Pro. My MacBook Pro has been running Leopard for several months while my server was running MacOS 10.4.11 until this week. Having been happy with Leopard on my MBP, I decided to upgrade my server. Since then, file transfers between the two computers have been a royal disaster. When I initially connected I was getting speeds of up to 1.5 MB/s, but it quickly drops to 30KB/s or less. This was much less than the 10MB/s speeds I was typically seeing before upgrading my server to Leopard. I couldn’t quite figure out the pattern. It did seem the speed uploading files to my server was not as affected as downloading from my server.

Given the fact I didn’t see any file transfer issues between the two computers before upgrading the server to Leopard (MacOS 10.5.2), I suspected the issue was solely with the server (or possibly due to the communication between two computers running Leopard). On a hunch that the “self-tuning” networking heralded (quietly) on Apple’s Leopard Features page might be the problem, I tried to turn it off by tinkering with the “Advanced” settings in the Network Preference Pane. Specifically I changed the settings to look like this:

Notably, I forced the configuration to be manual (instead of “Automatic”), I set the “Speed” to “100BaseT” which is my LAN’s speed (instead of “autoselect”), and I set the “Duplex” to “full-duplex” without “flow control”. I left the “MTU” at “Standard (1500)”.

Making these changes seems to have done the trick. For the last hour my network has maintained speeds of about 10 MB/s on download, something it hasn’t been able to do for the last few days. I suspect Apple has some work to do on their “self-tuning” Network code.

[Followup Post: Yes,this pretty much fixes my network slowdowns. I just did some Bandwidth tests online, I'm back up to my pre-Leopard speeds.]

The nice thing about MacOS X 10.5 Leopard is that it comes with PHP 5.2.4 pre-installed. Unfortunately one of the features Apple choose not to compile in was support for the GD graphics library, which I use extensively. Furthermore compiling in new features has proven to be somewhat troublesome. When I tried to configure PHP 5.2.5 on my Leopard box which the following commands (a variant of the configure command I would issue under Tiger with no complaints):

<br />./configure --prefix=/usr --mandir=/usr/share/man <br />   --infodir=/usr/share/info --disable-dependency-tracking <br />   --with-apxs2=/usr/sbin/apxs <br />   --with-ldap=/usr --with-kerberos=/usr <br />   --enable-cli <br />   --with-zlib-dir=/usr <br />   --enable-trans-sid <br />   --with-xml <br />   --with-dom <br />   --enable-exif <br />   --enable-ftp <br />   --enable-mbstring <br />   --enable-mbregex <br />   --enable-dbx <br />   --enable-sockets <br />   --with-iodbc=/usr <br />   --with-curl=/usr <br />   --with-iconv=shared,/opt/local<br />   --with-openssl=shared,/opt/local <br />   --with-xmlrpc <br />   --with-xsl=/usr <br />   --with-config-file-path=/etc <br />   --sysconfdir=/private/etc <br />   --with-gd=/opt/local --enable-gd-native-ttf <br />   --with-jpeg-dir=/opt/local <br />   --with-tiff-dir=/opt/local <br />   --with-png-dir=/opt/local <br />   --with-freetype-dir=/usr/X11 <br />   --with-xpm-dir=/usr/X11 <br />   --with-pdflib=/opt/local <br />   --with-gettext=/opt/local<br />   --with-mysql=/usr/local/mysql <br />   --with-mysqli=/usr/local/mysql/bin/mysql_config <br />   --with-pdo-mysql=/usr/local/mysql <br />   --without-pear<br />

The result was a failed configure due to an error in mysql configuration. I pinned this down to a request for a library at /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib which is actually located one directory up. This can be fixed via the command line using:

<br />cd /usr/local/mysql/lib<br />mkdir mysql<br />cp libmysqlclient.15.dylib mysql/libmysqlclient.15.dylib

Then the ./configure worked just fine. Unfortunately, when I did a

<br />make<br />make test

to compile the PHP and test it, there was no happiness. There were over 50 errors, some of them major. Crud.

This is just the setup. See, all I needed was GD graphics library support in PHP for my website. Well, after googling for some time for some master hacker’s notes on getting PHP 5.2.5 to compile on Leopard, I discovered a fellow named Hill Pei had hacked GD support into the Leopard PHP without too much effort. His method simply requires some comfort with the command line and editing text files. In five minutes, I had GD support with Leopard’s built-in PHP. Excellent! [Despite a report in the comments to the contrary. This still appears to be necessary if you apply Security Update 2008-002, which installs PHP version 5.2.5. In which case, you should grab the php 5.2.5 code and work from there. I can confirm Hill Pei's instructions do work after Security Update 20008-002 if you grab the PHP-5.2.5 code instead of 5.2.4 as he suggests.]

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.