Today someone asked me to take a look at an Evolution enhancement that's just begging to get into trunk. Since this is a Gnome program in a subversion repository I've commenced the process of cloning the repository so I can look at the issue against the current head.

At the current rate I should have a copy of the repository by early tomorrow morning, in order to be able to start looking at it. Of course today is when I actually do have some time to spare, and I hope to be fast asleep at the time when I expect this to finish.

Presumably subversion isn't this slow for everyone, but since my latency to their repository is 300mS I'm probably on the worst end the pain, with each commit seemingly taking around a second. It sure would be nice if subversion provided some kind of chunked compression of these five-year-old commits, so I could be bandwidth limited, rather than latency challenged.

The addition of a day to the checkout of a software project must be a significant barrier to entry for anyone considering contributing. It makes it much less likely to be opportunistic.

So far I'm up to r3600 in 75 minutes. That's 75 minutes that I could have spent actually looking at the code, but now it's time for me to go and vote for me...

Well, it seems that there were few problems with the pre-release of DAViCal I pushed out last week, so 0.9.6 is out now.

The full release notes are on the wiki. The biggest change is that this release now supports free/busy using the method defined in the draft scheduling extensions for CalDAV, so it's possible to schedule meetings with Sunbird/Lightning or iCal, and possibly other clients if they support that.

Now I can concentrate on getting some paid work done for a few weeks before I start on the next stage.

Updated

After release I discovered that due to the changed behaviour of DAViCal, interoperation with Mozilla Sunbird/Lightning 0.8 was no longer working. A new 0.9.6.1 version has been released to resolve this issue.

Here are some pre-release DAViCal 0.9.5.90 (i.e. nearly 0.9.6) packages now. Since there is a lot of refactoring that has gone on under the covers here, I'll publish these packages so that people can tell me about all my embarassing mistakes, and I can correct them, before I upload them to places where they might get installed more or less automatically.

In particular if you do find problems with these, and can catch me on the #davical on irc.oftc.net during the coming week I should be able to include a fix into the real 0.9.6 release next week. If you can't get on IRC then an e-mail will also be fine.

The full release notes are here but the short version is that this fixes a number of bugs, notably one to do with importing calendars containing repeating events with exceptions. The big change is that this adds the initial support for the draft scheduling extensions to CalDAV, in particular the lookup of free/busy information.

Updated

In true pre-release fashion I forgot to actually enable the scheduling extensions stuff, so I've put new packages (0.9.5.91) on there now with that enabled... :-)

Writing free, open-source software is an incredibly public activity. Everything you do is in the public eye, and google will inevitably discover your site, and then other people will find your software, and download it, and this is a good thing. It's why you're doing it, after all, and it's so nice to receive those occasional 'Thank you for your software' e-mails. There are occasional exceptions, however.

Today's practical exercise is to demonstrate your skills responding to the annual student exercise question, like this one, following on to finish a real exchange while still retaining your sanity to the maximum extent possible. Humour will receive bonus points.

Here goes. First up, we have an e-mail arriving out of the blue which looks like this:

how to run the caldav server
in window
i have download it from the http://wiki.davical.org/

Finally, I have released DAViCal 0.9.5. Hopefully this will resolve the series of installation- and upgrade- related problems which plagued the 0.9.4 release.

Thanks for everyone being patient while this release was thoroughly tested through five pre-release versions, and especially thanks to those patient people who helped test those pre-releases.

Now if I don't get too distracted by:

• processing my GPS tracks of the last two weeks around the South Island
• Uploading my last six months worth of photos
• Making sure the kids have done their homework
• Describing the places near where I live.
• ...anything else that catches my interest

... then maybe I will be able to really concentrate on nailing the scheduling extensions work over the next couple of months...

Wish me luck!

A curiously interesting thread has sprung up on the Xorg mailing list recently regarding the lack of bandwidth the developers might have for accepting patches. Bernardo Innocenti, who hacks on OLPC stuff amongst other things, wants to get some patches reviewed for acceptance, but there aren't enough people around with the time and inclination to review and accept his work.

