James’ SOC Blog

I tried to get a build of gnome done on my computer using the jhbuild tool. I like the way it uses libnotify to inform you when there is a build error. It’s meant that I can leave it compiling in the background whilst doing work on my Masters project and only pay attention when there are errors.

I got stuck compiling pixman with the same error as found here. Unfortunately the fix provided in this case didn’t work for me. I tried both using jhbuild build -a and adding the appropriate PKG_CONFIG_PATH lines to my .jhbuildrc file without success.

Turns out the error was due to one of the tests in pixman was trying to link against gtk which had yet to be built by jhbuild and so was trying to pull in the system version of gtk which linked against the system version of glib, which was listed first on the command line and hence took priority, resulting in the error.

Now I’m not the only one to have this problem: http://bugzilla.gnome.org/show_bug.cgi?id=344358. The reason for the problem is when the system already has the dev packages installed for the system’s installation of Gnome, in my case this is because I am running Gentoo. The solution given on #gnome-love on irc.gnome.org was to remove all *.la files from my system. This isn’t really an acceptable solution for a distribution that is compiled from source - I need the libtool library files to update my system!

Making sure a build system compiles on a fresh checkout for a new user is a problem that I came across when maintaining the build system for a fluid dynamics software suite I worked on at BAE Systems. It’s all too easy to write a build system that relies on source already being installed, and miss the small things that a new user will be stumped by, even if it is only a 1 minute fix to you. I wouldn’t be surprised if I start hacking at jhbuild in the near future as these things do niggle me, especially if I can think of a way to fix them!

Despite all this I’ve managed to, through a mixture of running jhbuild with the -a flag, manually running configure, and modifying my .jhbuildrc file to set environment variables and build options, to get most of the latest dev version of gnome compiled now (at least the parts that I need to work on). Next step is to point the jhbuild moduleset to my git repositories (I’ll post a url once I begin development), although to avoid future pain I may resort to setting up a VMware image with Fedora or Ubuntu on it to use as a sandbox environment for testing.

Since my work is going to span across many modules and that each of these modules are in it’s own svn repository, I have decided to use git-svn as a source control tool. I will be publishing my git repository at git.jsharpe.net once I’ve got ssh access enabled on my server.

Using git to access svn repository
Some of you may be interested in how to use git to access a svn repository. (A more comprehensive guide is available here) This is how I used it to clone the gnome repositories:

First run:
git svn clone http://svn.gnome.org/svn/jhbuild -T trunk -t tags -b branches
This tells git to clone the jhbuild svn repository with trunk directory named trunk, tags directory tags and branches directory branches. (A pretty standard repository layout however if the repository is laid out in a non-standard fashion there are ways of making git svn play nice here too - ask if you’d like to know).
This will churn away for a long time checking out every single revision from revision 1 to obtain the complete history( the -r flag can be used to reduce the number of revisions that are checked out to a smaller number).
Once this is completed we will then have all the branches and tags from the svn repository available as remote branches.

Space Savings using git over svn
I’m still amazed at how well git compresses repositories. After cloning the nautilus repository the .git directory was 2.0G. Running the command:

git gc –prune –aggressive
compresses this down to 381M.

Working with a git svn repository
Keeping up to date is simple. You simply run the command
git svn fetch
from within your working copy. This will download all updates on all the branches and tags from svn that happened since you last updated. (Incidently if during the initial clone step your connection dies or you need to stop it then to resume the clone you just have to run the above command to resume downloading the history).

Day to day development then should occur on a branch which is then rebased against the master when svn updates are pulled down. Changes can then be pushed back to svn using git svn dcommit.

So I’ve been accepted onto the google summer of code 2008 program to work on the Gnome desktop project. I’m going to be working on the desktop wallpaper system and adding the functionality of being able to set a different wallpaper for each desktop. This functionality has been desired in Gnome since 2001 (bug 48004). Its an interesting project as it cuts across a number of modules within the Gnome project and also presents some challenges such as keeping memory usage down when a user has a large number of workspaces.

The project consists of two main parts: the backend, which involves dealing with GConf and all the management of the background pixmap, and the user interface; adding the flexibility of choosing a background for each desktop introduces new usability challenges to the interface; its desirable for new users to be able to quickly pick up the interface for changing the background for all desktops, for existing users to not be confused by the new interface but at the same time be able to fully utilise the full functionality available easily.

Its possible that I finish this work early. In which case I have plans to add new functionality to the background system. Some ideas I have already are:

• Background rotation every N mins
• New colour gradients
• Watermarks e.g. a corporate logo can be blended onto the background chosen

I’m open to other ideas too, so if you have any then get in contact with me.