José Dapena blog

Want a better Maemo bugzilla!

You don’t realize how wonderful Gnome Bugzilla is till you find some other that needs a bit of love.

As I’ve told in my last post, I’m hacking a bit in Maemo platform, and in particular in Sardine Distro. I found some issues I wanted to report, and implemented some patches for them. So, I decided to go to Maemo Bugzilla. But the experience was far from optimal. I’ve sent two mails to maemo-developers mailing list (problems with categorization, suggesting a bug template).

Build brigade IRC meeting

We need to decide what to do in Build brigade next month. Iago Toral has proposed a meeting for next Monday at 16:00 UTC, in #build-brigade IRC. Everyone interested in Gnome testing or continuous integration, is invited. I hope we’ll get at least one meeting per month, but let’s talk this Monday about this. You can read more about the meeting in Iago’s blog and meeting proposal in mailing list. See you there!

Long time without writing, so let’s retake it. Last weeks I’ve been playing with Maemo and Nokia 770. Very interesting platform, very familiar for those (like me) with some background in Gnome SDK.

The device is fantastic. Definitely. Small, light, and with a good screen. But overall, as much powerful as free software is. As this was my main interest, Maemo as a free software based device, I’ve been taking a look at the development platform. Nokia has done a good work, not only providing full access to a Gtk/Gnome based technology, for developing applications, but also offering their platform contributions to the community.

Interesting points:

• Very similar to Gnome development. Starting to develop Maemo applications for someone with Gnome SDK background is a very very small step.
• Scratchbox. The project is interesting, and it makes very easy debian-based development of software. I can try very dirty pieces without breaking my PC environment.
• Sardine distribution, to let you work on the bleeding edge platform.
• Good tutorials for startup (see Maemo 2.0 tutorial and Scratchbox tutorial to start developing).

Drawbacks:

• Many pieces of the software inside the real device are not available as free software (yet?). Main example is the web browser (Opera), but there are more.
• A bit slow. I suppose that time will let Maemo be faster and lighter (it’s still a very young platform, so there’s a long way to run). We can expect to see heavy improvements in next months and years, and some of this work returning back to Gnome to make it also better).
• It’s _VERY_ difficult to find an RS-MMC (recommended for dual boot procedure). I’ve walked lots of shops in order to get one, and I’m still waiting for my order.

Of course, I’ve sent my first bugs and patches mainly related with file selection (filters bug, proposal for filters UI). I’ll comment more interesting things I find next days.

Once Build brigade puts in production the Buildbots for projects, with testing support, we’ll get an automated way to run unit tests of all projects in Gnome umbrella. And you, developer, will love to know when your tests fail to get them fixed asap.

But, to do this, you should implement good tests. How to do these tests? A good unit testing framework is Check.

If you need an example: currently, Iago Toral is developing unit tests for gtk+ with it. You can browse his work or read his post to know about them or ask him at #build-brigade. It’s an interesting work, and accepting and extending these unit tests in mainstream gtk+ would be great for gtk+ quality.

Two main goals in your tests:

• The first goal would be adding tests checking known bugs. If you detect a bug and don’t want it to be regressed you can add a test to know if it happens again.
• The second goal is trying to run as many code paths as you can, in order to be sure they behave as expected, and don’t segfault. Code coverage tools helps you to do it. You can view current coverage of these gtk+ tests.

Wouldn’t it be great that you know your new features don’t break other code behaviour before committing? Just run make check and you’ll begin to be more confident about that.

Of course, these notes apply directly only to C projects. But  replace Check with your favourite test framework for your language .

Yesterday I’ve deployed my jhbuild buildbot prototypes:

• Fisterra buildbot: it compiles the CVS HEAD for Fisterra Distribution and Fisterra Garage. It also has some unit tests integrated in fisterra-base. You can check coverage of last results.
• Gtk with unit tests buildbot: this is a playground to add unit tests implemented with Check in gtk+. These tests have been developed by Iago Toral (read his post, browse his tests).

Code coverage measure consists on counting the portion of code being executed by a set of tests. It gives a quantitative measure of the paths of code covered by our tests, and it’s specially useful for unit testing. One of the purposes of Gnome Build Brigade is adding this kind of measures to the continuous integration loop. This way, we can encourage developers to increase their marks, or even make parallel teams add new tests to the core libraries of Gnome. This would make Gnome more reliable, I think.

Then, if you want to polish your library or project, please add some pretty tests. If you want help on Check, just contact us in #build-brigade gnome irc channel. Better quality in Gnome deserves this!

PS: it seems the link to Iago Toral’s test is not working (Bonsai seems to get in troubles when a module has some symbols like +). You can get the source of the tests in our CVS (CVSROOT :pserver:anonymous@cvs.igalia.com:/var/publiccvs MODULE gtk+).

JHBuild Buildbot scripts reporting

This week I’ve been adding some new features to my JHBuild Buildbot scripts, in order to get better reporting and information for projects:

• Implemented a custom Sources changes fetcher for the gnome-cvs-commits mailing list. This code fetchs the mails from a Maildir, and assigns them to the projects, filling the changes column. Now it only matches the projects with the same name of a jhbuild module, but it should be extended.
• Now you can set a list of email addresses to get the build status, using the buildbot MailNotifier. You can also set an IRC bot for each project (establishing an IRC server, channel and nick), using the buildbot IRC object). It’s too much simple, and I like more the IRC bot Thomas is using for gstreamer.

Fisterra and JHBuild

