pkg-gnome

People Behind Debian: Josselin Mouette, founder of the Debian GNOME team

January 27, 2012 by Raphaël Hertzog

Josselin Mouette is one the leaders of the pkg-gnome team, he takes sound technical decisions and doesn’t fear writing code to work-around upstream issues. He deserves kudos for the work he has put into packaging GNOME over the years. He can also be very sarcastic (sometimes he even enjoys participating to flamewars on debian lists), and there are quite a few topics where we have long agreed to disagree. But this kind of diversity is also what makes Debian a so interesting place…

Read on to learn more about the pkg-gnome team, its plans for Wheezy, Josselin’s opinion on the GNOME 3 switch, and much more.

Raphael: Who are you?

Josselin: I am a 31 years old Linux systems engineer. I started in life with physics, which I studied at the ENS Lyon. I started a thesis on experimental and numerical models for optoelectronics, but when it became clear that research was not for me, I abandoned it and accepted a job at the CEA, which holds the largest computing center in Europe. Working on these machines has been the most awesome job ever (except for it being near Paris). After that I worked a bit on system monitoring technologies.

I am married, currently living in Lyon, and working for EDF (the French historical electricity company) on scientific workstations using Debian. EDF is using Debian on more than a thousand workstations and holds the fastest Debian supercomputer in the world (200 Tflops), which makes it another obvious place for Debian developers.

Raphael: How did you start contributing to Debian?

Josselin: I discovered Debian in 1999 while studying at the ENS, which is one of the biggest nests of Debian developers – while being a small place, it is producing almost one Debian developer per year on average. After wondering for a while what it could be useful for, hacking on a slink snapshot made me think that it was for, well, everything except for gaming. Later, in 2002, when I was working on optoelectronics computing codes, I started to package them for Debian in order to make them easier to install, for us as well as other labs over the world. I started the NM process, and it was going smoothly but also going to take time. However, at that moment, the frozen-bubble game went out and made quite some buzz. Since I knew a guy who knew the game’s developer, he asked me to package it. The package found 3 sponsors in a very short time and was fast-tracked into the archive at a speed that was unseen before. After which the NM process was completed very quickly.

At that time, I was a heavy WindowMaker user, but I didn’t like the direction the project was taking (actually, I wonder if there was one). GNOME was starting to become attractive, but its packaging in Debian was very ineffective, with many inconsistent packages maintained by people who didn’t ever talk to each other – some of them didn’t speak English, and some of them didn’t talk at all. Together with awesome people, among which Jordi Mallach, Gustavo Noronha Silva, JHM Dassen, Ross Burton and Sébastien Bacher, we started the GNOME team in 2003, introducing consistent packaging practices, and initiating synchronized uploads. Releasing a completely integrated GNOME 2.8 in sarge was a considerable achievement; proving (together with the Perl team) that a team was the best way to maintain large package sets changed the way people work on Debian.

“Proving […] that a team was the best way to maintain large package sets changed the way people work on Debian.”

Raphael: You’re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team?

Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us.¹ The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the “big” packages are usually waiting on dependencies.

I used to direct newcomers towards bug triage, but it is a tedious task and I’m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it’s worthy enough you’ll soon get commit access.

“Our huge bug backlog will never be dealt with.”

¹ At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn’t mean that no one will answer in 2 hours, so please stay on the channel after asking.

Raphael: There’s been some controversy about GNOME 3 and the direction that the project is taking. What’s your personal stance on GNOME 3? And what’s the position of the pkg-gnome team?

Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:

General lack of configurability
Strange design decisions
Red Hat centric development
Hardware requirements
Change resistance

The lack of configuration options has been an ongoing criticism since GNOME 2.0 has decided to rip off most of them. Of course, when the control center was redesigned again for 3.0, there was a surge of horrified exclamations from people who missed their favorite buttons. On this topic, I fully concur with GNOME developers. The configuration option that is useful for you is not necessarily useful for someone else. Of course, sometimes developers go a bit too far, but the general direction is right. At work, we found that only a minority of users actually configure anything on their desktops: they just want something that works to launch their applications. Apple and Google have sold millions of devices by making them the simplest possible and without any configuration.

