Raphael Kubo da Costa

In case you use Icecream (the distributed compile system which makes your coworkers' machines compile KDE for you ) and happen to be using a glibc >= 2.11.2, you might notice that you are not able to send compilation jobs to other machines while still being visible to the scheduler and receiving jobs from other hosts.

It turns out that some commits to ldconfig made the script which created the environment sent to all other clients not work as expected because of a missing directory.

So until a new stable Icecream release is made (the current one is 0.9.4), make sure to apply this commit to your package to keep things running smoothly.

Besides maintaining Ark, I also spend some of my KDE time reviewing and applying patches for other projects as well. This weekend I had some free time, which was dedicated to applying some Kopete patches and pushing some KDE-FreeBSD patches upstream.

So let's start with Kopete. My initial intention when subscribing to the kopete-devel mailing list was to work on new features and get in touch with the development community in general. Even though in the end I haven't written code for Kopete myself and have replaced it with Bitlbee, irssi and GNU Screen on a remote server, I still comment on the list, help moderate it and review patches whenever I can.

Actually, "reviewing" may be too strong a word here -- since I've never digged too deeply through the code base, I usually just give an outsider's look at the patches, watching for const iterators in foreach() loops, giving hints about what patches should be applied after trunk is unfrozen and other things like that. Since there aren't many active Kopete developers, even these small actions end up helping the development.

Yesterday I went through some open review requests for Kopete, checking which ones could finally be committed now that trunk is once again open for feature commits, asking some request authors to close their reviews as Submitted or simply pinging people about pending reviews. Ralf Haferkamp's patch, for example, implements wishlist item 97998; Manuel Luitz's one connects and disconnects an account when the IdentityStatusWidget is double-clicked. Finally, Igor Poboiko's big patch brings the translator plugin back to a working state after who-knows how much time -- I've never used it myself, but it apparently fixes no less than 6 bug reports! The patch does add some new strings, though, so it will only make it to KDE SC 4.6.

On the FreeBSD front, Alberto Villa asked me a few days ago to take a look at some patches to kdeadmin's KNetworkConf and KDM that were lying around FreeBSD's ports tree. I asked him to forward the KDM patch to ossi (who has already given him some suggestions of improvements), but the KNetworkConf ones were fairly simple -- even though the application is quite old and mostly unmaintained, it's good to keep things such as correct FreeBSD release detection and routing information loading upstream.

P.S.: No, I'm not at Akademy

When I started blogging in the end of last year, I thought I would write much more frequently than I do: if only I had better marketing abilities, there would certainly be many more posts about what's going on the Ark, KDE's beloved archive manager, and KDE on FreeBSD fronts. At least I seem to be in good company in the occasional bloggers department.

Over the last few months (actually, for the last 1 or 2 release cycles at least), Ark has not received many feature additions (half of our open bug reports are wishlist items -- I'll never get tired of saying that many of them are quite easy to implement and are good junior jobs in case you are looking for a way to get into KDE development). Lack of time from both Harald (who, by the way, is finally getting his university degree one of these days) and me is not the only explanation, though: this may sound weird, but whenever I do have time for some KDE hacking, I prefer fixing bugs to implementing new features. The last weekends have been quite productive in this regard.

One of the most useful things for bug fixing (and also for preventing old bugs from showing up again) are unit tests. Ever since I started contributing to Ark's development, I thought it would be nice to have unit tests both for the code code (curiously called Kerfuffle) and the plugins, so that we can be more (even though not 100%) sure that the code behaves the way we want it to. I started writing some unit tests for Ark a few months ago, but they didn't look that nice and I stopped working on them shortly after starting. Two weekends ago I had some free time, so I started playing with them again. I wrote a dummy plugin which reads archive entries from a text file in order not to depend on the existing, real plugins, which may have bugs on their own. It lasted for only one week, as the next weekend I scrapped it in favour of a JSON-based format which lets one specify more archive properties in a concise way. Big kudos to the QJSON folks for their work (this also means that you need to have QJSON installed in order to compile Ark's unit tests). The total amount of tests written is still small, but I'm quite happy with them and hope to keep writing more of them as time permits. I can already say that the unit tests have helped me fix bug 225426, which was a regression that hopefully will be detected as soon as I write code while being distracted again.

Speaking of bugs, this Saturday I was able to close 3 bugs in a few hours (and mark 2 or 3 as duplicates too): bug 242071 prompted a cleanup of the RAR plugin (even though the RAR file format is unfortunately proprietary, unrar's source code is free (as in beer, though) and helped me understand what was going on), and bugs 241967 and 221551 were one-liners. The latter had many duplicates and seemed to be causing some headaches to users who were extracting many files at once (by the way, if you have a multi-volume archive, you do not need to select all of them in Dolphin to fully extract it, just select one of them).

We currently have 88 open Ark bug reports, 21 more than the 67 we had when I wrote my last post. The most serious ones, which are crashes related to closing Ark before finishing one operation (one of which has 90 votes and quite a number of duplicates), demand more free time to be fixed correctly, but it will certainly be easier to fix them as we progressively have more of our code covered by tests.

On a final note, if you want to help write and run our few unit tests, do not forget to pass -DKDE4_BUILD_TESTS:BOOL=ON to CMake when building Ark.