Category: Linux

openSUSE build service collaboration

One of the shortcomings of the openSUSE build service was, until recently, that it didn’t help outsiders (non-Novell employees) in contributing to the distribution’s packages. The build service team worked hard in the last few months, and now it is very easy for external people to send patches directly to be included in the main distribution.

First, you need to create a branch from the package you want to change:

osc branch GNOME:Factory gnome-utils

This creates a branch in your home project (home:$user:branches:GNOME:Factory), so just check it out:

osc co home:$user:branches:GNOME:Factory gnome-utils

Then, just work on changes, and when everything is ok and the package builds, just commit and submit a request

osc commit -m “Changed foo and bar”

osc submitreq create -m “Changed foo and bar”

Before submitting though, it might be wise to re-check your changes:

osc rdiff home:$user:branches:GNOME:Factory gnome-utils

which shows a diff of the changes in your branch.

osc commit/submitreq create will submit the changes to your branch and to the project you branched from (GNOME:Factory in this example), so that maintainers can review and accept (or reject) the submission. Maintainers just need to:

$ osc submitreq list GNOME:Factory

359 new home:rodrigomoya:branches:GNOME:Factory/gtk2-engines -> GNOME:Factory/gtk2-engines ‘——————————————————————-\nFri Jul 18 17:16:38 CEST 2008 – rodrigo@suse.de\n\n- Tag and upstream patches’

360 new home:vuntz:branches:GNOME:Factory/pango -> GNOME:Factory/pango ‘Tag pango64.patch’

363 new home:jproseve:branches:GNOME:Factory/glib2-branding-openSUSE -> GNOME:Factory/glib2-branding-openSUSE ‘Fix bnc#406741’

364 new home:rodrigomoya:branches:GNOME:Factory/fast-user-switch-applet -> GNOME:Factory/fast-user-switch-applet ‘Tag patch correctly’

365 new home:rodrigomoya:branches:GNOME:Factory/gnome-utils -> GNOME:Factory/gnome-utils ‘Tag some patches’

366 new home:jproseve:branches:GNOME:Factory/scrollkeeper -> GNOME:Factory/scrollkeeper ‘Tag patches’

367 new home:jproseve:branches:GNOME:Factory/icu -> GNOME:Factory/icu ‘Tag patches’

368 new home:jproseve:branches:GNOME:Factory/scrollkeeper -> GNOME:Factory/scrollkeeper ‘Tag patches’

which lists all the submissions waiting in the queue, and then just needs to review it:

$ osc submitreq show -d $id

which shows the patch for the submission identified by $id. And then, just accept or reject:

osc submitreq accept $id

osc submitreq decline -m “Your patch is wrong, don’t send me more” $id

Neat, isn’t it? This should help us a lot in getting users’ contributions quicker into the distro, as well as in a better patch reviewing system.

Where we are going we don’t need roads


