No Inspiration

Going to FOSDEM!

2012-01-31T10:24:00.000+01:00

This is this time of the year again, FOSDEM will take place in Brussels next week-end. This is one of my favourite free software event, lots of interesting talks, lots of interesting people, and lots of energy everywhere. This year, it looks like it will be the best FOSDEM ever! More devrooms, more than 400 talks, more everything!

I've helped again organizing the crossdesktop devroom. Among these talks, I can only recommend the gnome-boxes presentation that Marc-André and Zeeshan will be giving :) While I'm at it, here are a few more shameless plugs: Hans de Goede will be giving 2 SPICE talks in the Virtualization devroom, one general presentation of SPICE, and one where he will describe the USB redirection support in SPICE. And Alon Levy will present his work to interact with an X server through SPICE without using a virtual machine.

Last but not least, there will also be a GNOME booth with some goodies...

See you all there in a few days!

Unpacking Boxes...

2012-01-23T12:54:00.000+01:00

For the impatient people running Fedora 16 but who still want to get an aperçu of Boxes, today's your lucky day! I set up a preview repository with all the needed package to install Boxes on Fedora 16.
If you want to try it, download this file to /etc/yum.repos.d and then run
yum install gnome-boxes && yum update

To go back to your previous setup, you can either use the convenient yum history, or remove /etc/yum.repos.d/gnome-boxes-preview.repo and use
yum remove libvirt-glib && yum distro-sync

Keep in mind that this is a new application still in heavy development, so you're likely to find bugs and missing features. But I'm sure you will enjoy it nonetheless :)

Feel free to join us in #boxes on irc.gnome.org if you have any issues, or if you just want to chat with us.

FOSDEM Crossdesktop devroom

2011-12-16T16:03:00.001+01:00

GNOME, KDE, XFCE, ... will be present at FOSDEM this year in the crossdesktop devroom. The call for talks has been out for a few weeks now and the deadline (December 20th) is quickly approaching, it's next Tuesday! So don't delay your talk proposal any further, just email the crossdesktop devroom mailing list now :)

Talks can be specific, such as developing GNOME application with Vala; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2011 schedule might give you some inspiration.

Spicy apples

2011-06-17T16:49:00.009+02:00

It has been a few months since I've been hired by Red Hat to hack on Spice, and I realized I haven't blogged as much as I should have :)

Introduction

First, let me introduce Spice quickly. Spice is a protocol which then gets implemented in clients such as Vinagre (using the spice-gtk widget) and in servers (QEMU or the experimental X11 driver). Using this protocol, the video, sound, keyboard, mouse inputs and ouputs can be abstracted away from a virtual machine. This means you can run a Spice client application on one box to get the display of a QEMU virtual machine running on another box. Or you can have a big server running dozens of virtual machines, and connect to the VM you're interested in from your laptop. Or you use it in a VDI setup where you'll have N different PCs connecting to a single server running N virtual machines.

One of the thing I've done during these few months at Red Hat is to look into building a Mac client for Spice. Indeed, so far we have a linux client (as well as a GTK widget if you want to embed Spice in your applications, a Windows client, but nothing on Mac OS X. Since I was the only one in the team with a functional OS X install, I was volunteered to look into this port ;)

The long way toward Vinagre on OS X

I started by building the gtk+ OS X port. Using these build instructions, it was quite straightforward even though it took some time since there were a few bugs to fix here and there in the stack. Then I realized I needed gtk3 and that I had only built gtk2, so I started again, and fixed some more bugs (the glib maintainers really didn't want me to succeed :-) )

Once I had gtk-demo running, it was time to start thinking about my real goal, getting spice-gtk and vinagre to compile. Luckily, I had made a jhbuild moduleset for these, which I could reuse (after adapting it) for the OS X build since gtk-osx is using jhbuild too. This way, I could focus on the real porting work. The easy bits were tweaking spice-gtk build options to use gstreamer instead of pulse-audio, gthreads instead of coroutines, ... And then I finally had to do some actual porting work ;) This ranged from small fixes due to OS X BSD roots, or to older libraries on OS X, to new code to write because there was some linux/Windows specific code to handle screen detection/resolution changes. And after that, lo and behold, I could connect to my remote VM from my Mac!

Then, with the help of Marc-André, I could tackle Vinagre. This mainly meant making some Vinagre dependencies optional (namely gtk-vnc, gnome-keyring and GtkApplication) because I didn't want to compile/use dbus. After some confusion because of a regression in glib causing Vinagre to crash on startup, I was really thrilled to connect to finally connect to a virtual machine running on my work laptop from my Mac OS X laptop!

