GNOME Packaging Day

In the last few openSUSE-GNOME team meetings, it was decided to do regular packaging days whenever GNOME point versions are released, with the goal of providing bleeding edge updates as quickly as possible. So, next week is that time: along with the GNOME 2.25.90 release on Feb 4th, Thursday Feb 5th we’ll be helding a packaging day to get the latest unstable GNOME release packaged into our GNOME:Factory project (to be used for openSUSE 11.2 but also available for 11.1). It is a great opportunity to find out how to contribute to the packaging of GNOME for openSUSE.

The packaging day will last the whole day long, so just come around -gnome IRC channel on FreeNode at any time you want and ask how to help.

AdminKit 0.0.1

Last week it was hacking week for the openSUSE-GNOME team, so I continued working on a little project I started a few weeks ago, which is, in the good old Richard Hughes tradition, a thing called AdminKit, which is a PolicyKit-based framework for allowing user applications to run administration tasks.

Most of the time hacking on this has been dedicated to the PolicyKit stuff, but now everything should be in place, and, apart from the 2 methods I added (RunAsRoot to replace gnomesu/gksu/kdesu, and AddUser as an example of how to use YaST’s command line interface for the operations), more methods (users management, firewall, samba shares, etc) can be easily added. With this and the GUI from gnome-system-tools, I think we can start providing a distro-independent (and acceptable to all of them) set of administration tools for GNOME (and KDE, if they adopt AdminKit), or just add the needed admin functionality to already existing applications. From now on, here are my ideas:

  • Move PolicyKit mechanisms already existing in some GNOME modules (gnome-panel’s SetTime and SetTimezone, for instance) to AdminKit, provided people agree on adopting it
  • See system-tools-backends and reuse as much knowledge/code as possible
  • See at changing gnome-system-tools’ GUI to use AdminKit (once the functionality needed is moved to AdminKit)
  • Add more admin operations, as needed. For openSUSE, we have quite a lot of functionality via yast’s command line interface, and other distros have similar stuff, so anything we need can be added AFAIK.

Get the code with:

git clone http://www.gnome.org/~rodrigo/git/osc-plugins.git

(cd AdminKit, the other top-level dirs contain unrelated projects)

And, soon, packages at my home build service repository.

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.

PulseAudio in openSUSE

After several bugs fixed and lots of debugging, I can say now PulseAudio should be working almost perfectly (still some problems with stuttering sound on low-end machines) in openSUSE 11.0. So, here’s a summary of the things we have done, which I should have bloged about before.

First, we tried to replace the GNOME-upstream volume control with padevchooser (a system tray icon that gives access to all PulseAudio tools), but people complained loudly about the difficulty of just setting the volume with this, they just wanted a volume slider. So, we got back to the upstream volume applet, but changed it to open the PulseAudio volume control instead of gnome-volume-control.

volume applet using PA volume control

Another problem we found early was PA not working correctly on 5.1 (or other) speaker setups. There was an easy fix, just changing the number of channels in the config file, but there was no GUI, so we added one to paprefs:

paprefs-speaker-setup.png

With this, you can now control all your speakers individually:

Speaker setup on volume control

Apart from that, we had to tweak ALSA and SDL configurations to just use PulseAudio when on GNOME, since KDE is not using it, but I think everything should now be ok.

Back home / debugging

I’m now back home after a couple of weeks of lots of traveling. I first was 4 days in London, visiting my sister, then was 5 days at home, sick with a flu most of the family got while in London, then last weekend to beautiful Salamanca for a conference at the University. Back home on Sunday, still a bit sick, and on Monday flied back to Stansted for a 2 days visit to Michael, for some debugging and bug fixing fun.

So, in this 1.5 days of fun action at Michael’s, I’ve learnt a few useful bits:

  • Some useful tools, like LD_DEBUG, pmap, fuser, c++filt
  • Technique: this was the best part of it, since Michael is what we could call a superhacker, so watching him debugging stuff to look for a problem’s cause is very helpful (even though you can’t read everything he writes, since he does it so quickly 🙂 ), and he has some nice habits in his technique that should help me a lot, now that I’ve learnt them, in my bug hunting work.
  • I had an idea about writing scripts using lots of these tools for our users to use them for reporting super-useful bug reports, so will be writing a little bit about that as soon as I start looking at it.

While visiting Michael and his wonderful wife and daughters, I had the opportunity to meet my sister and family on Tuesday for dinner, since they were visiting Cambridge that day, where they will be moving soon, so I will have the opportunity to visit both my family and Michael (for more debugging and technique learning fun) more often.

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.

Desktop effects activation

After having implemented the same functionality already available in Fedora and Ubuntu (different implementations of the Desktop Effects tab on the appearance control-center applet) for openSUSE, it is time to come to a common solution for all distros to remove their need to add this functionality. An initial patch is available here.

Still lots of things need to be discussed and clarified, so if you care about activating desktop effects in GNOME, GNOME Control Center mailing list.