Been reading this last week the decadence in GNOME thread in Planet GNOME, so just wanted to add some thoughts:

  1. First of all, I don’t think GNOME is in decadence at all. The development platform does nothing but improve (GTK/glib, new gio/gvfs, libgnome/bonobo/etc disappearing, good bindings for lots of languages, etc), and applications do the same.
  2. We offer incremental updates on each release, a lot of work is done, but it’s true that for some end users, they might not see changes big enough to consider it a new version. So maybe, apart from the time-based releases (which work pretty well, IMO), we should maybe try to have, apart from the individual modules’ roadmaps, some sort of desktop-wide features to accompany each release. If we set, for instance, a “all apps will use gio and support working with remote files” goal, I think that would make a better release feature that end users will better appreciate. Similar desktop-wide goals could be used for each release, which will change, IMO, the user’s impression of the new releases.
  3. I hear some people considering 3.0 should contain a lot of development platform changes. And well, while changes in the development platform are great (that’s why it’s improving all the time), I don’t think the future of GNOME (the desktop) releases should be so tied to the platform. On the contrary, the platform should adapt to the applications being written. Some years ago we did a lots of improvements to the platform because we were writing big apps (Nautilus and Evolution).
  4. Since I started using GPSs, I ended up visiting forums and mailing lists about the subject, finding that most people use illegal software (cracked programs downloaded from P2P networks) and maps (ditto, got from P2P), so if we could offer a free software-based solution for these people, they would probably move on. This is of course just one example, which is even being already covered by OpenStreetMap, but I’m sure there are lots of similar markets out there that we could try to cover better to bring 1000s of new users to our desktop.
  5. As for innovation, this is probably something we need to improve. There is innovation for sure (Gimmie, Pulseaudio integration, Compiz Fusion (not really a GNOME thing, but it’s got GTK-based tools that nicely integrate into GNOME), Banshee 1.0 (try it, it’s great!), Clutter, etc), but it’s true it’s not easy to make revolutionary changes (like using gimmie instead of our current panel, for instance), since it means convincing a lot of people in endless discussions. I think part of the problem is that people working on similar stuff are not put together to come to decisions (like distros working on similar solutions for the same thing 🙂 ), so we probably need improvement there, like having the hack meetings that were discussed recently.

Summer of Code 2008

For the first time, I am mentoring a student for this year’s Google Summer of Code, who will be working on a GNOME client for the openSUSE build service.

Mario (ie, the student) seems to be a very motivated person, so I’m willing to see the results of his work this summer, and to have another future contributor to openSUSE and GNOME.

As for the mentoring itself, following Federico’s mentoring HOWTO should make things easier for me, so I hope to do a good job. More news about the project as things progress.

Desktop effects activation (compiz)

The discussion about how/where to put the activate-desktop-effects thing in the appearance capplet seems to not reach a good solution for all distros, at least for now, so, while waiting for a good solution for all upstream, and since in openSUSE desktop effects means compiz, I added a patch to the simple-ccsm openSUSE package to activate compiz directly from the same place where it is configured.

So, the ‘Desktop Effects’ icon in the GNOME control center:

starts now simple-ccsm, which contains a check box to activate/deactivate compiz.

The old ‘Desktop Effects’ capplet (aka gnome-xgl-settings) will soon die, since gnome-xgl-switch script has been moved to the XGL package, and the hardware database is already on a separate package.

New colleague at work

Yesterday was the first day with Vincent Untz as a member of the openSUSE GNOME team. For those who don’t know him, he’s one of the top-involved persons in upstream GNOME, having been part of the Foundation board, the release team, and maintainer of several modules, etc, etc, so his role on the team will help a lot in making openSUSE and GNOME better.

Looking forward to see what he helps us getting to.

Hack week II

Last week was Hacking week at openSUSE, so here’s a summary of what I did:

  • I moved all my OSM-related packages to the Application:Geo repository in openSUSE’s build service. And I added a couple of packages I needed to build maps for my GARMIN GPS unit: mkgmap and osmosis, which have helped me in making the first 100% free map of Spain for GARMIN GPS units 🙂 Of course, the map is incomplete (compared to the P2P’ed maps GARMIN users in Spain use), but this should probably get more people to contribute to the maps. Here are some screenshots of the maps on a Que PDA (thanks to Miguel Blanco):
    que-osm-spain que-osm-barcelona que-osm-madrid que-osm-madrid-sol
  • I lost lots of time at the beginning of the week trying to make Mapper (a fork of maemo-mapper to provide more OpenStreetMap-oriented features) work, fixing some build problems (patches are upstream now) and packaging it. It still doesn’t work very well though, crashing a lot, but this will improve soon.
  • I started working on a GNOME client for the openSUSE build service. Most of the time was spent doing tests with Python in general and the OSC Python API in particular, so the result is not that fantastic, but at least I’ve got now a good base from where to continue the work. You can find the (clean) work in my git repository: 
    git clone http://www.gnome.org/~rodrigo/git/osc-plugins.git

    gosc.png