While this was great, things were far from being over :) In order for this work to be usable by other people, I had to build an application bundle, this basically means making Vinagre relocatable at runtime. Thanksfully, the work from the people porting gtk+ to OS X came to the rescue once again! They provide an ige-mac-bundler to help generate application bundles for gtk+ applications. I had to tweak it since it's not fully ready for gtk3 yet, and to figure out how to get it to change the location of libpeas plugins, typelibs, pango modules, gdk-pixbuf modules at runtime. The good new is that all these modules provide handy environment variables which help with that (PEAS_PLUGIN_LOADERS_DIR, GI_TYPELIB_PATH, PANGO_SYSCONFDIR and GDK_PIXBUF_MODULE_FILE), but it took quite a bit of trial and error to figure out all of these :) Last but not least, I wrote a few patches for Vinagre to add similar environment variables to locate its data files.

The reward

And here is the final result (disclaimer: it's still a work in progress) :

As you can see in the video above (bigger ogg version here), it's already working pretty well, you can connect to a VM, go fullscreen, sound is working, ... But as always, there are still some improvements to be done...
The most important one is to upstream the various changes I had to make in Vinagre, spice-gtk and ige-mac-bundler. For spice-gtk, this is mostly done, for Vinagre and ige-mac-bundler, I have to clean up the changes first. I also have to make building Vinagre on OS X much easier And then, there is more work to do to polish the OS X integration, like looking at GtkOSXApplication to get the usual OS X top menu bar, finding a better looking theme, having a native GtkApplication backend, and developing native OS X code for things like monitor detection/resolution changes/... (which is currently not implemented/not working). And obviously, it also needs lots of testing :)

All in all, I'm pleased with the result so far, it's a really good basis for a rocking Spice OS X client! Any takers for working on an iOS Spice client next ?

Public Announcements

2011-03-30T00:03:00.000+02:00

GNOME 3 in Paris

Thanks to YoBoY, there will be a GNOME 3 release party in Paris. It will happen on Friday, April 8th, registration is mandatory, and the number of available seats is limited, so register now for the party! There will be some GNOME 3 goodies ;)

Summer of Code

If you are a student, you can now apply for this year Google Summer of Code! GNOME is a mentoring organization this year again, this means you can be paid to hack on GNOME for a whole summer. Just browse our list of ideas for potential projects, or you can just write a proposal for any idea that you care about and would make GNOME even cooler!

Personal Life

I'm really happy to announce that I've started working at Red Hat last week. I have joined the Spice team and I'm looking forward to do great stuff (take over the world, this kind of things ;) with the people working there. Hopefully I'll get my own red hat soon!

Transferring contacts to an iDevice

2011-03-23T20:20:00.001+01:00

Recently, I wanted to transfer my addressbook from my good old but dying Sony Ericsson W910i phone to one of Apple iOS devices (aka iPhone 4).

Reading the contacts out of the old phone was a bit hackish but pretty straightforward using gammu/wammu and a bit of hacking. I didn't manage to import 100% of the data in GMail/evolution-data-server (had to retype a few addresses/phone numbers by hand), but I decided I could live with that.

Then I looked at the computer to iDevice writing, thinking it would be a pretty similar process, ie grab an existing tool, do a bit of fiddling and be done with it. Alas not :) I quickly realized that there was no tool on linux to send contacts to an iDevice. The alternatives involved booting into OS X, or sending a vcf file by mail and opening it on the iDevice. I didn't want to do the former, and the latter didn't work for some reason (and it's cheating anyway ;)

After talking with the nice people on #libimobiledevice, I realized the low-level building blocks were there in libimobiledevice, so I decided to go ahead and write the missing code (which involved parsing and writing XML plists from the device after figuring out their format). After a few days of hacking, eds-to-idevice was born! This C program can read contacts from evolution-data-server and writes them to an iDevice.
Be aware that this does not try to handle contact synchronization: when I use it, I tell it to erase all contacts from the iDevice and to unconditionnally write all contacts from evolution-data-server to the iDevice. If it's called multiple times, it will create duplicate contacts on the device.
However, I tried to make the code as generic and reusable as possible, with the hope that someone would pick up the ball and improve it to write a synchronization plugin for one of the linux synchronization framework. Volunteers :) ?

You can find the code on gitorious and I made a tarball. Enjoy!

GNOME and GSoC 2011

2011-03-19T22:11:00.002+01:00

We just got the great news that GNOME got accepted to be part of Google Summer of Code 2011. This is a great opportunity for GNOME, thanks again to Google for organizing this!

The bad news is that the work is just starting for everyone :) We are looking for cool ideas for students to work on during the summer, so if you are working on a GNOME project and have ideas that would make a nice 3 months coding project for a student, please add it to our idea page.

We'll also need mentors for all the students that will have fun hacking on GNOME during the summer, you can already register to be a mentor for GNOME on melange, don't wait, register now :)

Last but not least, if you are a student, be sure to check our ideas list and our information page for students. For now it's preliminary, the ideas will be sorted in the coming week. And you don't have to limit yourself to these ideas, you can also come up with your own cool idea and describe it in your application on Google website. The application period for students hasn't opened yet, it will open in about 10 days for now. However, you can already start thinking about what project you'd like to work on, start playing with the code of the project you'd like to work on during the summer, start discussing about your idea and your application with people involved in the project, ... Remember that in the previous years, we required candidates to show us a patch they had written for a free software project, and it's really likely that we'll do the same this year. You can also drop by on #soc on irc.gnome.org if you have specific questions!

