ThoughtSpark.org

I love music. I really think that if I were to change professions, or go back in life to change something, I would had picked up music as a hobby. Sure I buy music, listen avidly and I own a guitar but I suck at the guitar, at least to this point in my life. While I hope to one day invest in my musical talents, for now, I have to listen to other people's music.

When it comes to what I listen to, I listen to nearly anything. I do not like country all that much, although there are certain artists and songs that I do enjoy, but other than that, I listen to nearly anything. My iPod Touch is busting at the seams due to the amount of music on it. While looking through the Apple iPhone App Store, I kept seeing an application called Pandora in the top 25 with killer reviews. I decided to check it out and ever since, my life has changed.

Pandora is published by pandora.com, whom provides a free service where you can create virtual radio stations based on your favorite artist. After you create a radio station, you listen to music by that artist and other artists with similar music, as identified by the Music Genome Project. (While the Music Genome Project is an extremely brilliant algorithm, I will not dive into it here.) Once you create your radio station(s), you begin to listen either in your web browser or on your iPhone/iPod Touch. Music plays commercial free and the user interface allows you to pause a song, skip to the next song, rate the song (Whether you like it or not) or you can even bookmark that song and/or artist. Pandora even lets you buy the song you're listening to. Pandora.com has literally changed the way I listen to music.

For anyone that loves music and likes music tailored to your likes, with complete control to weed out the things you don't like, Pandora.com is for you. Whether you're listening through a web browser, mobile phone or media device like the iPod Touch, Pandor's Music Genome Project will make sure you have the music you want, commercial free. Pandora.com, you rock.

Don't you hate it when you build a new Apache module or install a new Apache module only to startup Apache and see the following: httpd: ... Symbol not found ... Well, for those of you using mod_perl, mod_python and many others on OS X Leopard, this may have already become a common occurrence. Unfortunately, it has started to affect me as well since some users of the Subversion OSX Universal Binary started running into this issue as well.

The bad news about this is that it might appear like your new Apache module is broken. The good news is that it probably is not and is in fact a false positive caused by Apache shipped with OS X. The best news of all is that this doesn't only apply to the Subversion Apache modules. Many other Apache modules running on Leopard could possibly be falsely accused of being broken whenin reality, it's a very simple fix to Apache and not to the module in question. Let's shed some light on the situation.

When I first got wind of this issue, I recompiled my binary like 5 times. I just knew the problem was with my build script. After wasting a few hours, I began scouring Google, Apple's Discussion Lists, asking questions on freenode and a few other things. I finally ran out of ideas and started just grasping at straws and that is when I made a huge discovery. If I started Apache using launchd or /usr/sbin/httpd directly, I no longer got the error about missing symbols. In fact, when Apache started up successfully, it also loaded my module successfully and it ran without any errors or warnings. This was the clue that gave me what I needed to find the culprit. So if launchd and direct invocation of httpd worked properly, let's look at /usr/sbin/apachectl.

Initial skimming of apachectl gave me no information. Everything looked fine. In fact, I see that apachectl invokes httpd with no special arguments or anything like that. Then I found this:

.....
# pick up any necessary environment variables
if test -f /usr/sbin/envvars; then
  . /usr/sbin/envvars
fi
.....

Bingo. After looking at /usr/sbin/envvars, I see that DYLD_LIBRARY_PATH is being set to prepend /usr/lib in front of any custom DYLD_LIBRARY_PATH I might have set. Not having a custom DYLD_LIBRARY_PATH, I wasn't sure this was the cause. But since it is the only difference between the working solutions and the broken one, I kept looking. After further analysis, I see that in my case, the Apple Subversion libraries were being loaded instead of my custom Subversion libraries. This would explain the missing symbols mentioned in the thread that started this all up. Subversion didn't have a libsvn_fs_base in 1.4.4, which is the version of Subversion shipped with Leopard, and that would explain why this error was manifesting.

After commenting out the only two uncommented lines in /usr/sbin/envvars, I was able to finally start Apache successfully using apachectl and have it load my Subversion 1.5.1 Apache modules with no errors or warnings. The problem has been found and the solution is now known. So what have we learned?