He did a quick and dirty analysis of Xorg LoC vs Linux LoC, to give a "X codebase is roughly 1/2 Linux codebase" (which surprised me, actually, I'd always thought it was larger) and then a similarly rough analysis that suggests that Xorg has roughly 1/20th of the developer base.

To some extent Bernardo's metrics are arguable, but the basic facts are that Linux gets the lions share of the developers. Is this what we should expect? Is this a healthy way for the free and open source software community to support the development of what I personally would like to see as the future desktop base?

Linux does a fantastic job as an OS, right now. It's been doing it for years, really, but we still need to get behind some of the differential further up the stack. And all credit to those stalwarts of X development who are shouldering more than their fair share of the burden.

So if you were looking for an open source software project where you can be appreciated, don't overlook X.

Quite a few people seem impressed with the new release of Leopard, and are now looking for a CalDAV server to use with their shiny new iCal app. Unfortunately it seems that Apple wrote this primarily to work with their own (free, open-source) calendar server, which has the side effect that it doesn't work with DAViCal.

Part of the "doesn't work" is due to DAViCal not implementing some areas of the CalDAV specification, which is fair enough. Part of it is due to DAViCal not implementing some draft extensions to the CalDAV specification, which I can also understand, since it allows them to provide some useful features that those extensions are designed to support. There also seem to be some parts of the "doesn't work" which are due to a dependence on extensions beyond either of these cases, which is a little more disappointing - and quite a bit harder to implement.

So far I have made some fixes to the first point, and some additions towards parts of the second, but as of today it still does not work. This is complicated by my not having access to a Mac. Things are looking up, however, because Tom Robinson has kindly agreed to loan me a Mac running Leopard from next week.

In order to "clear the slate" for that, I will be releasing a 0.9.2 over the weekend with the various minor enhancements and fixes that have been applied over the last week. So although this upcoming release will let you add your DAViCal account to iCal 3, it still won't actually work with it. I'm hoping that ready access to the application will enable me to correct that fairly quickly.

Also waiting in the wings (and which unfortunately won't be in 0.9.2 either) Maxime Delorme has been working on SyncML support, and is nearly ready with a patch, so we can look forward to that addition fairly soon also.

After much wading through possible names, none of which really excited me, I have finally chosen "DAViCal" as the new name for my CalDAV server that was previously called RSCDS, or the "Really Simple CalDAV Store".

In the end, I chose DAViCal because it:

• seems easy to pronounce.
• combines the 'Cal' and 'DAV'.
• returns < 1000 results on google.
• doesn't make me cringe.
• didn't have a domain name registered.

That was about the hardest part of preparing for the 0.8.1 release, and now that I've done that I should manage to make the changes to the packaging, though I have no doubt that the old name will appear in all sorts of places for a while yet.

Choosing names is an important business, and I should know that from the length of time we spent agonising over names for our children, discarding all sorts of things because they had silly abbreviation collisions (like the "Royal Scottish Country Dance Society" :-) Even then, I think we got the kids names wrong, and the big one should be called "Thumper" with the little one called "Sly", but perhaps that's just a temporary annoyance and in time the names that we registered for them will fit them better.

I also recall Grant once saying that you should never use the word "Simple" in the name of your project, and he should know. DAViCal is no longer particularly simple, although I have attempted to hide the complexity from the user as far as that is possible, and will continue to do so.

Once I get out version 0.8.1 of DAViCal I will finally upload it to Debian, proper. This version has some important enhancements to its DAV spec compliance which are going to be needed by some future versions of Mozilla, and probably other things too, so it's important to push it out as soon as possible now.

I see that there is another Wellington Summer of Code this year. I know that Catalyst didn't get involved last year because it seemed to be primarily for commercial interests, which was a disappointing contrast to the Google Summer of Code.

So it's good to see that they are sponsoring some open source projects, but I can't see us getting involved with it as it stands.

Meanwhile, of course, there are always a few openings at Catalyst for students over the summer break. That's paid work, of course, and won't always involve working full-time on FOSS projects.

Having taken time out to go to the other side of the world to attend DebConf 7 in Edinburgh, and then after spending some time with my family, I have been somewhat distracted from things CalDAV for a wee while now. There are signs that I will be able to put a few more evenings and weekends into it in coming months.

Current Status

With the release of 0.8.0 I believe it is quite a usable application for shared group calendars. We use it at Catalyst for about 80 staff and, while we're not heavy calendar users, it manages without any noticeable performance problems.

There have been an impressive number of downloads from Sourceforge, as well as substantial downloads from my Debian repository, and I believe that the program is in tens, if not hundreds, of installations.

Future Plans

In the immediate future I want to get the basic framework for querying properties about the owner of a calendar or a set of calendars. This will be used by Mozilla soon during their configuration of a new CalDAV source, and I think that Apple iCal probably uses them already. This is partly done, but it's implementation has been slowed by the necessity to refactor the handling of the REPORT method in general to make the code more modular and readable, and to support queries and properties in a more general manner.

The refactoring of the REPORT method handling is in place now, so moving on to the handling of DAV:principal objects should become fairly straightforward. I may end up with a fair bit of quiet, undistracted time over the coming weekend so if I can get in the 'zone', it may get done, and we can start rolling towards a release 0.9.

Release 0.9 will have a new name. One from the cast of thousands that have been submitted to me so far, or one that I will hastily think up in between, but the next released version will not be called RSCDS any longer.

The main goals for further into the future are:

• Maintain interoperability with clients
• Improve specification compliance
• Extend coverage to related specifications
• Documentation improvements
• Configuration improvements
• Installation improvements

Interoperability

I think that RSCDS does fairly well on the interoperability front. Unfortunately I have no access to the preview of OS 10.5, with it's native CalDAV client (though I have been told that it works with RSCDS). Likewise, other commercial CalDAV clients aren't available to me for testing either, so I have concentrated my efforts on supporting the featureset used by the various free CalDAV clients.

My initial work focused around supporting Evolution, in particular, but with the recent effort put in by the Mozilla Calendar team the primary interoperability challenge is to enhance RSCDS to support their areas of development. If I could see how the OS 10.5 client behaves, too, I believe that would help identify a few points to extend, as well as suggesting some future directions.

The best place to review interoperability would probably be at the CalConnect Roundtable 10 but I think that without some sponsorship for airfares I probably won't be able to make that. Maybe next time.

Specifications Compliance

As I read, and reread, the CalDAV (and DAV, and HTTP, and ...) RFCs the compliance with the various specifications improves. Recently I have put a lot of work into the calendar-query report, in particular, which means it now supports querying against arbitrary properties much more comprehensively. This is important because some of the client software is starting to do arbitrary queries also, and it is inevitable that queries for the classification of events, or the percentage completion of todo items will become more common.

And now I notice that there is a new version of DAV in RFC4918, though not too many changes as far as I can see. The intent of this release is mostly to clarify, and slightly to extend, primarily in order to improve client interoperability.

Coverage of Related Specifications

In terms of general calendaring activities, the biggest hole in the CalDAV specification at present is standardisation around the location of other people's schedules. The current draft of the Scheduling Extensions to CalDAV appears to address that, and a lot more besides. I expect to start working on parts of this at some point, but perhaps not sooner than I see a client which starts using it, or when it is ratified, whichever occurs soonest.

Documentation

The documentation is OK. The wiki, in particular, is a reasonable resource for resolving problems (I believe), but it would be good to have some documentation of other things.

One area that could do with enhancement is some documentation of how to check out a copy of the code, and how to provide patches back to me. Even better if other people can maintain their own trees which I could pull patches from, since we're using a distributed version control system (Git) to start with.

Configuration

The administration interface for RSCDS is OK, but could do with a few improvements to make it more usable. Really there are not a lot of reasons to be in the administrative interface, so these improvements should be relatively few, and relatively easy.

This would be a good area for someone interested in helping out to become involved, because it does not entail reading large reams of RFCs, or watching tcpdumps scroll past for the debugging.

Installation

One thing that I have done right, I believe, was to provide the software from the beginning in a packaged form to make the installation easier. Although the software is packaged for Debian, however, it has not yet been uploaded to the archive because I have been waiting for the webapps-common package to enter Debian so I can use that for configuration.

I think I have waited long enough though, so I will upload the next version to Debian for use by a wider audience.

Security

Security has always been a focus for me and I have had the code reviewed for any obvious security flaws. If any particular vulnerabilities are found they will be addressed with appropriate haste.

Retrospective

I've been working on this for a little over a year now, and I think I have largely met my goals for the project. It has certainly been an educational experience for me, and the effect of this work on other projects that I also participate in has also been valuable.

Any new open-source project is always at risk of the developer losing energy and interest, but I believe this one has made it to a state where the bulk of the infrastructure effort has been done, and there are enough interesting challenges in the future to continue to keep me (at least) working on it into the future.

The scope of this project is good, in that it is not at risk of expanding to take over the world. The intention behind this is simply to provide a back-end service for client software which should be very much Someone Else's Problem. In reality there have been times when I have had to get to grips with some of that client software in order to resolve problems, but those have by and large been good experiences.

Ten Years of Catalyst IT

It's our tenth anniversary at Catalyst this year. Since we have our company 'birthday' in the middle of the year we normally have a private party and, while that's been good in the past, we felt ten years was a milestone of some kind and we wanted to do something a little more special...

So this year we decided to set up the New Zealand Open Source Awards, which are all set to go in October. There have been lots of entries rolling in to recognise all sorts of interesting projects and unsung heroes of the revolution, but I'm sure there are still a few out there that we haven't heard of.

If you think we might have missed one you've only got 10 more days until nominations close at midnight, New Zealand time, on the 17th of August.

Nominate your favourites now in the following categories:

• Open Source Ambassador
• Contributor
• Software Project
• Use in Government
• Use in Business
• Use in Education
• Use for Community Organisations

Note that this is not a vote. All entries will be judged on their respective merits by a panel of New Zealanders with a broad technological background.

Good luck, and may the best people / teams / departments / organisations win :-)

A recent thread which started on the Debian Release mailing list caught my eye this week. I attempted to aid the migration of this thread to the debian-ipv6 mailing list, which is really a better place for this and sorely in need of controversial topics for discussion.

It is interesting how people can so blindly decide that broken things should be destroyed. Repair often appears not to be an option, even for a long-term, wide-reaching effort like this, though we are all working on open-source software!

In this case there are an unknown number of less fortunate people in the world who are located behind some kinds of broken DNS infrastructure which discards 'AAAA' lookups. Of course 'AAAA' lookups are attempts to resolve a name to an IPv6 address, and the resolver in a 'modern' libc (i.e. one from the last five years or so :-) will try to retrieve an IPv6 address before it attempts to resolve a name as IPv4 with an 'A' lookup. That is how the standard is written, so if you want to comply with the standard you have to do it that way. Other things also interfere, but this element of the specified behaviour seems to cause the most annoying and pointless whingeing I have heard.

I suppose that the people who want working IPv6 make it so, and do not have problems with this behaviour. But it seems that people who are behind this kind of broken DNS either disable IPv6, or they have to whine about IPv6 being turned on by default, and can't we please all go back to the good old days. What's wrong with IPv4 anyway? Doesn't NAT solve all of it's problems? Are we sure this new (heh!) technology is safe?

Fortunately some people are so good at making their pain felt by other people that they can get other people to do their work for them. So Mithrandir has written a nice elegant patch for libc6 so that it won't do the IPv6 lookups unless you have a usable IPv6 configuration. I've filed bug #435646 against Debian to get this included, but Aurelian Jarno justifiably wants a few people to test it a bit harder... So I've taken the original patch and tweaked it to apply against current libc6 sources (2.6-5) and tested it for myself. It works as desired, as far as I can see, when comparing behaviour with an unpatched system. The patch is attached to the bug report, of course.

Perhaps some other people out there can put a wee bit of CPU into testing this for other environments so that we can make life easier for those people with no time / inclination to use IPv6, to ensure that they don't just disable it because it is making life too painful for them in it's current form?

How to build libc6 for fun and proft

If you have appropriate deb-src URLs configured, and are running Sid, then the following will let you build a local copy of libc6 with the patch. This is probably better testing than if I just make my packages available (which are only i386 in any case).


apt-get build-dep glibc
apt-get source glibc
cd glibc-2.6.1
debian/rules unpack
cd build-tree/glibc-2.6.1
wget -Oglibc-only-lookup-ipv6-if-it-makes-sense-debian.patch http://tinyurl.com/3xzm3o
patch -p1 <glibc-only-lookup-ipv6-if-it-makes-sense-debian.patch
cd -
dch --newversion 2.6.1-1+v6 "Apply IPv6 Resolver Sanity"
fakeroot debian/rules binary


Wait a few hours for it to build...

Install...

And then confirm that this only does 'AAAA' lookups if (when) you actually have a global or site scoped IPv6 address. When you only have a loopback or link local IPv6 address then you should only see 'A' record lookups.

Step 3: profit!

Whoops! I forgot the fun bit: please update the bug report :-)