All in all, it should be a fun summer! :)

GNOME devroom at FOSDEM

2010-09-08T17:23:00.002+02:00

This is just a public notice to let people know that this year again, I'll be handling the GNOME devroom at FOSDEM. For now I have applied to get one, let's see if we'll be lucky enough to get accepted this year again. This should be announced by the end of October.

But if you are willing to help organize GNOME presence at FOSDEM, don't wait until it's cold and nearly winter to get in touch, just tell me now! And if you have any suggestions about things to improve or things that went well in the GNOME devroom handling in the last years, let me know too!

GUADEC Paper Selection delayed

2010-04-10T18:10:00.002+02:00

GUADEC Paper Selection has been slightly delayed, speakers should have been notified today (April 10th), this announcement will be done on Friday April 16th instead. So don't worry if you sent a paper submission and haven't heard from it yet :)

GNOME and GSoC

2010-03-24T12:16:00.003+01:00

GNOME was once again accepted as a mentoring organization by Google for their Summer of Code!

The fun will begin later in the summer, but there are already a few things you can do to help:

add ideas for cool things that could be done during the summer
apply as mentor
or just hang around on #soc to guide students looking for help

So you know what you have to do now to help GNOME have a rocking summer!

For the late birds....

2010-03-21T14:27:00.002+01:00

For those of you that procrastinated for too long and missed the GUADEC paper submission deadline, I've got insider information... Something tells me the application interface on the GUADEC website will accept paper submissions until 23:59 UTC today (Sunday).
So this is really your last chance to propose a talk for GUADEC 2010 if you were really really late :)

On your mark, get set, go!

Only one day left!

2010-03-19T11:51:00.003+01:00

Time is ticking away, the deadline for talk submissions for GUADEC 2010 is tomorrow evening (Saturday 20th 23:59 UTC). If you are planning go give a talk there and haven't applied yet, there's no more time for waiting, better to apply now before it's too late! :)

GUADEC Call for Papers deadline

2010-03-15T15:55:00.003+01:00

It's nearly over us, it's coming fast!

If you want to submit a talk proposal for GUADEC 2010 (July 24, 2010 – July 30, 2010 in The Hague, The Netherlands), make sure to make your submission real soon since the deadline is Saturday, March 20th (aka "End of this week").

That's all folks!

One way to help free software projects

2010-03-04T21:47:00.006+01:00

Free software projects are always looking for new volunteers to help, new coders, new translators, new documentation writers, ... However, sometimes you want to contribute but can't become any of those, either because you lack time, because you are already involved in other projects, or because you feel you don't have time. For some projects, another way to help is through donations, here are 2 examples for projects I'm involved with.

Rhythmbox

Rhythmbox has had a plugin for Magnatune for quite a while now. In addition to not being evil (their website says so, it must be true! Joke aside, they give 50% of what they sell to the artist), they give 10% back to the Rhythmbox project for every purchase through its plugin.

And since they are not evil, today they sent a $600 check to the GNOME Foundation (which we chose as the recipient for the money). So you can buy lots of cool music on Magnatune while giving money to the GNOME Foundation at the same time!

Thanks a lot to John Buckman from Magnatune who was a really nice guy to interact with and to Adam Zimmerman for all his hard work on Rhythmbox Magnatune plugin.

libgpod

libgpod is the iPod handling library used by gtkpod, rhythmbox, amarok, songbird, ... It recently gained support for most of the latest devices released by Apple (iPod Nano 5th generation, iPhone, iPod Touch) which were unsupported under Linux until now (thanks a lot to Marcan, Nikias and all the people who helped with that by the way :)

However, this development was made harder by the lack of devices to test the code on, forcing us to look for testers with the right devices and going back and forth with bug reports and bug fixes until things work as expected. So donations to the project (even small amounts) are really helpful so that we can buy these missing devices and move things forward.
This already let us fund an iPod Nano which was a tremendous help to polish support for it in libgpod, thanks to everyone that made that possible. Next on the list are an iPod Touch to make sure the iPhoneOS support is up to par, and a buttonless iPod Shuffle which is so far unsupported by libgpod.

I've already mentioned it here, but if you have old iPods you no longer use , please get in touch, they can also be helpful for testing (thanks Götz!)

FOSDEM 2010

2010-01-15T17:35:00.002+01:00

GNOME will be present at FOSDEM and will have its own devroom on Saturday again. The schedule is now final (at least I hope so ;) ). Thanks to everyone who sent talk proposal to help make this room rock this year again!

On a related note, if you're coming to FOSDEM, let us know! This will allow us to print nice nametags (maybe!) for all gnomies around Brussels :)

Modern Begging