Design decisions are, on the contrary, individual decisions, and each of them, while having reasons behind it, can be questioned. I remember seeing a lot of complaints when the OK and Cancel buttons were reversed in dialog boxes, something that nobody questions anymore. GNOME Shell is full of such changes; some are easy to get accustomed with, some others just make eyebrows raise. The most obvious example is the user menu in GNOME 3.2, which contains an entry to configure your Google account, but no entry to shutdown the computer. Both decisions were taken independently, each of them with (good or bad) reasons, but the result is simply ridiculous. The default configuration in Debian will contain an extension to make it a bit better, but on the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.

“On the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.”

Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won’t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions¹.

Hardware requirements are mostly a consequence of the previous criticism: there’s hardware that most distributions just don’t want to bother supporting. We’ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone². On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called “fallback mode”, which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems³. For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy.

Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users’ habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don’t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the “fallback mode” great. One of the change that was made in Debian was to make it easier to find, being available as “GNOME Classic” directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.

“In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.”

¹ Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
² Scientific workstations are a non-trivial example, since there is a measurable effect of using 3D in the window manager on heavy 3D applications.
³ On the other hand, on accelerated systems, this feature should end up improving performance a lot.

Raphael: What are your plans for Debian Wheezy?

Josselin: The first goal of the GNOME team is, of course, to provide again a great desktop environment to work on. For wheezy it will probably be based on GNOME 3.4. There also needs to be some work on package management interfaces. Upstream bases everything on PackageKit, but it is not as featureful as the aptdaemon Ubuntu technology. If I have time, I would also like to improve HTTP proxy support, since currently it is based on a stack of terrible hacks.

Raphael: If you could spend all your time on Debian, what would you work on?

Josselin: Obviously I would like to make GNOME in Debian even better. That would imply working on underneath dependencies (what we now like to call plumbing) to make sure everything is working great. This would also imply working more as GNOME upstream to make it more suitable for our needs.

I would also work on large-scale improvements on the distribution, like conditional recommends which I’d love to see implemented¹, or automatic build-dependency generation. I would also work on the installer to make it better for desktops machines.

¹ The idea is to automatically install language packs, or glues between two packages when both packages are installed.

Raphael: What’s the biggest problem of Debian?

Josselin: The obvious answer is the same as the one most people you interviewed before gave: not enough members in core teams. A lot of developers join Debian to work on a small number of pet packages, and don’t necessarily want to be involved with existing teams. It is probably still not obvious enough that the primary way to start contributing to Debian is to join an existing team.

But if there is one thing that is preventing Debian from gaining more momentum now, it is a completely different one: the too short support timeframe. 3 years is really not enough for corporate users. One year to migrate from one version to another is too short, and it is not possible to skip a release. It is definitely possible to change that with reasonable effort: the long-term support after 3 years doesn’t have to cover the same perimeter as the short-term one. For example, we could upgrade the kernel to the version in the current stable release, and stop fixing all non-remote security holes. The important thing is to cover the most basic needs: companies are ready to take the risk of having less support if it allows skipping a version, but not the risk of having no support at all. And even more important is to say that you do something. Red Hat says they support a release for 10 years, but of course after 5 years the supported perimeter is extremely small.

“3 years [of support] is really not enough for corporate users.”

Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years – perhaps as a reaction against what happened with Ubuntu – we’ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities.

Raphael: You’re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems?

Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does – although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files.

Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I’ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects.

Raphael: Is there someone in Debian that you admire for their contributions?

Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.

Thank you to Josselin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

GNOME 3 transition happening in Debian unstable

October 17, 2011 by Raphaël Hertzog

The few articles I wrote that explained how to install GNOME 3 from Debian experimental have been very popular. So I figured out that a small update would be welcome.

The Debian GNOME team started uploading a mix of GNOME 3.0 and 3.2 packages to Debian unstable because the release team is ready to take care of this transition. This means that as soon as the packages are ready in Debian unstable, the release team will ensure that they also reach wheezy (aka the current testing distribution).

So if you’re a Debian unstable/testing user with a GNOME Desktop, expect some important changes… by the way my experience with GNOME 3 was recently plagued by some rendering issues resulting in parts of the screen not being properly refreshed. While trying to track this down (and investigating clutter as a possible culprit) I came upon this mail on the clutter-devel mailing list. I recompiled mutter with the indicated patch and it fixed my issue. I immediately uploaded mutter 3.0.2.1-4 with the fix… so this issue should be gone for the many people who are going to experience GNOME 3 for the first time in the coming days.

