v1.3 fails to load on fresh Snow Leopard with built-in Ruby, RubyGems and Passenger 2.2.5

[tdd]

Hey there!

So I just lost my beloved pref pane when moving to built-in Ruby thx to my Snow Leopard upgrade (from Leopard).

Here's some diag info:

$ ruby --version ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]

$ which ruby /usr/bin/ruby

$ passenger-config --version --root 2.2.5

$ passenger-config --root /Library/Ruby/Gems/1.8/gems/passenger-2.2.5

Console output when trying to open the pref pane:

17/09/2009 13:09:57 [0x0-0x2ef2ef].com.apple.systempreferences 2009-09-17 13:09:57.364 System Preferences[31492:903] -[PassengerLoader initWithBundle:]: unrecognized selector sent to instance 0x2e03000 17/09/2009 13:09:57 [0x0-0x2ef2ef].com.apple.systempreferences 2009-09-17 13:09:57.364 System Preferences[31492:903] NSPrefPaneBundle instantiatePrefPaneObject: error occurred during instantiation.

What's a developer to do?

Thanks!

[tdd]

(hmm, I guess GFM doesn't actually handle line breaks all that well)

[alloy]

Just to get this clear; You first installed the recent version (1.3) of the prefpane on Leopard and then upgraded to Snow Leopard, and now it doesn't work anymore?

And which version of 10.6 are you currently on? Because unfortunately with the current info I have no idea how to reproduce this…

[soffes]

You have to be sure Apache is running when you install it or it won't work.

Go to the Sharing pref pane and check the web sharing box before installing. That's what I had to do to get it to work for me.

[alloy]

@samsoffes You had those exact same log entries?

[soffes]

@alloy i didn't think to record them when it failed. it is quite possible that is a different issue.

@tdd do you remember if web sharing was on when you tried to install

[tdd]

My built-in Apache has been up all the time (as the Web sharing confirms), as I use it all day long.

[soffes]

Nevermind then. Must have been a different issue.

[alloy]

@samsoffes Damn, too bad, thanks though :)

@tdd Hmm, can you check if you have a RubyCocoa version in /Library/Frameworks and if the md5 of the system RubyCocoa matches mine?

MD5 (/System/Library/Frameworks/RubyCocoa.framework/Versions/Current/RubyCocoa) = 1953a07de6d06710fa410889da9f7abc

[alloy]

Ugh, apperantly we shouldn't reply to issue emails. Pasting here for good reference:

I match yours in /System/Library, but have another one in /Library. Should I kill the latter?

Thanks!

alloy said 1 day ago: Do you remember when/which version you installed into /Library ? And yes, please check if moving it aside helps.

PS: Are you building the pane yourself from source? Or using the downloaded tarball?

[alloy]

@tdd Any progress on this?

[alloy]

Reply was sent directly to my inbox, instead of this issue:

Hey there,

The lib I had in /Library was RubyCocoa-0.13.2.1-OSX10.4universal according to its Receipts entry. Just moving it aside w/o restarting did not help:

cd /Library
mv Frameworks/RubyCocoa.framework /tmp
mv Receipts/RubyCocoa-0.13.2.1-OSX10.4universal.pkg /tmp

I'm not familiar with the logic of OS X framework loading and have no idea whether rebooting now (after putting my moved libs somewhere else than in /tmp…) would be of any help?

[alloy]

Restarting should not be necessary. One question that was unanswered is whether or not you build the pane from source yourself or if you downloaded the binary?

[tdd]

Oh, sorry. No I got the tarball: whenever I try and build it myself, I get an error at some point (which MIGHT have been due to the RubyCocoa version tweak. I'll try and rake it again now).

[tdd]

W00t, that worked! rake built it right up, and the replacer pane that resulted works a charm. So it seems that the tarball may have an issue? Anyway, in my own situation, it's a fix :-)

Thanks for your help!

[alloy]

(A partial) Yay! :)

Still very weird that it doesn't work for you from the tarball. Unfortunately I have no clue how to debug this any further… So closing it for now at least.

Thanks