After asking the KDE e.V. for funding, I can now finally say I'm going to the Platform 11 sprint in June and to Desktop Summit in August.

I would like to thank the e.V. (hi there Claudia!) and everyone involved in organizing both events for making these trips possible. Besides being my first international trips, these are going to be my first plane trips ever too :) I plan on taking a few hats with me to Randa and Berlin, in hopes that they can provide valuable contributions: my KDE developer hat (kdelibs and kdeutils), my KDE on FreeBSD hat (there are even going to be two of us there) and also my buildsystem hat.

Last but not least, the obligatory "I'm going to" images, made possible by KolourPaint -- as you can see, my work as an artist is heavily inspired by the master Paul Adams:

Update (2011-04-22): Credit where credit is due, the original awesome "I'm going to" artwork was created by Paul Adams :)

A few days ago, Alberto Villa committed some changes to the KDE on FreeBSD website: it is now using the Chihuaha framework, which means it looks a lot more like the rest of the kde.org websites. As noted in the commit message, many thanks to the KDE on Windows webmasters, since Alberto originally got the code from their website.

As for myself, I've recently started playing with the KDE conversion to git. The kdeutils conversion rules are shaping up nicely, thanks to the #kde-git folks who've been kind enough to always answer my questions. To get my feet wet, I decided to try converting the KDE on FreeBSD repository from SVN to git, since its history is much smaller and simpler than kdeutils'.

So after spending a few minutes writing the conversion rules and waiting for some feedback from the other KDE on FreeBSD guys, I filed a sysadmin bug report to start the conversion.

Thanks to toma and neverendingo, things went pretty smoothly, and freebsd.kde.org became the first website to have migrated from /trunk/www/sites, and we're now on /websites/freebsd-kde-org. :)

Yesterday, I moved KBugBuster from trunk/KDE/kdesdk to tags/unmaintained/4. For those unfamiliar with it, it is/was a frontend to KDE's Bugzilla, so that you could interact with it without a web browser.

Unfortunately, KBugBuster had not seen any bug fix or feature commit in several years, and did not work at all -- the URLs it used to communicate with KDE's Bugzilla were wrong to start with.

Personally, I find the idea of non-browser frontends to our bug tracking system very interesting (I seem to belong to the shrinking group of people who prefer non-web-based alternatives whenever they exist, even when we are talking about something as non-fancy-web2.0-blingy thing as Bugzilla :) ).

Some time ago, Harald blogged about Deskzilla, a Java-based Bugzilla GUI. Even though they have granted a site-wide license for us to use with our Bugzilla installation, Deskzilla is proprietary software and the fact that it is Java-based does make it feel like it is not properly integrated with the rest of my desktop.

I also remember some people worked on a KBugBuster rewrite in Python some years ago, but it has never left our playground, which means it is still very preliminar work.

So until someone steps up to maintain KBugBuster, it will not be present in KDE SC 4.6.0 or in any further release.

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.

So let's talk about what's going on in the Ark land.

Some time ago, Lydia blogged about raising the number of bug reports marked as junior jobs on Bugzilla. I've done my part, and currently there are 12 Ark bug reports listed as junior jobs.

If you have some (little) experience with C++ and Qt, fixing a junior job is a very good way to become part of the KDE community: junior jobs are usually easy to fix, you delve into the art of reading and understanding other people's code and, of course, you make KDE better with your contributions! What's more, you get the feeling that you're also part of our community.

Despite being about 12 years old, Ark, KDE's file archiver, does not have a huge code base, and it's fairly easy to understand its source. Most of the bugs marked as junior jobs involve writing support for more file formats (such as RPM), improving the error messages displayed to the user or implementing some easy wishlist items. But that's not all: as I write this blog post, there are 67 open Ark bug reports: only one of them is a more serious crash, and I'm sure there are many other report there which are not marked as junior jobs but are fairly easy to fix or implement.

Take a look at our bug reports, choose one or more you'd like to fix. You can then attach the patches to the reports themselves, mail them to the kde-utils-devel mailing list or send them directly to me. And remember that if you ever get in trouble, there's plenty of places you can look for help: TechBase, the API reference, LXR, the kde-devel mailing list or the #kde-devel IRC channel on Freenode.

Happy hacking! :)

Hi there. In order to keep the tradition, an introduction in this first post. I'm Raphael Kubo da Costa, a 20-year-old Computer Science student at State University of Campinas, Brazil, and also part-time employee at ProFUSION Embedded Systems (a very nice place for any free software developer, I'd say).

My first contact with KDE as a developer was in 2006 when I sent two small patches for Konversation. Curiously and frustratingly enough, when I started university in 2007 I found myself with much less time to dedicate to my own free software interests than before -- even though I did to go to the International Free Software Forum that year and happened to be one of those "new and interested developers" to whom aseigo showed off the soon-to-be KDE4.0 desktop on the exhibition floor. ;)

Since the beginning of this year I've been contributing to KDE in a few different fronts: I do some occasional bug triaging and commits to kdelibs, but most of my KDE time is spent maintaining Ark, our old and beloved file archiver, with Harald and helping the KDE-FreeBSD team (I'm not a full-time FreeBSD user, although I'm writing this post directly from FreeBSD 8.0-RC3). So expect me to write more about these activities in the future.

Now let's try to make this post a little less "hello planet-ish" and talk about Ark, KDE's file archiver which lives in kdeutils. I believe it's one of the longest-living programs in KDE (the first commit shown by svn log is revision 12097, which was actually a CVS commit and dates back to the end of 1998). It has survived our four major releases and has had quite a few different maintainers (curiously enough again, most of them were Brazilian).

So what's the state of Ark today? As I write this post, Ark's bug count in Bugzilla is at 72, which I consider a small number to be honest. However, we have been mostly in bug fixing mode for at least a few months, and some bugs need pretty big changes in code to be properly fixed. Being a university student, working (even when it involves using Qt) and also having a life means I don't have that much time for big changes at the moment, and neither does Harald, who's also losing his hair to graduate from university.

I don't want to end this post in a negative mood, though. So my dear reader, you have been watching the KDE "scene" for some time, you would like to contribute and you don't know where to start. Well, Ark needs you! Despite its age, Ark has a small code base, and both Harald and I are (presumably) nice guys and we are more than willing to help you. And you, my dear reader who already contributes to KDE, how about doing something completely different? :)