Mandriva 2009 InstallFest, and what I've been doing lately

We are running an InstallFest for Mandriva 2009 in November. If you want to take part, write in! All the details are on the Wiki page.

As well as desperately trying to keep up with all the post-2009 community stuff - forums are busy, and I'm following up on reviews all over the place - I've been working on a bit of development stuff lately. Yesterday I fixed a few bugs: I fixed sound-scripts to mute Analog Loopback by default, which should resolve a problem many people have seen on 2009 where they hear an unpleasant continuous noise over their headphones / speakers. Unfortunately the change doesn't happen automatically following the update on an installed system, but it will be fixed on future installs if the update is installed at install time. If you're suffering from this, just run a mixer and mute the Analog Loopback channel.

Also fixed a rather interesting bug in curl. Someone reported that, when you're running with Turkish localization, the Control Center doesn't display any icons. Thierry tracked this back to webkit - which, from 2009, is used to render the Control Center. From there, Thierry and the webkit developers were able to trace it all the way back to curl. webkit uses curl to 'retrieve' the icons via the file:/// protocol. This protocol turns out to be broken in curl in Turkish locales, because of a notorious - in very select circles - idiosyncracy of the Turkish language. In Turkish, the letter i is not the lower case of the letter I. So POSIX standard string case comparisons on strings containing the letter i break.

Fun bug, eh? :)

Once this was eventually all figured out and reported to the curl developers, they fixed it (by implementing a custom string case comparison function which works for Turkish). However, we were still left with a problem: backporting the fix to Mandriva, which uses the latest stable curl release, obviously. Unfortunately, curl uses CVS for revision control. There's one giant problem with CVS (from the point of view of a maintainer of a package whose upstream uses CVS): it doesn't track patchsets.

What does that mean? Let's take this case as an example. To fix this bug, the developers introduced a new function and then used that function throughout curl instead of the standard string case comparison function. So to fix this one bug, over a dozen files in curl were touched. This was all done in one CVS commit, of course.

In modern revision control systems - anything from Subversion onwards, basically - this kind of change is easy to isolate. A single commit across multiple files is a 'patchset' and is easily exposed by the RCS. In SVN, for example, no matter how many files were touched, it's just one revision. You can easily use svn diff -r to generate a patch which covers every file that was touched. It's similarly easy in git and everything else modern.

But, cvs doesn't have the concept at all. CVS just tracks individual files. Even though they were all touched by a single commit, as far as CVS is concerned, they're all different changes. All it can tell you is what was changed in a given file between versions.

Just as I was contemplating the ugliness of sorting this out manually, I thought SURELY someone else had fixed it before, and hit Google. Fortunately, I was right. (It's an invaluable rule for lazy people that, before doing any kind of dull, menial task, you should hit Google and see if someone's written a tool to do it for you. Frequently, they have.) There's a tool called cvsps which handles exactly this situation. It basically logs the entire repo you're working on, and figures out the patchsets from the log. Then you can use it to generate a patch across an entire patchset.

Phew.

That just left me with the fun task of combining the three sequential patchsets which made up the change, and re-diffing them for the differences between current CVS (where the patch was written) and the current stable release (which is what we use). A measly three hours later, I had a working patch. Which, if you're Turkish and have a burning desire to see icons in MCC, you can grab from /main/testing . The maintainer's life is ever interesting!

Aside from that, I also fixed a longstanding ical bug, kinda accidentally. I'm working on gradually migrating Cooker to Tcl/Tk 8.6, the upcoming new major release. I'm doing all this privately on my own system as if I just landed Tcl/Tk 8.6 in Cooker then worked on all the Tcl-based packages afterwards, it'd break them all. So, I was adapting ical for Tcl 8.6, and noticed quite a lot of functions didn't work, apparently because Tcl now doesn't like variables of the form foo(done) , thinking they look like array references or something. So I just changed all variables of that form in ical to foo_done instead. And lo, it worked. Having done that, I came across a bug filed on the exact same issue a few months ago, which I'd previously just bumped upstream. So it turns out not to be a Tcl 8.6 issue at all - my guess is that the change was made in Tcl 8.5. So I kicked the fix out as an update for 2008, 2008 Spring and 2009. So the world's three remaining iCal users will now find lots of bits that didn't work before, now do.

Well, just thought I'd do a random snapshot of maintenance work. :) All maintainers for all distros are doing things like this all the time, I just thought it'd be fun to write about it once in a while. And it makes a nice change from community work.