2009-07-26T20:56:00.003+02:00

The more I hack on libgpod, the more I realize that having iPod models from various generations would be really helpful. When implementing support for setting the iPod time, for parsing the iPod timezone, for figuring out which information is useful in SysInfoExtended, ... I always end up running after people with various iPod models to make sure the code works as expected both on new and old iPods.

I'm sure some of you have old iPods they no longer use hidden somewhere in their room, if you are in this situation, a donation would be really welcome and helpful :) Even iPods with dead batteries or broken screens might be useful.

And while I'm at it, it would also really really help if I could get my hands on an old iPod touch or iPhone. Because this is where most of the work is to be done today, and without one such device, I cannot test thoroughly and get into shape stuff like that.

So if you're feeling generous today and want to help support iPods on linux, drop me an email or leave a comment below!

Rhythmbox GSoC

2009-05-27T20:58:00.003+02:00

The coding period for this year Google Summer of Code has just started. I haven't blogged yet about Rhythmbox GSoCs, now is a good time to do it ;)

This year, 2 students will be hacking on Rhythmbox. Paul Bellamy (who I am be mentoring) started hacking on synchronization between Rhythmbox and media players.

And John Iacona (mentored by Jonathan Matthew) will spend the whole summer working on a contextual information pane for Rhythmbox. This information pane will display various information about the song being played (artist bio, similar artists, ...)

Adventures in udev land

2009-05-19T20:13:00.012+02:00

I've mentionned a while ago the work that has been done on libgpod hal callout. It's working nicely, but with HAL being deprecated, I thought now might be a good time at looking at how to do things in the future, and to check if udev already lets us do what we do in the HAL callout. The good news is that it's working now and is pretty straightforward. However, I got stuck on a few details, so I thought it might be useful to others if I documented my findings here.

Currently, libgpod installs a .fdi file with the iPod vendor ID/device ID and a binary name. When HAL detects that a device that matches these 2 IDs is plugged in, it runs the binary. The binary issues a SCSI inquiry command to the iPod to get various information, and set some HAL properties using libhal.

My goal was to do something similar with udev, ie get udev to run a binary when an iPod is inserted and then associate some information with the iPod device in udev database so that other applications can access it.

iPod detection

Running a binary when the iPod is inserted wasn't too hard, it's done with a udev rule file (the format is documented in udev manpage, don't forget to read it if you have to write such a file! ) which goes to /lib/udev/rules.d. My first version was simple enough:

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem",

ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="1204",

RUN+="/tmp/udev-test.sh"

udev-test.sh is a simple shell script wrapping the actual udev callout. It makes it easier to dump various information to a log file (for example the callout environment which udev uses to pass useful information to the callout). And, lo and behold, after plugging an iPod, my shell script was run!

Adding information to the udev database

The next logical step was to add some values read from the iPod to udev database so that other apps can get this additionnal information. And this is one of the steps that gave me some troubles. I was a bit ashamed of finding a really informative post by Kay Sievers answering my question right after having sent this email...

In short, it's really easy to import new values in the udev database, all you have to do is to output key/value pairs on stdout. This is nice, since udev passes information through environment variables and adds information to its database by reading stdout, this means that your callout doesn't have to depend in anyway on libudev.

I quickly modified my test program to print a few key/value pairs to add to the environment, triggered an unplug/replug of my ipod with udevadm, and watch the 'block' subsystem devices with the devkit binary. But I was really disappointed not to find my values associated with the iPod :(

After double checking everything and fiddling a bit to try to figure out what was wrong, I read again Kay's email, and I saw there was another difference between his code and mine: he is using an IMPORT rule to run his binary while I was still using a RUN rule.

I changed my udev rule to an IMPORT rule and.... it still didn't work :;)After staring at udevadm monitor output, I noticed that when the iPod was plugged in, there was first an "add" udev event for the iPod device shortly followed by a "change" event. Since my rule was only catching the "add" event, I hypothetized maybe my changes to the udev database were first properly added, and then overwritten by the "change" event. So I changed my rule file to catch "change" events in addition to "add" events, and it finally worked!

ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem",

ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="1204",

IMPORT{program}="/tmp/udev-test.sh"

I was very happy with my udev callout, however I shortly realized that when going from a RUN rule to an IMPORT rule, udev no longer passed me the device name (/dev/sd??) in the DEVNAME environment variable. I went to #udev on freenode to check if this was the expected behaviour, and Kay confirmed this is normal because when IMPORT rules are run, the final device doesn't exist yet.

However, the $tempnode variable can be used as an argument to the binary that is being run to give it access to a temporary device node which can be interacted with. And indeed, after adding this argument to my udev rule, I could do everything that I wanted to :)

Final polish

After this successful experiment, all that remained to be done was to make the udev callout as featureful as the HAL callout. This was pretty straightforward, I abstracted the information gathering part from the HAL callout. This generic code then uses some backend-specific code to set the values. The HAL backend does that by using libhal, the udev backend does that by just outputting values to stdout.

David Zeuthen was (as always) really helpful by pointing me at the udev/devicekit equivalent for info.desktop.icon and info.desktop.name: DKD_PRESENTATION_NAME and DKD_PRESENTATION_ICON_NAME. I also cooked up some variable names in a LIBGPOD namespace to have an udev equivalent to the stuff provided by podsleuth, let me know if it could be useful in your projects, it can be changed to fit your needs :)

