Feed aggregator

A recent article from lwn.net shows ProFUSION in the most active employers for networking stuff in the 2.6.35 release cycle.  That was due to the work we did in the Bluetooth stack implementing the L2CAP Extended Features (see older post in this blog to learn about L2CAP Extended Features).  Nice!

After more than 4 months working daily at ERTM, here at ProFUSION, we have now a functional and much more stable implementation. Several potential crashes have been fixed, and missing features were added. Also the code was checked against the Profile Tuning Suite(PTS) test software. That software is the official test software from Bluetooth SIG to qualify Bluetooth stacks and the result is that right now we are also passing all PTS tests.

On the bug fixes front, beside the kernel crash fixes, a lot of ERTM behavior bugs have been found and fixed. Some of them made ERTM flow crazy, but we have been able to discover and fix them all. Obviously there might be other bugs in the code, but I haven’t found them yet. ;)

New code added: All missing events and actions from the ERTM spec were implemented, they should be working properly now. Among them we have the Local Busy handling, Invalid Frame detection, etc.

The PTS software helped a lot with the ERTM development, I’m sure that we are much more compatible with others stacks now after fixing L2CAP to pass all tests for Enhanced Retransmission Mode, Streaming Mode and FCS.

Now I’m aiming at make the code base even more stable looking on the mainlining of this new part of the L2CAP code inside the Linux stack.  All the code should be available and enabled by default on the 2.6.36 release. If you wanna help testing use the for-next branch of my git tree:

http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-testing.git

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.

I’ve been recently nominated as a WebKit committer after landing more than 60 patches to upstream the EFL port. My account was set up yesterday, and I’ve already committed some build fixes that would otherwise get dusty on the bug tracker.

This will eventually speed up the maintenance of the EFL port, as build fixes do not require to be reviewed by someone else, and thus don’t require the use of the usually crowded commit queue.

Some days ago I requested  a account to the kernel.org admins, today I finished to setup my kernel git tree there.  If you were following my git tree at git.profusion.mobi please change your remote to the kernel.org one.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-testing.git

You can also browse on the gitweb view here. =)

Last week I was officially added to EFL developers list. After contributing some patches to eina, edbus, elementary and E17 (especially to connman module), Gustavo Barbieri, who is also my boss at ProFUSION, added me to developers list giving me commit rights on EFL svn. He said me some weeks ago that the only thing missing [...]

While working with WebKit at ProFUSION, this famous XKCD strip couldn’t be more descriptive:

There are various ways to get a monster like WebKit to compile faster, such as using ccache or icecream.

CCache is nice because I’m working with the build system, so I have to rebuild the whole thing often, even if I didn’t change a single line of code: ccache saves the object files somewhere in your home and only copies them instead of compiling it again, if there were no changes to the source code.

Icecream is also nice. Forked from distcc, icecream allows to distribute the compilation to other computers: add more nodes and the compilation goes faster. Compiling the kernel was never this fun before I’ve used this thing. There are some Gentoo users at ProFUSION that probably enjoys this thing as well.

And even though Icecream offers a nice program called Icemon with some nice visualization options, it is written for Qt3 — it works with Qt4 using the compatibility libraries — and crashes often. Since I was too lazy to debug this program, I’ve decided to write my own.

Called Picolé, it is an web-based monitor program. It felt natural to do a web-based program because I was working with WebKit; also, it can be installed on a server and there is no need for specialized client applications anymore. And since I’ve been longing to create something using AJAX for some time, this was the perfect opportunity.

The user interface is pretty simple. It offers two views: Hosts and Jobs.

Picolé’s main interface (click to enlarge)

The hosts view can display all the Icecream nodes in the network either in a table, or by using a star view, similar to the Icemon one.

The jobs view displays all the jobs being processed right now, and tells the language, file name, node that asked the compilation and node where the compilation is being performed.

The server is written in Python (using webpy) and it communicates through pipes with a program, written in C++, which communicates with the Icecream’s scheduler. The reason I’m not using a single programming language is that I didn’t want to rewrite the C++ part in Python, because I am using the same classes used by the Icemon program.

I got permission to distribute Picolé’s source code, but I need to clean it up and fix some stability problems. I’ll let you know whenever this happens.

Here at ProFUSION I’m working to finish the L2CAP Extended Features introduced in the Core Specification Addendum 1 of the Bluetooth Specification. As you can see in older posts in this blog I have started that implementation by myself during the last year’s Google Summer of Code. The project was too big and I wasn’t able to finish it in 3 months.

The L2CAP Extended Features comprehends the Enhanced Retransmission Mode (ERTM), Streaming Mode, Segmentation and Reassembly, and Frame Check Sequence(FCS).

During the last month I worked to complete the ERTM state machine. All the events and its respective actions were coded. Unfortunately that doesn’t mean that it has no bugs.  Now it is time to run a lots of tests on the code to check  if it is working as specified and fix all the issues we found.

If you want to help testing just clone my git tree and enable the Kconfig option for the L2CAP Extended Features and if you have any suggestion, bug report or patch don’t hesitate in contact me. :)

The git tree is hosted here and you can clone it directly with this line:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-testing.git

I expect that soon this work will be merged into the bluetooth-testing tree and then it will be available on the 2.6.35 kernel as an experimental work.

UPDATE:  changed the git tree url.

So, today was the last day of the Embedded Linux Conference. Now, I’ll be here in USA for the Linux Collaboration Summit. It was really cool and it was amazing to meet people you are only used to chat, exchange some emails or that you heard about. Just to name some: Steven Rostedt, Greg Kroah-Hartman, [...]