I finally got around to signing the PGP keys I verified during the ApacheCon EU 2006 keysigning session in Dublin. This is good, because next week in Austin we will have another Keysigning Session. To help expedite the follow-up, I have posted the procedure and script I used to get all the verified keys signed and submitted.

Mads suggests some topics for his session about httpd on OpenSolaris for ApacheCon US 2006. Perhaps he may also talk about the NCA, whether it still exists and what role could it play with today’s httpd?

No?r?n has put up a calendar for ApacheCon EU 2006 to which you can subscribe from iCal (if you’re on a Mac). I have set mine to update once an hour in case the schedule changes.

On a slightly related note, Apache legends Rich Bowen and David Reid have started Feathercast, a series of Podcasts on Apache related topics. You can subscribe to it in iTunes by choosing Subscribe to Podcast… from the Advanced menu, and typing http://feathercast.org/?feed=rss2 in the URL box. iTunes will then automatically download new episodes as they appear.

Softguide makes available zoomable, clickable maps of many cities including Dublin. For instance, they have one of the immediate surroundings of the ApacheCon conference hotel.

meta-writeback: on
For those of us that happen to be visiting Dublin in the near future and not attend ApacheCon, the Dublin Tourism Office makes available self-guided walking tours in the form of Podcasts. Subscribe in iTunes (instructions at the bottom of the page), load some up on your iPod and walk the day away. Very cool. I wouldn’t be surprised if you could obtain the illustrated brochures that go with the audio from the tourist office, also the starting point of walk one.

I’ve been playing around with Gump over the weekend. My goal was to set up a Gump run on an Xserve box that Apple has made available to the ASF, so we get some build coverage on the platform of all the packages and projects that Gump tracks.

Gump builds and installs hundreds of software packages, and to get the maximum experience I started from scratch, by checking out the trunk of the Gump source code. Before Gump can run, it requires the presence of several native and Python packages. I found out about these by repeatedly calling ./gump run until it would actually go, installing pre-requisite libraries along the way. I don’t remember exactly what I installed, but one component (rdflib?) required Python 2.4 so I installed that as well.

Gump checks for a number of prerequisites like make, ant, maven, a .Net runtime and it’s build utility NAnt. After I had all these up and running, I had the following build result:

Then, I started adding packaged projects by finding out from the build logs which jars were missing, and downloading those from the individual project web sites. This slightly reduced the number of failures due to missing prerequisites:

However, tracing down all those packages proved pretty tedious, so I cheated. I got with the Gump guys and copied the entire package collection from one of their official instances. This got my failure count down markedly:

But wait, the failure count was down, but the success rate did not increase. What was going on? Well, most projects depended on JUnit, which just a couple of days before had introduced some JDK 1.5 only features. So, I switched the entire Gump run to JDK 1.5. I also populated the Maven local repository by hand-rolling some failing builds. Gump runs Maven in offline mode, so it doesn’t go out on the net to find jars it doesn’t have. The folks on the Gump mailinglist were very helpful getting me up and running. This exercise got me to just about the present state:

A few more failures, mostly because of failing JUnit tests, but radically higher number of successes. Tee Hee! We’re getting somewhere! I have now put Gump on an automated run every six hours, with the results publiclly available. Now if I could figure out how the Stats and Xref pages work, I’d be onto something.

The Apache httpd 2 build system expects to find a copy of the Apache Portable Runtime (APR) and its utility library (APR-Util) under srclib in the source tree. However, if an installed copy of APR is already present on the system, the build system will use that instead. As far as I can see, there currently is no way to force the httpd build system to use the bundled APR instead of the installed one. This is an insurmountable problem in situations where, for instance, the APR that came with your FreeBSD ports when you installed Subversion is too old to build httpd-trunk.

This is a problem that should be solved by that same build system: it needs to check more thorougly whether the installed APR fits the bill, and it should have an option (like –with-bundled-apr) that forces building against the included source tree regardless of what is already installed. However, I currently lack both auto-fu and round tuits to come up with a fix. Fortunately, all the httpd configure script checks for is the presence of the APR and APR-Util configuration scripts, so renaming /usr/local/bin/ap{r,u}-1-config to something inocuous makes the problem go away.

ApacheCon presentation materials are due yesterday, so I’m setting this weekend aside to work on it. Except for the Cal-UCLA game, of course. Wave at us, we’re behind the north end zone…

I’m hoping to do a more even presentation this year. Last year I ran out of time which was a shame. This year some content will move to the paper, so I can pay better attention to the stuff that remains in the talk. One thing I found myself doing last year was to get stuck in slides: I would spend too much time about minute details, forgetting the overall flow of the presentation and undoubtedly losing part of my audience along the way. Hope to clean that up a little this year. Anything I should bring up? E-mail me.

Updated mod_zeroconf to the latest version of howl last night. All the function names and some of the signatures have changed, but overall it was fairly painless. Extra bonus: got it to run on my Powerbook this morning. It turns out that the howl library that mod_zeroconf links against has some CoreFoundation stuff in it (on the Mac, presumably not on other platforms since those don’t have CoreFoundation), and neither my module nor Apache itself has any reason to link against the CoreFoundation Framework. The result is some undefined symbols when you start Apache.

I tried to force mod_zeroconf to link against CoreFoundation by defining some variables in the source, but that just seems a can of worms. The cheapest solution seems to be to simplyLoadFile /System/Library/Frameworks/CoreFoundation.framework/CoreFoundationin httpd.conf, before the LoadModule line for mod_zeroconf. This will be superfluous when I get the module to work with DNSDiscovery which would be the preferred interface on the Mac anyway. I hope to some day have the module work with either one as a configure option.

Installed the perl-framework today on my Panther G4. Couple of observations about the modules that back it up.

This morning, I’m installing the httpd-test/perl-framework on my G4 tower in anticipation of the second release candidate of httpd-2.0.49. If I am done earlier than the RC, I may start on RC1 anyway.

As many know, running the perl-framework test suite for httpd requires installation of a bunch of Perl modules. The framework tends to gracefully skip tests if the corresponding Perl modules aren’t installed, but that is not the purpose oft he framework, is it?

br /Turns out that perl-framework/Apache-Test/lib/Bundle/ApacheTest.pm has the entire list, so you can just follow that in the CPAN shell. I usually do not install the entire bundle at once, because I have seen installations fail and my attitude towards the Perl module installation base is one of respectful fear.

the (newishly added, from my point of view) module IPC::Run3 fails one test. I force installed it anyway.

The HTTP::DAV module is not listed, probably for good reason. As the name implies, it is necessary to run the tests against mod_dav. It turns out that HTTP::DAV depends on XML::DOM, which lists as prereqs XML::Parser::PerlSAX, XML::Parser and XML::RegExp. XML::Parser::PerlSAX depends on XML::Parser, so it would make sense to install the latter first. Everything depends on Expat.

Expat is obtained from Sourceforge and installed in /usr/local. It spews a ton of warnings during compilation, and its DejaGNU tests bomb out spectacularlly, but its presence makes XML::Parser build and satisfies its tests, so I’m happy. Subsequently, XML::Parser::PerlSAX fails one test, which makes me 97.78% happy. The other packages install without a hitch.

Oh, let me record the following for posterity, so that when I forget, again, I can go back to this Blog: to open the hood of a 1966 Ford Mustang, grab under the radiator grille, below the galloping horse icon, and pull the lever forward. Oil (a lot of oil) goes into the top of the block, where the hose from the carburator attaches.