What the patch does

In my opinion this is quite an elegant solution from Tolleff. He has picked a single characteristic of the IPv6 interfaces to further refine whether the IPv6 configuration of some interface is actually usable.

With IPv6 it is much more common to have multiple addresses assigned to a single interface. Interfaces are automatically configured with a link-local address which is not globally routable, and the loopback interface is also configured with the IPv6 equivalent of 127.0.0.1 (which is "::1").

To get a usable IPv6 setup you will also end up with a more widely usable address. In most cases this will be a global address, meaning that it is (in theory) globally routable from other people who also have global addresses, or you could have a "site" address, which is the IPv6 equivalent of RFC1918 addressing.

The patch considers that for the purposes of name resolution, it will be pointless to do AAAA lookups unless you have an address of the second kind. This means that people behind broken DNS won't be impacted unless the try and set up IPv6, and people who don't try and set up IPv6 won't get the 'hesitation' while their system attempts to resolve each address in IPv6 space first.

It will also mean that when people start to enable IPv6 around them, their setup will continue to work correctly.

A few years ago we needed to introduce employment contracts for all staff at Catalyst. When we got the example contract back from our HR consultant, she had quite naturally biased it strongly in the employers favour, and as a consequence it had a very anal and lawyerly clause in it regarding the ownership of intellectual property.

