Category: Maemo

Igalia Assembly… Or why I love working here…

As many of you know, I am a worker, and one of the initial partners of Igalia. This company is organized following an assembleary model. Every partner has the same rights and power of decission. And we want all workers to become partners in a medium term.

The main representation of this assembleary model is the Assembly itself. It’s a periodic meeting (one each two months) with all the partners discussing and taking the strategic choices of the company. We’ve held 43 assemblies in the history of Igalia, the first one in September 2001.

No bosses at all, just all of us being partners, with the same responsibility. This is fair, and one of the better things of being a member of Igalia team. And this makes everybody contribute with their best efforts and ideas.That’s one of the main reasons I love working here. And other main reason may be how much extraordinary and good people my partners are.

Guademy CFH (Call for Hacking!)

This is a very interesting event that will happen this year. It stands for Guadec + aKademy = Guademy destroy myths. As the event web states, Guademy is a meeting where GNOME and KDE developers share working sessions with other people interested in collaborating with both projects. It will be in March in A Coruña (Galicia – Spain), and is being organized by GPUL. Good idea and best wishes!

Snes emulators and touch screens

Last week I’ve been playing a bit with some emulators, in order to try to get one of them running in Maemo. The one I’ve been testing more deeply is Snes9x. It compiles without too much problems, and it should be easy to make it run a confortable UI with some hildon work.

But there’s a problem. Nokia N800 and 770 haven’t got too many hardware buttons, and a good Super NES emulator should get 6 fire buttons plus start and select buttons. My idea would be add support for showing buttons in the screen replacing some hard buttons in the screen, in order to use the touch screen for providing 4 fire buttons. Unfortunately, I suppose the main drawback of this idea is that AFAIK the touchscreen of these devices can’t handle more than one “touch” simultaneously :(. Any idea about this?

The other problem will probably be hardware performance, but I didn’t test the emulator in the device yet.

Long time since last post. Lots of news had happened, so I will not bore you with lots of them. Anyway, some interesting remarks:

• Here at Igalia we’ve been doing lots of interesting things last months. A very interesting project is our Gnome Handhelds project, which has been awarded with public founding from Xunta de Galicia.
• Nokia has released a new device based in Maemo platform: the n800. FIC is releasing soon the Neo1973, with the OpenMoko. Very promising devices. I don’t know yet about the OpenMoko platform, but it’s based in Gtk. About the Maemo platform, I’ve been playing with the bleeding edge distribution and it’s really interesting. The kind of toys I would love to receive as a present. Congratulations to Nokia and FIC!
• We’re hiring! We’re looking for smart hackers, willing to work in free software projects. Galicia is a lovely place to live, and much better when you work in what you love.

Last month I’ve moved to a flat in Vigo with my girlfriend. Lovely city, pretty flat and very nice to be living with her! We’ve been very busy with the move and preparing our wedding. It seems next months won’t be more relaxed…

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