It’s also worth noting that contrary to how upstream handles it (they hide the fallback mode and the user has to enable an option to use it in place of the GNOME Shell), Debian has a dedicated session for the GNOME 3 fallback mode so you decide what you get right from the login screen. This will be appreciated by the people who do not see GNOME 3 as a step in the right direction. Unless they switch to XFCE as some did.

As far I am concerned, I’m already used to GNOME 3. I spend most of my time in terminals, browsers and an IRC application and the whole Shell does not fundamentally changes my work habits.

Installing GNOME 3 on Debian 6.0 Squeeze? No, sorry

June 16, 2011 by Raphaël Hertzog

Ever since I blogged about the status of GNOME 3 in Debian experimental, my web logs show that many people are looking for ways to try out GNOME 3 with Debian Squeeze.

No GNOME 3 for Debian 6.0

Don’t hold your breath, it’s highly unlikely that anyone of the Debian GNOME team will prepare backports of GNOME 3 for Debian 6.0 Squeeze. It’s already difficult enough to do everything right in unstable with a solid upgrade path from the current versions in Squeeze…

But if you are brave enough to want to install GNOME 3 with Debian 6.0 on your machine then I would suggest that you’re the kind of person who should run Debian testing instead (or even Debian unstable, it’s not so horrible). That’s what most people who like to run recent versions of software do.

How to run Debian testing

You’re convinced and want to run Debian testing? It’s really easy, just edit your /etc/apt/sources.list and replace “stable” with “testing”. A complete file could look like this:

# Main repository
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
# Security updates
deb http://security.debian.org/debian-security testing main contrib non-free

Now you should be able to run apt-get dist-upgrade and end up with a testing system.

How to install GNOME 3 on Debian testing aka wheezy

If you want to try GNOME 3 before it has landed in testing, you’ll have to add unstable and experimental to your sources.list:

deb http://ftp.debian.org/debian unstable main contrib non-free
deb http://ftp.debian.org/debian experimental main contrib non-free

You should not install GNOME 3 from experimental if you’re not ready to deal with some problems and glitches. Beware: once you upgraded to GNOME 3 it will be next to impossible to go back to GNOME 2.32 (you can try it, but it’s not officially supported by Debian).

To avoid upgrading all your packages to unstable, you will tell APT to prefer testing with the APT::Default-Release directive:

# cat >/etc/apt/apt.conf.d/local <<END
APT::Default-Release "testing";
END

To allow APT to upgrade the GNOME packages to unstable/experimental, you will also install the following pinning file as /etc/apt/preferences.d/gnome:

Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release experimental
Pin-Priority: 990

Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release unstable
Pin-Priority: 990

Package: *
Pin: release experimental
Pin-Priority: 150

Note that I used “Pin-Priority: 990” this time (while I used 500 in the article explaining how to install GNOME 3 on top of unstable), that’s because you want these packages to have the same priority than those of testing, and they have a priority of 990 instead of 500 due to the APT::Default-Release setting.

You’re done, your next dist-upgrade should install GNOME 3. It will pull a bunch of packages from unstable too but that’s expected since the packages required by GNOME 3 are spread between unstable and experimental.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

Journey of a new GNOME 3 Debian packager

April 11, 2011 by Raphaël Hertzog

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that’s not enough in this case, GNOME 3 is not fully packaged yet and it’s only in experimental for now.

I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there’s lots of work left. Instead Roland Mas gently answered me “Sooner if you help”. 🙂

First steps as a GNOME packager

This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I’m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org.

Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn’t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance.

Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version—usually 2.91—in experimental, but some are still at 2.30).

Packages updated and problems encountered

(You can skip this section if you’re not into GNOME packaging)

So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it’s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment.

Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log.

Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It’s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem.

In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus.

Help is still welcome

There’s still lots of work to do, you’re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don’t know).

Installation of GNOME 3 from Debian experimental

You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you’re ready to invest some time in understanding the remaining problems. It’s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues).

To help you out with this, here’s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500

Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it’s better than nothing.

I hope you find this useful. I’m enjoying my shiny new GNOME 3 desktop and it’s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.