This clearly wasn't going to work well in our environment so I decided to take the opportunity to try and write a clause which was fair and reasonable, which considered the likely desires of both parties, and which expressed an understanding of the sort of environment which often happens with free open-source software.

It seems that many people who are interested in working on open source software are also people who will work on (i.e. fiddle with :-) things in their spare time, but they will not necessarily consider the possible consequences of using conmpany resources to do so. I have heard of situations where employment contracts (or perhaps even government enacted legislation) will give ownership of an individual's work to their employer in such situations, so I also wanted the contract to make it clear where and how this might happen.

I would like to hear people's comments on the contract clauses which we use here. Is this fair to both parties? Have I missed something? Is the meaning clear?

Also, I need to make it clear that it is OK for people to use this text, so I hereby place the text of the following Intellectual Property clause in the public domain.

Intellectual Property

1. All intellectual property, including source code, objects and documentation, relating to work carried out while in the employment of ${COMPANY}, remains the property of ${COMPANY}, subject to the exceptions outlined below.
2. All intellectual property, including source code, objects and documentation, owned prior to joining ${COMPANY} remains your property. If you choose to use such intellectual property, including source and objects during your time at ${COMPANY}, ${COMPANY} will have the rights to their continued use in perpetuity, including access to the source code of all versions of such software in use at ${COMPANY}.
3. If ${COMPANY} asks you to do something, then we expect that while you work on that something, you will be being paid by us and we (or our clients) will own the IP. In some cases we may elect to open-source that, and may decide to jointly own the IP or make some other arrangement, but it would be at ${COMPANY}’s option.
4. If you work on something by your own choice, and on your own time, then you are welcome to own the IP, but if you use the premises or computers of ${COMPANY} to do that work then you must license it under a free, open-source license agreed with ${COMPANY}.
5. ${COMPANY} may choose to fund some part of your time to work on OSS projects in a non-directed way. ${COMPANY} will expect to own the IP for such work, and to participate in the choice of license for such code.
6. All of the above is subject to confidentiality of client information, and constraints which clients may specifically request in relation to specific project work from time to time.