End result

And here is the end result after plugging in my iPod:

# udevadm info --query=env --name=sdb2

DKD_PRESENTATION_ICON_NAME=multimedia-player-apple-ipod-color
LIBGPOD_VERSION=1
LIBGPOD_IS_UNKNOWN=0
LIBGPOD_FIREWIRE_ID=000A270002BAD546
LIBGPOD_SERIAL_NUMBER=JQ446FN4R5Q
LIBGPOD_FIRMWARE_VERSION=1.2.1
LIBGPOD_IMAGES_ALBUM_ART_SUPPORTED=1
LIBGPOD_IMAGES_PHOTOS_SUPPORTED=1
LIBGPOD_IMAGES_CHAPTER_IMAGES_SUPPORTED=1
LIBGPOD_DEVICE_CLASS=color
LIBGPOD_MODEL_GENERATION=4.000000
LIBGPOD_MODEL_SHELL_COLOR=white
LIBGPOD_PRODUCTION_FACTORY_ID=JQ
LIBGPOD_PRODUCTION_YEAR=2004
LIBGPOD_PRODUCTION_WEEK=46
LIBGPOD_PRODUCTION_INDEX=20272
LIBGPOD_MODEL_CONTROL_PATH=/iPod_Control

Et voilà! The code is available from the devicekit branch of my libgpod git repo
and will be committed to libgpod svn soon.

Solutions Linux 2009

2009-03-31T00:09:00.001+02:00

It's tomorrow. 9am. I'll be there. Waiting for you.

Why is so hard to find a blog post title?

2009-03-29T21:44:00.008+02:00

GSoC 2009

GNOME is a mentoring organization for the Google Summer of Code 2009. If you are a student who wants to get paid to hack all summer on free software, now is the time to apply, the deadline for application is on Friday, April 3rd.

You can find a list of ideas that have been proposed by GNOME contributors here but this list is in no way exhaustive so you can apply for any idea you care about and you think would improve the GNOME desktop!

Rhythmbox

Rhythmbox 0.12 was finally released a few weeks ago, it contains a lot of bugfixes and new features compared to the aging Rhythmbox 0.11.6. And development and bugfixing is going on in svn contrary to the impression some people had

There are 2 ideas proposed for the GSoC, one about media player synchronization (to keep Rhythmbox library and you favourite media player in sync), and one about getting information about the currently playing song (to know everything about your favourite group, get stats about the song that is playing, ...). You can find more details on the GSoC idea page on live.gnome.org

Solutions Linux

Solutions Linux will take place in Paris on the 31st March, 1st and 2nd April (this is Tuesday, Wednesday, Thursday this week). This year it has moved from CNIT/La Défense to Paris Expo/Porte de Versailles so this will be an exciting new experience for exhibitors ;) Mandriva and GNOME-FR both have a booth, you should definitely come to visit us, entrance is free! And there will be tshirts and stickers on the GNOME booth, and plenty of good stuff on the Mandriva booth!

FOSDEM!

2009-02-06T00:00:00.003+01:00

It's this week-end in Brussels, so make sure to go there if you don't already have plans for the week-end! I'll arrive in Brussels on Friday evening, not sure I'll be able to attend the beer party. Then I'll enjoy most of the great talks in the GNOME devroom and spend some time on the Mandriva booth as well. And am not sure yet what I'll be doing on Saturday evening, I guess something with the GNOMErs. Or the Mandrivians, we'll see ;)

If you are a GNOME contributor, don't forget the group photo on Saturday at 3.45pm. And there will be cool GNOME tshirts on sale as well.

Well, that's it, I don't really have much to say, this is just some shameless advertising ;)

Bloody spammers

2009-01-23T20:33:00.005+01:00

If you are subscribed to a GNOME mailing list, you probably got a really long and off-topic email from me. Except it wasn't me who sent it.

Yesterday, I was spending a nice evening enjoying some good home-made sushis, and when I went back home, I was really surprised to see lots of emails about waking up the world, meeting the new boss, ... And I got very annoyed when I realized that these emails had been sent from my email address to most GNOME mailing lists existing on earth. I felt really bad when I saw some replies showing that some people thought this email really originated from me. So I did the only thing I could do, some limited damage control. I replied to the persons who mailed me directly and to a few select mailing lists to make it perfectly clear that this mail didn't originate from me despite what it seemed.

