So, I got fed up with this issue now and found a solution that isn’t pretty. But it works, apparently without any relevant disadvantages, so I’ll live with it for the time being.

Update: in the comments below there’s a different, somewhat cleaner solution, which doesn’t require you to change your “system” Python files.

Yesterday I posted about the problem: offlineimap quits with a “trace trap", which occurs when the line from _locale import * is executed.

For full reference, this line is line 31 of the file locale.py, which lives in your Python version’s library dir. For the standard Python 2.6 that comes with Snow Leopard, that path is /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 – for your Python version the version number may vary, or in the case of a MacPorts installed Python, it’s going to be somewhere else entirely (/opt/local/lib/python2.5 for instance).

I tried hunting down the real origin of this problem, but I wasn’t able to find out anything in the end. I learned an awful lot about using the fantastic toolset that comes with Mac OS X and XCode (Python pdb and gdb, of course, but also the DTrace based stuff like Instruments, dtruss, opensnoop and the like – amazing stuff). But apart from demonstrating that _locale.so can apparently not be imported under the specific circumstances without crashing Python hard, I wasn’t able to get any further. I hope somebody will figure this out eventually.

Meanwhile, looking around the sources (isn’t open source wonderful… – some people always claim you can’t do anything useful with it), I found that there is actually a workaround implementation right there in locale.py. The offending import statement is nested in a try/except block and an exception called ImportError is caught. Presumably that’s the idea. Somehow the problem I’m seeing looks awfully like an import error to me, albeit more of a kick-your-ass-and-hopy-you-die sort of import error (that’s what they say, isn’t it?).

So. I just went and took out the import line and the try/except and left the code in place that would be executed in case of the ImportError. Brilliant, eh? Yeah well, I sort of hate it because I don’t like modifying something I’d call a “system library” from my point of view. Anyway. It works. offlineimap just synchronized about 400 messages or so. Cool.

In case you feel like doing the same thing, I’m making a patch file for the file locale.py available here: locale.py.patch

Please be aware that these instructions come without warranty!! They may not work for you or result in other issues! You follow these steps at your own risk!

In order to use the patch, follow these steps:

1. Download the patch file and save it somewhere on your machine

2. Find the correct path (see above) where your locale.py lives. Open a Terminal window and cd into that path.

3. Make a backup copy of the original locale.py: sudo cp locale.py locale.py.orig

4. Apply the patch with this command: sudo patch < /path/to/locale.py.patch

You should see output from the patch command saying patching file locale.py. This confirms that everything has gone to plan. Now try running offlineimap – it may just work.

Please be aware that these instructions come without warranty!! They may not work for you or result in other issues! You follow these steps at your own risk!

Have fun!

Yesterday I wrote that I was going to roll back my Snow Leopard update today. I just wanted to post a quick update, because as things are, I’ve decided to stay on it.

The main reason is that I managed to fix my alpine build today. Turns out that a workaround had been included in the OS X dependent code parts of alpine, to account for the fact that Apple used to have PAM headers in include/pam instead of include/security, like all other systems do. In 10.6 this has been fixed, and so the workaround broke things. I created a patch, which is now in the process of being worked into the MacPorts distribution.

offlineimap is still not working, but at least I can now use alpine again to access my mail from the IMAP server directly. So I decided not to roll back Snow Leopard after all and just live with the occasional oddity a little while longer :-)

Today I ran the update to Snow Leopard on my laptop. Tomorrow I’m going to roll back that update – I’ll certainly try again, but now doesn’t seem to be the time. Snow Leopard broke a few probably minor, but to me rather important things. Here’s a summary of what I found.

After the update ran through, everything was almost good for a start. I saw a few messages coming up for kexts, but nothing that seemed serious to me. All system stuff was working.

One odd thing I noticed is that I had been running a trial version of iClock, which had installed itself in my menu bar, and after the update it was gone – but the standard system clock didn’t turn up either! I haven’t looked into this.