Over To You

I wrote that because I couldn't find examples around the place of similar things. I guess I still see people looking for that sort of thing so I'm publishing it here with the idea of providing a seed which can perhaps grow into something else.

A few specific questions I would like you to think about:

• Are there any loopholes in this?
• Does this seem like a fair agreement?
• Is there anything missing?
• Is there any part you would like to see changed?

Then, perhaps, if we can see some general agreement on what would, or would not, be a useful standard we can encourage people to use it in their future contracts. I am hoping that through your collective wisdom I will be changing this clause in Catalyst's standard employment contract.

We managed to entice Quentin Stafford-Fraser to Catalyst on Thursday night to talk about a variety of ideas around communicating with displays, including displays over ethernet and over USB2.

Interesting ideas, and I would certainly look forward to being able to plug more displays into my laptop via USB. Hopefully he will be able to get some open-source Linux drivers released for it as well.

All round an excellent evening, and I hope Quentin enjoys the rest of his time in New Zealand.

My packages of eaccelerator for Etch caused me a problem last night when I pulled in a new security fix for PHP5 and they all stopped working so I've built some new ones against the new PHP5.

I've also added a few enhancements:

• Create the /var/cache/eaccelerator directory with appropriate permissions
• Install a default basic configuration in /etc/php5/conf.d/php5-eaccelerator.
• Clean out old cache files from /var/cache/eaccelerator

The packages are available in my Debian repository built for i386 and for amd64, with a apt sources line like:

deb http://debian.mcmillan.net.nz/debian etch awm

The repository is signed with my private key, 0x8f068012, which is fairly well-connected and which you can get from subkeys.pgp.net and many other places.

Enjoy!