By looking at the headers of the email, it's quite clear (at least to me) that I didn't send it: it was sent from a US ISP and I'm living in France these days and mainly using gmail as a mailer. Moreover, careful readers of the email (I haven't even read it myself ;) will have noticed that this email is signed "david duke" which is not my name ;).

I think some guy box was taken over by a trojan and that it crawled gnome.org mailing list archives, got my email address from there and gathered the addresses of most mailing GNOME lists and then blindly spammed them. I sent an email to the abuse contact of the ISP, but I don't really expect too much from them.

Now you know about as much as I do about that embarrassing email that some spam bot sent impersonating me. If you know people who got this email and think it was really from me, please spread the word and let them know that I had nothing to do with that. I'd never sent some political email to dozens of mailing lists where it's off-topic, especially not a really controversial one like this one.

That's all folks, let's go back to hack now :)

First news of 2009 :)

2009-01-21T20:33:00.005+01:00

New job

In my last post, I was looking for a job. The good news is that I started working at Mandriva 2 weeks ago. I'll be working on the core distro to (partially) replace pixel which means I'll hack on urpmi and bootloaders among tons of other things. Thanks to everyone who helped me with job opportunities!

libgpod

After far too much time, we finally released libgpod 0.7. It contains tons of improvements, the most noticeable being support for the latest Nano and iPod Classic, but there were lots of other improvements: writing of compact artwork files making the iPod more responsive, chapter data support, better iPod model detection, updated python bindings, improved API documentation, ...

There aren't many changes in this release for iPhone/iPod Touch support. However, in addition to the great work from the iFuse team, marcan figured out how to add songs to a jailbroken iPhone using amarok/gtkpod/rhythmbox/. If you add to that the iPod Touch is on its way to being jailbroken, this means that people really insisting on buying those devices will at least be able to use them without iTunes.

FOSDEM

FOSDEM is only a few weeks away now (7th and 8th of February), the GNOME and Freedesktop devrooms are booked and their schedule has been published. You should definitely plan a trip in Brussels if it's not done already :) And don't forget our group picture on Saturday if you are a GNOME hacker!

FOSDEM!!

2008-12-04T23:06:00.003+01:00

Months go by, and it's once again time to start thinking about the upcoming FOSDEM. It will take place on the 7th and 8th February week-end in Brussels.

This year, we'll have a devroom, we'll be on our own on Saturday, but on Sunday we'll share it once again with KDE and, this is new this year, with XFCE for talks of crossdesktop interest. I just got the confirmation about the room, so organization on our side is just starting, but if you already know you are going to FOSDEM and want to give a talk, please contact me and tell me about it :)

Another good news is that we'll also have a booth (like last year). The not-so-good news is that there is noone dedicated to the organization of said booth yet, so we'd need a volunteer to coordinate everything as soon as possible :) Contact me!!! It's not complicated, you just need to ask for the GNOME Event Box, think about what can be shown on the stand, find a few volunteers to be present on the stand during the FOSDEM, ... All that is needed is a bit of time, there are lots of helpful people who can give really good advice about the organization :)

Autumn update

2008-11-25T15:04:00.006+01:00

Rhythmbox

In the last weeks, I finally landed a few patches for Rhythmbox iPod plugins that had been waiting for too long.

The first one adds a dialog to setup new (empty) ipods, courtesy of gtkpod. This was bug #358029 and the initial patch was made by James Doc Livingston.

The second patch was written by Ed Catmur and Paul Drain. Its purpose is to avoid copying duplicate tracks to the ipod. It's currently a bit simplistic, 2 songs are considered duplicates if they have the same title/album/artist. And the code doing that is factored in a generic function in the RBRemovableMediaSource class so other DAP sources can easily get the same behaviour. The fact that the duplicate check is made in a single function also means that we can easily replace this check with a more elaborated one (using audio fingerprints for example) in the future.

The 3rd (and last) patch has been made by John Daiker and adds a property dialog to the iPod source to see how much space is available on the ipod, to see the ipod serial number, device name, ... This code is specific to the iPod source for now, but seeing bug #561955 which asks for the same feature for MTP devices, there is probably some factoring to be done...

And, more or less related to this last bug, in the last days I worked on porting the Banshee SegmentedBar widget to C to be able to reuse it in Rhythmbox. After writing the GObject boilerplate for a new GtkWidget, the porting was pretty straightforward since Cairo/Pango mono bindings are really close to their C counterparts. The end result can be seen on this screenshot :

The code can be found in bug #561955 as a patch to Rhythmbox source. However, the widget code doesn't depend on any Rhythmbox code which means it should be easy to reuse in any GTK+/C project if you need such a widget. If you do so, please let me know about any bug or API issues you encounter since the code is really young and hasn't been tested much :)

Libgpod

On the libgpod front, not too many news. svn trunk is in a satisfying state and is probably releasable as is. The lastest ipod nanos and ipod classic are supported (with artwork and photos). As always, any testing with the latest ipods is welcome. We are also missing a few serial numbers for the new 16GB nanos, so if you own one, it would be great if you could send us the last 3 digits of its serial number (printed on the back) as well as its color.

