Running FogBugz on Leopard
Posted on October 30, 2007 by Brian Webster
Filed Under Development, Tips & Tricks | 1 Comment
I use FogBugz as my main bug tracking and customer support system. It’s a neat application that runs on PHP and a web interface and allows me to both keep track of bugs/features in my development, as well as handle all tech support e-mail. It’s designed with a multi-user environment in mind, but works quite well for a one-man shop such as myself. The web interface is not as good as a true desktop interface could be, but it’s perfectly sufficient, and I’ve become quite dependent on FogBugz as part of my daily workflow.
Dependent enough that it was a rather rude (but not wholly unexpected) discovery to find that upgrading to Leopard pretty soundly hosed my FogBugz installation. Not that it went and deleted files or data or anything, but the setup was quite far from working normally.
The primary cause for this was that Leopard now ships with Apache 2.2, whereas Tiger came with Apache 1.3. All the various differences are well documented out there on the intertubes, but a lot of things, such as where configuration files are stored, changed between the two versions. For example, instead of httpd.conf being in /etc/httpd, it now resides in /etc/apache2.
I got that part figured out pretty quickly, but then when I went to start up the web server, I would get a message printed in the system console reading:
Oct 30 12:07:57 bw-mbp org.apache.httpd[11317]: httpd: Syntax error on line 484 of /private/etc/apache2/httpd.conf: Syntax error on line 8 of /private/etc/apache2/other/+entropy-php.conf: Cannot load /usr/local/php5/libphp5.so into server: dlopen(/usr/local/php5/libphp5.so, 10): no suitable image found. Did find:\n\t/usr/local/php5/libphp5.so: no matching architecture in universal wrapper
Hmmm, well, I do have a custom build of PHP5 (in /usr/local/php5, with additional extensions needed for FogBugz) and it seems to be finding that OK, but it’s complaining about architecture something-or-other. I’m still running on Intel, aren’t I?
[bw-mbp:~] bwebster% file /usr/local/php5/libphp5.so
/usr/local/php5/libphp5.so: Mach-O universal binary with 2 architectures
/usr/local/php5/libphp5.so (for architecture ppc): Mach-O bundle ppc
/usr/local/php5/libphp5.so (for architecture i386): Mach-O bundle i386
Yeah, that’s got an Intel build in there, that’s OK. What the heck is Apache’s problem?
[bw-mbp:~] bwebster% file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 4 architectures
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc
/usr/sbin/httpd (for architecture ppc64): Mach-O 64-bit executable ppc64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64
Oooh, I see 64-bit stuff in there, don’t I? I suppose that could be a problem if it’s trying to load a 32-bit library. Well, the packaged PHP that I installed from entropy.ch hasn’t been updated yet for Leopard, so I guess I’ll have to download and compile PHP myself so I can get in on the 64-bit goodness.
*insert footage of Brian downloading a bunch of stuff, typing ./configure and make, and seeing copious error messages fly across his terminal window*
Hmmm, OK, I think someone smarter than me is going to need to figure this stuff out. But I don’t have time for that, I want to get my FogBugz up and running so I don’t have to switch back to Tiger just to answer customer e-mail. If I could just force Apache to run as 32-bit instead of 64-bit, it should be able to load this PHP module just fine. Now let’s see, what would Dr. 90210 do…?
[bw-mbp:~] bwebster% man lipo
Yes, this is extremely hacktackular, and I’m sure there must be a better way to do this, but this is what I got.
[bw-mbp:~] bwebster% cd /usr/sbin
[bw-mbp:~] bwebster% sudo cp httpd httpd-fat
[bw-mbp:~] bwebster% sudo lipo httpd -thin i386 -output httpd
After making a backup of the httpd executable for safety purposes, the lipo commands sucks out all of the architectures included in the universal binary except the 32-bit Intel one (specified by “i386″). Apache can’t run as 64-bit if it doesn’t have a 64-bit binary!
After doing this, starting up the web server again worked just fine, and loaded the existing 32-bit PHP5 module. Once I got all my httpd.conf customizations moved over to the new location, that was pretty much all I needed to do. It also turns out that I probably would have run into this same problem for FogBugz specifically, since it loads its own fogutil.so PHP module which is also only available as 32-bit right now. I don’t know for sure, but I’m guessing people running on G5s, which also support 64-bit, would probably need the same trick, except replacing “ppc” for “i386″.
This is obviously a very poor long term solution, but if anyone needs to get FogBugz up and running on Leopard right away, this did the trick for me. Ultimately, getting FogBugz to work hack-free will require someone to get a 64-bit build of the PHP5 Apache module figured out, as well as Fog Creek providing a 64-bit build of their own Apache module. And of course what I’ve outlined here is totally unsupported by Fog Creek, so proceed at your own risk!
iPhoto Library Manager 3.4 released
Posted on October 30, 2007 by Brian Webster
Filed Under Updates, iPhoto Library Manager | 7 Comments
At long last, iPhoto Library Manager is ready for Leopard! OK, it hasn’t really been that long since Leopard came out (4 days?), but it seemed like a long time. The new version is available for download and as usual, is a free update for existing customers. Leopard compatibility was the biggest change in this new version, but it also includes a bug fix or two as well. Enjoy!
MacFixIt’s scare tactics
Posted on October 26, 2007 by Brian Webster
Filed Under Apple | Leave a Comment
I just read this article on MacJournals regarding MacFixit’s tendancy to overhype problems, and I’m glad someone is calling a spade a spade here. MacFixIt used to be a useful site, but in recent years it has gone downhill in the quality of what they publish, almost to the point of being useless, or worse, harmful. It reminds me somewhat of Symantec trying to hype nonexistent virus threats to the Mac so they can sell more copies of Norton AntiVirus that nobody needs.
The article uses a recent MacFixIt post on DiskWarrior as an example, and I actually used to work for Alsoft for a few years, and it’s definitely not the first time this sort of thing has happened with MacFixIt. We had to deal with them on several occasions when they posted various stories, mostly regarding DiskWarrior, that either stretched the truth or were just outright false.
It seems that a large amount of MacFixIt’s material comes from reader e-mails and other such input. That’s not a problem in and of itself, but the problem is that there is almost no effort put forth on their part to filter and/or verify the statements made by their readers. The result is that stories go up on the site that have absolutely no basis in reality, simply because one or two readers e-mailed in. “I noticed that when I upgraded my iLife on the full moon, it crashed my machine, but then when I rebooted and tried again when the moon was waning, it worked!” results in the headline “Warning: iLife installer deletes your photos when installed under a full moon!“
MacFixIt seems to hardly ever even bother to try some of these things readers write in about to see if they actually behave as described, but even worse, they often won’t even try verifying something with the developer of an application if a problem is reported with it. This happened several times at Alsoft, where some reader reported a problem with DiskWarrior and blamed it on something, and MacFixIt happily plastered it on their front page as though it were gospel, causing all sorts of people to panic about running DiskWarrior under whatever circumstances they claimed caused the problem. I remember one case in particular where they claimed that DiskWarrior wouldn’t work with Firewire 800 drives (which is utter nonsense), simply because some reader had had a problem rebuilding their own Firewire 800 drive. Of course it turned out to have a completely different cause (a bug in Quicktime), one that had actually already been well documented months ago, on MacFixIt’s own site!.
Had they bothered to simply shoot an e-mail or phone call our way, we could have provided them with the solution, they could have referred their reader to their old article with the solution, and saved everyone a whole lot of hassle. This is not only a problem for MacFixIt’s readers, but it costs the victim company time and money in responding to the resulting support calls and e-mails, plus the effort needed by the company to try to set the record straight.
So, if you’re a regular MacFixIt reader, I would encourage you to take everything they say at least with a grain of salt, if not to stop reading the site altogether. They have journalistic integrity on par with the National Enquirer. And if you do experience a problem with a program, contact the program’s developer. They are often quite helpful and actually know what they’re talking about, and will be happy to help you with your problem. Now if you’ll excuse me, I need to go install Leopard before the tides come in…
iPLM Leopard update
Posted on October 24, 2007 by Brian Webster
Filed Under News, iPhoto Library Manager | 4 Comments
Just a quick note on iPhoto Library Manager compatibility with Leopard:
- I am currently working on the update, but Apple has decided not to give developers an advance copy of the final version of Leopard until it ships, which means that I won’t truly be able to start final testing until this weekend. I’m hoping that it won’t take too long and that the iPLM update will be out sometime next week.
- Similarly to major iPhoto updates, so far the basic library switching in iPLM seems to work fine in Leopard, it’s just the advanced photo copying stuff that will need additional work, so upgrading to Leopard isn’t going to cut you off from your iPhoto libraries or anything
- The update will be free, so if you buy a copy of iPhoto Library Manager now, you won’t have to pay to upgrade, you can just download the new version.
That’s all for now, I’ll try to keep updates coming as I know more.
Apple totally stole my line!
Posted on October 17, 2007 by Brian Webster
Filed Under Apple | 3 Comments
I was looking through the Mac OS X Server section of Apple’s website, which has also been updated with Leopard info in the last couple days, when I saw this:
Hmmmm, this is seeming awfully familiar… where might I have seen this before?
Yeah, OK, my evidence is a little slim…. so far. But I’ve got my eye on you, Apple!
Top 10 obscure new Leopard features
Posted on October 16, 2007 by Brian Webster
Filed Under Apple | 1 Comment
I was just reading through the 300 new Leopard features just posted today on Apple’s site. They usually have a list like this with each major OS X release, and I always find it interesting, as there are usually a few little features that don’t make the “top features” list, but are the kind of refinements that can make upgrading worthwhile. Here are a few that I found that I’m looking forward to using.
- Scriptable System Preferences: There’s all sorts of functionality in System Preferences that I wish again and again I could change using a script. It doesn’t look like everything is scriptable, but it’s definitely a step in the right direction
- UI Recording and Playback: Back in the day, Applescript used to support recording, which was a great way to set up simple tasks and learn scripting. This has fallen by the wayside in OS X, but I’m glad to see some kind of recordability make it back into the OS, even if it’s slightly less sophisticated.
- Spring-Loaded Dock: I knew about this before, but apparently in addition to opening folders via the dock, you can also “spring-load” applications. Pressing the space bar while holding a drag over an app in the dock will launch the application. I’m pretty sure I’ll find ways to use this.
- Finder Path Bar: This is a nice little touch that puts the full path to the current folder in the bottom bar of your Finder window, similar to the one you see when selecting a search result. Simple, but will definitely make life easier.
- Inline iCal Editing: I never really liked having to shuttle all the way over to a separate window/drawer to edit iCal events. This looks like it will be much more intuitive.
- iChat Audio/Video Recording: I don’t do audio/video chats that often, but I love having transcripts of my text chats to look back at, and being able to do this with audio/video chats is definitely nice to have.
- Self-Tuning TCP: One of those under-the-hood optimizations that probably should have been done a while ago, and for which there are multiple third-party ways to enable it. Nice to see this here.
- PDF Manipulation in Preview: This is sweet, being able to reorder pages in a PDF, or copy pages from one PDF to another. You can combine multiple PDFs into on or split them apart. Preview is really getting to be a pretty powerful little application.
- Calculations in Spotlight: Finally, I can do quick calculations directly from my keyboard without having to open a separate app or widget.
- Scroll Non-Active Windows: Another little feature that I’ve found myself wanting fairly often. I sometimes employ the command-drag trick to drag a background window’s scroll bar, but just being able to crank the scroll wheel is much nicer.
iPhoto Library Manager and Leopard
Posted on October 12, 2007 by Brian Webster
Filed Under Development, iPhoto Library Manager | 1 Comment
I just thought I would drop a quick note regarding plans for Leopard compatibility for iPhoto Library Manager. The short version is that iPhoto Library Manager will support Leopard fully by the time Leopard comes out. Yay! Since things can change and break things at the last minute with new OS releases, I won’t actually be releasing a Leopard compatible version of iPLM until I can actually test it with the final version of Leopard, but I’ve got the big stuff figured out already. For those interested in the nerdy technical details, read onward.
Leopard will require some changes in the way iPhoto Library Manager works under the hood. iPLM uses the Input Manager mechanism of Mac OS X to load a bundle of code into iPhoto which supplements iPhoto’s Applescripting capabilities, which is what makes features such as copying albums and merging libraries possible. Some other programs, such as Inquisitor and 1Passwd also use input managers to implement their functionality. However, as has been reported by Ars Technica and discussed on some other blogs, input managers are no longer going to be supported under Leopard.
Other developers have found other methods to do what they need to do under Leopard, such as 1Passwd, whose developers say they are going to switch to a WebKit plugin, which works well for them since their product is web browser oriented. iPhoto Library Manager is going to take a different approach though.
One difference between iPLM and some other apps that use input managers is that iPLM only actually needs its code to be loaded when it’s actively doing something with iPhoto, like copying some albums between libraries. It doesn’t matter if the code is loaded every time iPhoto is launched, unlike say, Inquisitor, which pretty much always has to be there to be of any use.
So, instead of a plugin based approach, under Leopard iPLM will use a handy little feature of the OS X dynamic linker, the DYLD_INSERT_LIBRARIES environment variable. Basically what this does is allow you to load additional dynamic libraries in an application (and even substitute for libraries the application is already linked to). The most well known usage for this feature is the MallocDebug developer application, which loads a custom debug version of the malloc library that replaces the normal system library and provides all sort of information on memory usage in the application being debugged.
The downside to this approach is that it requires relaunching the application in question in order to load the additional code, since you have to set up this environment variable and then launch the application yourself. So, for something like Inquisitor, launching Safari directly from the dock would not load the code automatically. There would have to be a separate program that performs the special setup and launch Safari itself, which would be a pain in the butt for users. However, this isn’t really a problem for iPLM, since it has to relaunch iPhoto multiple times during an album copy anyway, so having to do the special setup doesn’t really change the flow of things at all.
There are a couple other upsides to this approach:
- The code will only be loaded into iPhoto itself, unlike input managers, which load their code into any Cocoa application that runs. iPLM’s code doesn’t actually do anything unless it’s being loaded in iPhoto, but the input manager bundle still shows up in crash reports and such, which can be suspicious to others trying to debug a crash.
- Nothing needs to be installed! All the code can sit happily within iPLM’s application bundle, and there’s no need to update the bundle when iPLM is updated, or any of that hassle. This means I’ll actually be deleting more code than I’m writing in order to change to the new method.
The only feature that will be lost as a result of the change is putting the name of the current library in the title bar of the iPhoto window itself. This was a neat addition that I put in on a whim, but since the iPLM code will no longer always be running in iPhoto, this will be going away.
In retrospect, if I had known about this method of doing things back when I first wrote iPLM 3.0, I probably would have done it this way in the first place, since it’s less intrusive and uses a long standing feature of dyld that isn’t likely to go anywhere anytime soon. Like I said above, this method isn’t feasible for many programs that are currently using input managers, but this may still prove a useful technique to some other programs transitioning over to Leopard.
iPhoto 7 editing behavior
Posted on October 9, 2007 by Brian Webster
Filed Under iPhoto, Tips & Tricks, iPhoto Library Manager | 1 Comment
While fiddling around with the editing controls in iPhoto 7, I came across a small bit of new behavior that I thought may be interesting to some. If you use any of the sliders in the “Adjust” palette, iPhoto 7 will actually remember the positions of those sliders if you come back to that photo to edit it a second time.
Picture after editing and reopening
This is in contrast to iPhoto 6, where opening this photo back up again would result in the “Temperature” slider being reset to 0. This is pretty cool overall, even if it prevents you from doing X-TREME 200% SHARPNESS adjustments by sliding the slider to 100% twice.
However, if you choose to edit your photo with an external editor, such as Photoshop or Preview, iPhoto will not remember these slider settings.
Picture after editing in Preview
Also note that when copying photos with iPhoto Library Manager, transferring both the original and modified versions of the photo does the equivalent of editing in an external editor, so the slider settings won’t be transferred.
RSS 2.0