Now for the worse stuff. I had been using offlineimap to sync my IMAP accounts to local maildirs, which I was accessing with alpine. Yeah, I’m like that :-)

offlineimap is a Python application, and there’s no shortage of Python on Macs. After the update, I found that offlineimap didn’t work anymore. It just showed a “trace trap” (when running from zsh) or a “Trace/BPT trap” (when running from bash) right after the point where it starts working its way through the first of my accounts. Michael Foord was nice enough to give me some Python debugging help and I was able to track down the problem to where locale.py has a line from _locale import *. _locale refers to the file /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_locale.so, or the same for version 2.6. Oddly enough, it is possible to import that file from a console Python session, so I have no idea why this fails.

After some looking around, I decided to try and install a separate Python to check things out. Next, I found my MacPorts installation broken, which did surprise me, since I’d installed the latest 1.8 as per their instructions. But it turns out that’s not enough – between major versions you need to do more work to migrate. Unfortunately there are other, unrelated (?) problems with Python 2.6 in MacPorts (and I also found out that Python 3.1 isn’t the least bit compatible with the other versions, something that I find very interesting but is beside the point here).

I did manage in the end to install Python 2.5.4 from MacPorts, and so was able to see that the same _locale.so problem comes up there as well. I’m sure if you know what the problem is, this makes some sort of sense, but at a glance it seems rather incomprehensible. Well. Whatever causes it, my own self-built /opt/local/lib/python2.5/lib-dynload/_locale.so has the exact same problems now.

To top it all off, my reinstallation efforts of MacPorts also killed my existing, working, alpine installation. When trying to rebuild with the new setup, it turned out that alpine is broken right now as well.

So that was an interesting way of spending a few hours this evening, but I need to get my system back to normal. Not a problem, fortunately – the superb SuperDuper combined with the Mac’s ability of booting from USB drives makes this an easy and safe exercise. I’ll come back to 10.6 a bit later then…

Hm… update to this recent post of mine.

I just found this blog post about VMWare Fusion’s support for Snow Leopard. Hadn’t thought about that yet – it doesn’t support 64 bit as the host yet, and possible won’t do so for the foreseeable future. In that case, I can’t even use the 64 bit kernel, since VMWare support is very important for me. Well.

That makes me think a thought I’ve never thought before… never really wondered too much about 32 vs 64 bit on the Mac. Guess why? Because it doesn’t seem to be important. Why is it important on Windows? Simple: because you can’t have more than 3.something GB of RAM in your machine before it stops recognizing more RAM on 32 bit. So if my current Leopard installation is 32 bit, how come it works with the 16GB I have in my Mac Pro? As usual, there’s probably more to the 32 and 64 bit labels than you see at a glance… answers welcome – I may research myself, but not now :-)

Update: A quick Google search revealed the answers – everything’s right here. Interesting read. Short answer: Mac OS X, as well as Linux, can use PAE to make available more than 4GB even in 32 bit. For reasons better left unexplored here, Windows can’t.

@DerAlbert just pointed me at an article in German, which links to a PDF file with release notes for a recent pre-release Snow Leopard version. What it says is that a 64 bit kernel will not be used by default in Snow Leopard – in spite of all the advertising Apple has done for the 64 bit focus of Mac OS X 10.6.

Although this information is about pre-release software (and yes, it shouldn’t be out there at all – somebody must have broken their NDA), it doesn’t seem likely that things will change before the final release (which according to Apple has been in the post on its way to my house since yesterday – not here yet though).

The release notes show a list of machines where the use of the 64 bit kernel can be forced during startup, and it seems that my Mac Pro is among those. So I’ll have a chance to test this, which is nice – certainly much more than Microsoft can claim for their own efforts at supporting 64 bit.

Something I like about my Macs: Apple tries hard to deliver me everything that’s reasonably part of the operating system I bought in one package. Cool.