The iphone 3g and the ipod touch with 2.x firmwares are not supported at this time, the song database needs to be checksummed to be valid, and noone has reverse engineered the hashing scheme yet. Moreover, Apple is making things difficult through code obfuscation and legal hurdles.

UPDATE: the EFF published this really interesting analysis of the issue

On a brighter side, the iFuse guys have made great progress to make USB communication to non jail-broken devices to work. Before their work, one had to jailbreak his phone and to talk to it through wifi to do anything with it. Now that's no longer necessary thanks to those guys.

Personal life

After a few years working as a team leader on Anevia's Video-on-Demand server, it's time for me to move on and to look for new exciting job opportunities. So if you are looking for an experienced C/C++ Linux developper, you are very welcome to contact me. My resume is available here.

Lutèce d'or

2008-09-25T16:00:00.005+02:00

Yesterday, I attended the Cérémonie de remise des Lutèce d'Or (Lutèce d'Or awards). This is an annual event which is organised as part of Paris Capitale du libre (yeah, arrogant name, but we are French after all ;). This is a corporate event whose goal is to gather companies using free/open source software. The ceremony was great, free food in a really nice place except that I felt a bit out of place with my jeans and tshirts while everyone was wearing a suit ;)

But the most important (and most interesting) thing is that we (the GNOME project) won an award for the "Meilleure action communautaire menée" (best action led by the community) for the GNOME Outreach Program: Accessibility.

Getting this prize is really good since it give more exposure to our a11y efforts, even though now I really hate vuntz since he tricked me into going to this event instead of him and to go on stage to get the prize and say a few words with my tshirt (my best one!) in front of the suited audience. So no ice-cream for you Vincent!

libgpod callout improvements

2008-07-29T23:55:00.004+02:00

The other day, I mentioned that libgpod hal callout was setting volume.label to the iPod name to get a nicer name displayed for iPods in Nautilus (among other apps). What I didn't say is that I wasn't really sure that overriding that property with something that has nothing to do with the actual filesystem label was such a good idea.

And it wasn't. After asking David Zeuthen about that on IRC, he kindly told me about info.desktop.name which was added explicitly for that purpose. And I also learnt about info.desktop.icon which is to be preferred to info.icon_name. So I made these 2 changes and pushed them to the podsleuth branch of my git repository.

While I was at it, I worked on the few things that are still in the way to a libgpod 0.7 release, ie I cleaned up the exported symbols to make sure what we export make sense from an API point of view, and I added some missing API doc and made a few fixes in the existing one (some functions were renamed and the API doc wasn't properly updated).

On an unrelated note, I'm glad to see that some people find this blog worth some comments, thanks ;)

And my other project is...

2008-07-28T00:04:00.006+02:00

After describing my latest work on Rhythmbox yesterday, here's what I did on libgpod in the last month. libgpod is a cross-platform library used by many different projects (amarok, gtkpod, rhythmbox, songbird to name a few) to access and modify your ipod content.

Extensive SysInfoExtended parsing

As has been known for a while now, the iPod can be queried about its capabilities using SCSI commands and returns XML data describing the iPod (serial number, firmware version, ...) and what it can do can do (podcast support, video formats supported, image formats that it knows how to display, ...). When we released libgpod 0.6, we introduced a hal callout to send the appropriate SCSI query to the iPod and to dump the returned XML data to a file that we named SysInfoExtended. Normal users aren't guaranteed to be able to send raw SCSI commands to a device, hence the use of a hal callout and the dumping of the information to a regular file. However, in libgpod 0.6, we only had a very basic parser for that file which only knew how to read the only SysInfoExtended field we needed. Most of the information about the iPod capabilities was hard-coded into per-ipod model tables, and libgpod had to be told the iPod model before being able to (for example) being able to write artwork to an iPod.

For the next release of libgpod, I decided that we had to be able to use the information from SysInfoExtended to its fullest. I started by writing a generic plist (which is the XML subset SysInfoExtended is in) to GValue parser using libxml instead of GMarkup. Then, I extracted the data I was interested in from the GValue collection the parser gave me to a nice C struct. To make the addition of new fields easy, most of the work is driven from a table indicating the field name in the plist file, the type we want to assign that field data and the offset we want to put that data in the resulting struct. Modifying that table and the struct definition are the only things that need to be done if we want to read additionnal fields from SysInfoExtended.

With that being done , I had everything I needed to have libgpod use the information provided by the device to write artwork to the iPod instead of relying on hard-coded tables. Some refactoring was needed to make it possible to use the artwork data from the iPod (there were some assumptions here and there that the formats supported by the iPod were known at compile time) but now that it's done, the code feels much more natural and maintainable than before.

Getting the iPod model from SysInfoExtended

With the aforementioned work, writing artwork to the iPod has been made much more flexible, but libgpod was still unable to automatically guess the iPod model/color/... from the device without asking the user. This is due to the fact that to do that, libgpod relied on the iPod "ModelNum" which used to be present in a file on the iPod filesystem but for quite some time now, the only way to get that model number is to read it on the iPod box, which is not really easy to do from software :)