In order to get a smaller testing platform for my jhbuild buildbot scripts, I’ve decided to target on Fisterra project. To do this, I had to work a bit on it in order to make it easy to compile in a JHBuild environment:

• Fixed a lot of warnings compiling fisterra in gcc4. Now gcc4 is more strict on compatibility between signed and unsigned types. Then, I had to add a lot of type castings (mainly due to libxml2 and libgnomeprint).
• Improved the code generator scripts, and removed specific prefix dependencies.

And yes, now I can run Fisterra in a JHBuild environment. The work has been uploaded to the CVS (bonsai of fisterra-jhbuild). I’ve uploaded instructions in Fisterra CVS web. The available modules from the scripts are:

• fisterra-base: the main library, including a Postgres/libgda based persistence layer, a client-server Orbit based communication system, a powerful listing system, and a Gtk-based client library.
• fisterra-bmodules: implementation of some business objects (actors, documents, tax, payments, …) in fisterra framework, both server objects and client widgets.
• fisterra-distribution: a Point-of-shell app built on top of fisterra-base and fisterra-bmodules.
• fisterra-repair: an app to manage car repairing garage companies, also built on top of fisterra-base and fisterra-bmodules.

Yes! Today, 21-September-2006, Igalia celebrates its 5th anniversary!

An example of party at Igalia office (year 2003 )

Buildbot

Yesterday I’ve ended the documentation and upload of my JHbuild buildbot integration scripts. I’ve published a manual (jhbuild buildbot manual). With this bot, I’ve got:

• All Gnome 2.16 modules compiling in Buildbot. The configuration files use the JHBuild Gnome 2.16 moduleset. My scripts are easily configurable to use other modulesets.
• There’s a preliminar support for tests and coverage. Currently, it runs “make check” for all Gnome modules supporting this Makefile rule, and then it runs lcov to explore the code coverage of those tests.
• I’ve done some tricks to avoid a huge load produced by buildbot managing and compiling too much modules.

This week I’ll try to get this server in production (currently I’m running it in my PC). There’s a CVS with the scripts, and you can browse them with our Bonsai.

Fisterra

These days I’ve also been preparing some patches for Fisterra framework and apps to get them easily compiled in JHBuild. I’ll try to merge the patches this week. They fix compilation with gcc 4, and make it easier to get the modules compiled in a non-standard prefix (as JHBuild requires).

5th aniversary of Igalia

Next thursday Igalia will be 5 years old. Fine to be such a long time with these guys .
Weekend

Last saturday, I’ve gone with my girlfriend to an interesting restaurant in Vigo (Rosalia de Castro street). Tasty food (in special the hot chocolate fritters, or the veal tenderloin with strawberries and cheese sauce).

Thanks to Thomas for giving me this clue to get coverage reports with code compiled with gcc 4.x.

In order to get coverage logs, CFLAGS should include -fprofile-arcs -ftest-coverage (and preferrable to get also -O0). It’s what the gcc manual says. It was enough for gcc 3.x. But in gcc 4.x it may not. When you link, you can get this error:

hidden symbol `__gcov_init' in /usr/lib/gcc/i486-linux-gnu/4.0.3/libgcov.a(_gcov.o)

is referenced by DSO

The problem seems to be caused by the linker. In theory, adding -ftest-coverage should imply linking gcov automatically. But it’s not true, at least in my case. The solution: adding -lgcov to the LDFLAGS. Finally I have coverage reports for my gcc 4.1.2 compiler.

CFLAGS=-fprofile-arcs -ftest-coverage

LDFLAGS=-lgcov

First, hello to planet.gnome.org! Thanks to jdub for making it possible. Briefly, I’m working at igalia as a member of the Gnome technologies team, and currently I’m devoted to continuous integration and testing tasks under the umbrella of the Build brigade group. Hackergotchie is comming up, stay tuned.

Back from holidays. Some notes:

• I’ve been for nearly a week in Portugal (Lisbon, Fatima, Castelo Branco, Alto Douro, Viana do Castelo, …). Very nice country… and food.
• Nearly one month of relax far away from a computer in Vigo. I did some local tourism there (visited Gondomar, Mondariz, Villasobroso, A Cañiza, and some nice places in Vigo like Monte Alba, or the boat restaurant in the harbour).
• The worst thing was the terrible forest fire wave in Galicia. In Vigo I couldn’t even see the sun for a week, as all the sky was covered by a dense smoke cloud (photos in flicker Vigo Harbour, Rande Bridge).

But now I’m back. These days I’ll try to go on with the efforts around Buildbot and jhbuild integration:

• I’ve got Buildbot running with jhbuild, as I told in my last post.
• Buildbot is not designed for this use, and it’s a problem because I want to provide better aggregated views (build status of a slave, last builds of a module, information about an specific module, etc). I’ll try to improve a bit these views.
• I need better unit test support in buildbot (specifically I would like to integrate coverage reports as Thomas has done in gstreamer buildbot, and better unit tests log reports).

This week I’ve been playing a bit with buildbot, in order to complete my hack to get gnome jhbuild integrated with it. And it’s running now. I’ve uploaded a patch to buildbot project webpage (buildbot jhbuild support patch in sf).

The ideas of the patch are the following:

• Each module in a jhbuild module set gets a factory
• The factory can be used to get builders in many slaves. Then we’ll get a builder for each factor and slave.
• An scheduler for each builder. In my case the first module uses a Periodic scheduler, and the others are Serial depending on the previous module.

I added an example of a configuration file for buildbot master to get this working. Now I’m running gnome jhbuild in my machine. Saddenly the UI of buildbot does not scale very well for large sets of modules .

A capture here: