[FFE] update pygobject to 2.90.1

Bug #828751 reported by Martin Pitt on 2011-08-18
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
pygobject (Ubuntu)
Undecided
Unassigned

Bug Description

There have been some recent developments and changes for pygobject recently, which would be good to get into Oneiric IMHO.

= Background =
pygobject currently provides two things:

  * static Python bindings for a few basic GNOME libraries, such as glib, gobject
  * dynamic gobject-introspection binding generator [https://live.gnome.org/PyGObject/IntrospectionPorting]

= Status Quo =
So far we have pygobject 2.28 in oneiric, which was the version shipped with GNOME 3.0. It ships both the static bindings (which are being deprecated, and there is e. g. no pygtk for GTK3), as well as a reasonably stable GI binding. During Natty and Oneiric we have ported many of our Ubuntu specific apps, as well as some GNOME ones from pygtk2 (static binding) to PyGI (i. e. using the GI bindings).

= 3.0 =

Recently there has been a 2.90.1 release for pygobject:
http://www.j5live.com/2011/08/14/announce-pygobject-2-90-1-released-3-0-pre-release/

The main changes are:

 * static bindings are dropped completely
 * A lot of bug fixing for bindings (handling of more data types, closures, etc.)
 * parallel installability with the 2.28 version
 * Much more robust GI bindings (e. g. the rewritten invoke catches a lot of errors as proper exceptions which previously went unnoticed and potentially caused hard-to-debug segfaults later on)
 * This is now absolutely zero tolerant against importing both the static and the GI version of a particular library. This was mostly the case with 2.28 as well, but did work in some cases (like "import gobject; from gi.repository import Gtk", in particular for "glib" and "gobject"). These now cause errors as well.

It seems the current plan is that GNOME 3.2 will require pygobject 3.0, and recently the jhbuild module set was switched over accordingly:

  http://git.gnome.org/browse/jhbuild/commit/?id=8878eecb377f

= Proposal =

 * Package the old pygobject-2 separately, and disable GI support there. This is just about zero risk, and means that all applications which use pygtk and the old static bindings (such as software-center, and a lot of other older software) continue running.

 * Update pygobject to 2.90.1. (see below for impact)

The main difficulty is to make the package install cleanly in parallel. This work has already been done by Martin Pitt in the Debian svn, and uploaded to experimental:
  http://packages.qa.debian.org/p/pygobject/news/20110817T101759Z.html
  http://packages.qa.debian.org/p/pygobject-2/news/20110818T133252Z.html

= Impact =

The update will cause a lot of GI based python applications to stop working, as it is a very common error to mix static and GI bindings. I already went through most of our GI applications yesterday and prepared them for the switch, in case to be ready if/when we do it.

  https://launchpad.net/ubuntu/+source/software-properties/0.81.8
  https://launchpad.net/ubuntu/+source/aptdaemon/0.43+bzr669-0ubuntu1
  https://code.launchpad.net/~pitti/software-center/gi-fixes/+merge/71854
  https://launchpad.net/ubuntu/+source/usb-creator/0.2.31.2
  (and some more, basically everything I could find except for ubiquity, which I didn't check yet)

While I tested our apps with the new pygobject lightly, I cannot guarantee that they all work without any regression. I am happy to work on fallout if it happens, though.

On the pro side, we'll get the better performance and stability of the rewritten invoker, and also a better platform where new code should be written on, to avoid the bugs introduced by the overly tolerant 2.28 version.

Packages are available for testing in https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages.

Martin Pitt (pitti) on 2011-08-18
description: updated
description: updated
description: updated
Alex Eftimie (alexeftimie) wrote :

It's worth noting that without the invoke rewrite in 2.90 introspected libraries implementing GPtrArrays (such as PackageKit sic) won't work, giving segfaults.

So, +1 for having this in oneiric.

Changed in pygobject (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) on 2011-08-18
Changed in pygobject (Ubuntu):
status: Confirmed → New
Xavier Claessens (zdra) wrote :

Notice that some new telepathy-glib API gives segfault with previous pygobject. Fixed in 2.90.1.

Martin Pitt (pitti) wrote :

Known regressions so far in:

oneconf-service (oneconf source) -> to be investigated
gnome-sudoku: TypeError: 'Color" object does not support indexing -> TBI
ubuntuone-control-panel-gtk -> trivial fix, will do ASAP
gnome-language-selector -> trivial fix, will do ASAP

Martin Pitt (pitti) wrote :

language-selector (0.47) oneiric; urgency=low

  * LanguageSelector/gtk/GtkLanguageSelector.py: Move from static gobject to
    GI GObject module, to be compatible to upcoming pygobject 3.0.

 -- Martin Pitt <email address hidden> Thu, 18 Aug 2011 17:22:50 +0200

Iain Lane (laney) wrote :

I'd appreciate a tracking bug so that we can keep an eye on where we are with fixing regressions, but if we have that then I'm comfortable with this, providing you ensure that you shepherd the changes through

Approved.

Changed in pygobject (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :

Tracking bug is bug 829186.

Note that wrt. comment 3 I didn't include language-selector as it's already fixed, and gnome-sudoku because the error message you get is a different one and does not stop the program from working. The error happens with 2.28 as well, but wasn't displayed as such.

Martin Pitt (pitti) wrote :

All known programs which mix GI and static bindings have been fixed, see tracking bug.

However, ubiquity segfaults with the new pygobject, I track this in bug 834168.

Martin Pitt (pitti) wrote :

Meh, after I found a fix for bug 834168, ubiquity now exposes a final "mix static and GI" problem, I reopened the task in bug 829186.

Martin Pitt (pitti) wrote :

No further known breakage with 2.90, and this blocks updates of other applications. Bug 834168 has a safe workaround (in fact, the very same workaround that 2.28 had), and I have a branch to fix ubiquity.

I synced pygobject and pygobject-2, and uploaded a corresponding gobject-introspection which drops our hack to make it work with pygobject 2.28.

Changed in pygobject (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers