Sun, 03 Jun 2012

GNOME 3.4 in wheezy

Users of Debian sid will have noticed: the final (and interesting) bits of GNOME 3.4 have landed and if all looks as good as it does now, they should migrate to wheezy in about a week.

3.2 → 3.4 hasn't been as complicated as the previous horrible transition, but still had some complications due to Cogl/Clutter incompatibilities. Other than that, our major problem has been manpower, but this isn't new for many other Debian teams. We've also seen new incarnations of “Linux-only technology is now mandatory” which makes our lives a bit more miserable due to kfreebsd-* and hurd-i386, but for now we've still been able to dodge it. It seems wheezy+1 will be fun in that regard though, and we might need to take drastic approaches.

If all goes well and the current lot (GNOME Shell, Control Center, Settings daemon, Mutter...) transitions without additional problems, we should be wrapping up our transitions for wheezy with Evolution and friends (currently sitting in experimental), and hopefully GDM 3.4.

As we get many questions regarding the status of GDM in Debian, let's add a short note on this. Packaging GDM, at least in its current upstream form, is not a matter of unpacking a new tarball and editing debian/changelog. When Joss works on a new major version, the amount of tweaking to break away from stuff that works on other distros but is not so simple in Debian is outstanding (see, for example, the current unfinished work for GDM 3.2 in our SVN repo). In our case, to handle our GDM defaults, we even need changes to the underlying configuration system, dconf. This evidently takes some effort to do, and unfortunately our GDM expert has had little time for Debian lately, but we're confident we'll end up with a GDM in wheezy that is on par with Debian standards.

We are, as always, reachable at #debian-gnome in the OFTC IRC network. Have fun!

I've noticed several mentions in GNOME package changelogs about disabling systemd-related functionality.  I realize you want to keep compatibility with non-Linux kernels, but what about preserving that functionality for people actually running Linux?

Posted by Anonymous at Sun Jun 3 15:30:13 2012

I'd seen mentions in the GNOME 3.4 release notes about maximizing windows by default; however, the Debian-packaged GNOME 3.4 doesn't seem to do that.  Did that change not actually make it into GNOME 3.4 upstream?

Posted by Anonymous at Sun Jun 3 15:31:33 2012

Are there any plans to update gdm3 (3.4 looks really better than 3.0).

Posted by Dmitry Shachnev at Sun Jun 3 16:28:56 2012

Hi Jordi, thanks for the status update. You are doing a great job :-). Can you explain, why there are so many Debian specific changes necessary. Btw, what's up with Gnome Disk Utility?

Posted by Wiekalt Heut at Sun Jun 3 19:11:27 2012

@Wiekalt Heut: gnome-disk-utility 3.4 requires udisks2, which is a complete rewrite of udisks(1).
The udisks2 code-base is still pretty young, and e.g. KDE hasn't been ported to udisks2 yet, so we would need udisks1 for wheezy anyway.
While udisks1 and udisks2 can be co-installed, we didn't want to ship both udisks1 and udisks2 for wheezy.

That said, udisks2 is currently in experimental, and we will update gvfs to udisks2 in wheezy+1

Posted by Michael Biebl at Sun Jun 3 20:07:16 2012

@anoymous: wrt systemd: systemd is not the default init system for Debian yet.
There are basically three big areas where systemd comes into play considering GNOME:

1/ system services shipping systemd .service files, like e.g. upower. This can be enabled without a problem as packages continue to ship sysv init scripts resp. native dbus service files. We already have ~50 packages shipping native system service files, ie. with a default GNOME desktop installation there are not that many LSB/sysv services left if install and run systemd.

2/ systemd providing the timedate/hostname/locale mechanisms. These are used in gnome-settings-daemon and gnome-control-center to change the system locale or clock. As we can't rely yet on systemd being available everywhere, we use the builting mechanisms for now.

3/ systemd-logind [2], which provides user session and seat tracking. This is basically the successor of ConsoleKit. Not all packages support a run-time fallback for ConsoleKit, so you need to decide during compile time, to support only systemd or ConsoleKit. This obviously doesn't work, if we can't rely on systemd being PID 1.
So we've decided to stay with ConsoleKit everywhere for seat and session tracking in wheezy, even if some packages provide a runtime-fallback, i.e. support both systemd-logind and ConsoleKit and decide during runtime which one to use.


Posted by Michael Biebl at Sun Jun 3 20:23:41 2012

@Wiekalt Heut: I wanted to add, that udisks1 is a tested and proven code base, so switching to udisks2 seemed risky. Also, as mentioned, KDE still depends on udisks1. So if you use a KDE application under your GNOME desktop and e.g. open the KDE file selector, a udisks1 daemon would be auto-started by D-Bus and you would have both udisks1 and udisks2 running. This seemed sub-optimal to us.
We will do a full switch to udisks2 in wheezy+1

Posted by Michael Biebl at Sun Jun 3 20:40:34 2012

This sid-user just wants to thank you for the amazing work!

Posted by djcb at Mon Jun 4 09:28:13 2012