But for all recent iPod models, there's another way to guess the iPod model, this is by parsing the iPod serial number. And this serial number is precisely one of the things that we can read from SysInfoExtended! So all we had to do to be able to automatically detect the model/color/.. of a plugged iPod was to properly parse the iPod serial number and to infer the iPod physical features from that serial number, just as what podsleuth does with that table.

Podsleuth

Given that libgpod had already installed a hal callout, and after all the work done to parse the SysInfoExtended data, I realized that libgpod had gathered all the pieces to build a podsleuth clone, so I decided to try to write one just for fun and to test the new API added to libgpod in real-world situations. This led to the work which can be found in the podsleuth branch of my libgpod git repository.

Even though I haven't tested it against banshee, I compared the properties exported by podsleuth and by this experimental stuff, so this code can probably be used as a drop-in replacement to podsleuth. Writing it also made me realize that podsleuth doesn't export enough information about artwork formats compared to what libgpod needs. I'm also not a big fan of how podsleuth exposes the artwork formats: it parses the XML to get the artwork data to immediatly serialize it again to a string. It's then up to the app using podsleuth to parse that string (again) to get the artwork formats supported by the ipod.

Anyway, since I now have hacked this nice tool, it's now up to me to experiment a bit with all of that and to make suggestions as to how things could be improved :) By the way, I already used that code to see how iPod integration with the desktop could be improved: it sets the volume.label HAL property to the name of the iPod as extracted from the iPod database which results in a nicer name for the iPod on your Nautilus desktop.

blogo ergo sum

2008-07-27T01:11:00.000+02:00

After being kicked again and again (which hurts, the guy is a black belt in karate) by Dodji who wanted me to blog, here is a first post.

Album Artist support

These last days, I've been trying to get back to Rhythmbox development to scratch a few itches of my own.
First, I've looked at how Rhythmbox could handle compilations, ie albums containing tracks by different artists. Currently, if the album has 12 different artists, these 12 artists will appear separately in the artist list which can quickly create a big mess. I wrote a basic patch to make it possible to set an "album artist" for such albums and to use that instead of the multiple different artists in the artist list. I had to experiment a bit with various approaches, but in the end, the patch is surprisingly small.

Song UIDs

Then, I wanted Rhythmbox to be able to provide UIDs for the songs in its database. What I call an UID is some kind of identifier that is unique to a song and that can be generated by only looking at the song data. This can be useful for various things : iPod (or whatever your portable media player of choice is) synchronization, associating user data (rating, play count, ...) to a song which persists even if the user does a mv of the song from the shell, ... I learnt after doing that work that Charlotte had been looking for such a feature in Rhythmbox for her nice Rhythmbox SOC which was good news :)

To generate that UID, I chose to hash the song title, artist, album (read from the tags of the song) with the first 8kB of data of the file (actually, this hashing scheme was heavily inspired by what Amarok does). I'm not sure yet if this is the best way to uniquely identify a song, but we'll only know after people try to use it. Before you ask, I thought about using musicbrainz/musicDNS acoustic fingerprints but as far as I know, none of those fingerprints can be generated using free software end to end, there's always some closed source webservice that must be queried to get a fingerprint from a few parameters that were generated by analyzing the song audio data.

Once again, this feature was straightforward to implement.

The main issue I had was to debug the UID generation. Indeed, metadata reading (where I chose to add the UID generation) is done by a separate process which communicates with Rhythmbox through dbus. Reading metadata is basically equivalent to feeding random data to the tag reading library, so it's really hard to guarantee the library won't crash or hang in some corner cases. Using that external process allows Rhythmbox not to crash or hang if such an event should occur during metadata reading.

But this external process also makes debugging harder: it's short lived, spawned on-demand and run in the background (ie it's not possible to print stuff to stderr or stdout). So moch's help was really welcome since he explained me how to be able to run that metadata helper process by hand and to tell rhythmbox to use it. It's really simple, all you have to do is to (optionally) increase ATTENTION_SPAN in metadata/rb-metadata-dbus-service.c so that the helper stays alive longer (by default, it dies after 30 seconds of inactivity).
Then, you can run rhythmbox-metadata in nemiver (or in your favourite debugger), this will output a line like :

unix:abstract=/tmp/dbus-vXSVpHsnpL,guid=ba4e19b37904dba3bb1fc2214889d478

If you now set the RB_DBUS_METADATA_ADDRESS environment variable to that value before running Rhythmbox, then Rhythmbox will use the metadata helper you just launched in your debugger. Now all that is left to do is debugging!

The result of this work can be found in the uid branch of my Rhythmbox git tree. It still needs some polishing, but the basics should already be working (including automatically updating your database to add UIDs when you first run it).