José Dapena blog

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