Apple has done a great job to ship many third-party Apache modules with it's latest operating system offering. The problem is that if you want to build custom versions of any Apache modules shipped with OS X, you may run into the same problem many of us have where apachectl, and envvars, is creating a custom DYLD_LIBRARY_PATH, that will override any one you've setup, and it may cause false errors like: Symbol not found. If you're running into the "Symbol not found" when loading a new module into Apache on OS X, try running httpd directly:

sudo /usr/sbin/httpd -D FOREGROUND

and if your Apache loads fine with this approach, but fails to load using apachectl, there is a good chance you have ran into the same problem many of us have and the solution above might just be your ticket.

Well, the Universal Subversion 1.5.1 installer was met with mixed feelings. On one hand, it fixed issues with JavaHL on PPC, included the Subversion 1.5.1 stuff and appeared to finally have SASL support. Little did we know that by including SASL support we broke svn+ssh on Tiger (10.4).

The reason behind this is because we linked against Apple's distribution of libsasl2 and after some research, we found out that libsasl2 from Apple has issues when linked to from third party software. To resolve this, we built Cyrus SASL from source and are now distributing this with the installer.

Please upgrade at your earliest convenience to replace the problematic 1.5.1 installation with the new 1.5.1-2 installation. Other than fixing the SASL stuff, nothing new is in this package.

Here is a direct link: http://www.collab.net/downloads/community/

As Subversion 1.5.1 became available this week, so did the Subversion 1.5.1 OSX Universal Binary. While this is usually a boring little "Downoad the Latest" announcement, this time the binary comes with some improvements. Although the list is short, for enterprise consumers of the binary, this could be big. Here are the noteworthy changes:

• Fixed JavaHL on PPC
• Added Cyrus SASL support

Since the binary is already pretty complete, the list above is short and sweet. For those of you using previous versions of the binary, the new version is the most tested version of the binary yet. Feel free to upgrade.

In my last post I mentioned that I had been working feverishly on AnkhSVN 2.0. Well, I'm proud to announce the official release of AnkhSVN 2.0 Final.

For those of you that do not know, AnkhSVN is a Subversion source control provider for Visual Studio.NET. With AnkhSVN, you can do nearly all Subversion client interaction within the IDE using intuitive context menus, tool windows and keyboard shortcuts. AnkhSVN 2.0 is a huge overhaul of the previous AnkhSVN 1.0 line and includes, but is not limited to, the following new features:

• Visual Studio.NET 2008 Support
• Subversion 1.5. Support
• More Subversion Client Features
  • Merge Support
  • Properties Support
  • Enhanced Conflict Resolution Support
  • More tooling
• End User Documentation

The list above is only a small part of what AnkhSVN 2.0 brings to the table. For a better description of AnkhSVN, the new features in 2.0 and for links to downloads, please read the Official AnkhSVN 2.0 Final Release blog entry on openCollabNet.

Well, I dropped the ball. I packaged the Universal OSX Subversion 1.5.0 Binary over a week ago but I forgot to spread the news. I have gone back to my previous packaging, removing the CollabNet Subversion packaging approach used during the Subversion 1.5.0 release candidates. For those of you new to my Universal OSX Subversion offering, here are the highlights:

• All Subversion server modules. (Apache modules and svnserve.)
• All Subversion repository back-ends. (Both Berkeley DB and FSFS.)
• All Subversion network layers. (file, http, https, svn and svn+ssh.)
• All Subversion language bindings. (Java, Perl, Python and Ruby.)
• All OSX CPU architectures. (ppc, i386, ppc64 and x86_64.)
• All OSX CPU instruction sets. (32-bit and 64-bit.)
• OSX packaging complete with GUI installer.

As usual, this package installs on anything OSX 10.4.x+ and does not interfere with any of your previously existing Subversion installations, including the Subversion 1.4.4 version installed with Leopard.

I'm sure you guys are probably tired of the mundane posts but I've just been so busy recently. Not only have I been working feverishly to get AnkhSVN 2.0 out the door but I've also switched positions at CollabNet. A lot is going on and soon enough, which means when AnkhSVN 2.0 finally comes out, I'll be able to start posting good materials again. Thanks for being patient.

In an effort to keep pace with the rampant release of Subversion 1.5.0 release candidates, I have published the Universal OSX Subversion 1.5.0 RC8 binary on openCollabNet. This release is a Client-Only release. When Subversion 1.5.0 final is released, you can expect a full offering like what is offered with the latest Universal OSX Subversion 1.4.6 offering.

The release candidates are offered to give you early access to the pending Subversion 1.5.0 final release. In the event that you have issues with the release candidates, please post your comments/concerns/issues in either the openCollabNet Merge Tracking Forum or the Subversion Users Mailing List.

Sorry to be so brief, and blogging so little lately, but I have to finish getting AnkhSVN 2.0 release out the door. Expect more after AnkhSVN 2.0 releases, which will occur either the 13th of June or within a few days of the Subversion 1.5.0 final release.

As many of you know, I'm the maintainer of the Universal Subversion binary for OSX hosted on openCollabNet. When I released the last version of the binary, I quickly found out that the Subversion Apache modules wouldn't load under the default Leopard installation of Apache. The reason for this is that Apache on Leopard is a 4-way universal binary and when ran on a 64-bit CPU, Apache would run as a 64-bit application and would attempt to load a 32-bit Subversion module. The result was an error about an unsuitable image. As soon as I found out about the issue, I began devising a plan to fix the issue but I did not have access to a 64-bit installation of OSX. Well, due to the success of the OSX binary on openCollabNet, CollabNet decided to hook me up with a new MacBook and my problem was solved. Within a few weeks, since I do this on my own time, I had a new Subversion 1.4.6 build for OSX that is a genuine 4-way universal binary. This means that the new binary works on 32-bit and 64-bit version so of both Tiger and Leopard. This happens to be the only real "feature of the new binary, since the binary already includes everything Subversion has to offer. If you are new to the binary, or just need to know more about the binary before you download it, please see the original release. This link also has the download location as well. Enjoy and please remember to send feedback and/or requests to me at facilitators@svnbinaries.open.collab.net.

Well, for the first time in the Subversion 1.5.0 RC phase, I've managed to get a build up on time. The purpose of the Universal OSX Subversion 1.5.0 RC4 Client binary was to get Subversion 1.5.0 out in front of the community for those of use lucky enough to be running OSX. One of the major things you'll notice about the 1.5.0 RC4 release is that it is CLIENT-ONLY. This means no bindings, no server modules and not even svnserve. (The reason for this is that CollabNet asked me to do it this way.) Another thing you'll notice is that this release of Subversion is a 4-way universal build supporting both 32-bit and 64-bit instruction sets on both the PPC and x86 CPUs. This will mean more to you if/when the server stuff is delivered, since right now the 1.4.6 build I have out does not work with Leopard's Apache. All is not lost though. The plan is for me to rerelease the 1.4.6 binary with 32-bit and 64-bit support along with all the other goodies it usually comes with. Keep checking in as I will post here when the new 1.4.6 binary is ready for download.

Please feel free to comment on the new CollabNet packaging of the Universal Subversion Binary here.

A few months ago I got involved with AnkhSVN and as part of working on AnkhSVN, I was introduced to SharpSvn. SharpSvn is a C# implementation of the Subversion client API that has become the core of AnkhSvn. To be brief, I am very impressed with the completeness of SharpSvn, its design and well written/documented source code. To learn get more acquainted with SharpSvn, I decided to write a little Subversion Log Viewer using SharpSvn but to keep from reinventing the wheel, let me point you to my CollabNet blog entry: SharpSvn Brings Subversion to .NET. This blog entry describes my impression of SharpSvn, has a documented code snippet outlining how SharpSvn was used and also reference to the downloadable SharpSvn-based Subversion Log Viewer source code.