Many components of gtk failing on linux (debian-etch)

Bug #494140 reported by Vincent Ladeuil on 2009-12-08
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar GTK+ Frontends
Low
David Roberts

Bug Description

My machine is an asus Eeepc 701 'netbook'. The operating system is the supplier's version of xandros, which I understand to be closely related to debian etch.

Bzr is 2.1.0b3. I have branched gtk 0.98.0dev1 [r671] to my plugins directory.

Some bzr-gtk commands seem to work correctly, including gcommit, gconflicts, gdiff, ginit, gprefs, gpush, gstatus.

The others fail. This includes gannotate, gbranch, gcheckout, ginfo, gmerge, gmissing, gsend, gtags, visualise.

The error is common to the above. Line 54 of revisionview.py: gtk.link_button_set_uri_hook(_open_link)
AttributeError: 'module' object has no attribute 'link_button_set_uri_hook'

API documentation for gtk suggests that 'link_button_set_uri_hook' was introduced at 2.10 of PyGtk.

The version of PyGtk available from debian-etch repositories is 2.8.6-8.

Is there any patch or workaround for this, or do I have to conclude that bzr-gtk is not compatible with my Operating System? Are there any older but still functional releases of bzr-gtk that would not have PyGtk 2.10 as a pre-requisite?

Related branches

Vincent Ladeuil (vila) on 2009-12-08
Changed in bzr-gtk:
status: New → Confirmed
importance: Undecided → High
David Roberts (smartgpx) wrote :

gtk.link_button_set_uri_hook is referenced in revisionview.py
gtk.Action.set_tool_item_type is referenced in viz/branchwin.py

These are PyGtk 2.10 innovations. debian-etch supplies PyGtk 2.8.6-8

Both uses appear to be 'cosmetic' - they do not seem to set up or manipulate objects that the code later relies upon.

As a workaround - to prove that the remainder of the code runs successfully - simply commenting out these references seems to be effective. But I don't have enough knowledge of python, gtk or the bzr-gtk codebase to know whether there are unacceptable consequences to this.

'Proof of concept' branch proposed for merge to encourage discussion.

On Wed, 2009-12-09 at 10:56 +0000, David Roberts wrote:
> gtk.link_button_set_uri_hook is referenced in revisionview.py
> gtk.Action.set_tool_item_type is referenced in viz/branchwin.py
>
> These are PyGtk 2.10 innovations. debian-etch supplies PyGtk 2.8.6-8
>
> Both uses appear to be 'cosmetic' - they do not seem to set up or
> manipulate objects that the code later relies upon.
>
> As a workaround - to prove that the remainder of the code runs
> successfully - simply commenting out these references seems to be
> effective. But I don't have enough knowledge of python, gtk or the bzr-
> gtk codebase to know whether there are unacceptable consequences to
> this.
>
> 'Proof of concept' branch proposed for merge to encourage discussion.
To not degrade the functionality on platforms that do have newer
versions of pytgtk, we should check if those functions are present
before we call them.

David, where is your attached branch? Could you perhaps update it to
include these checks?

  status triaged
  importance low

Changed in bzr-gtk:
importance: High → Low
status: Confirmed → Triaged
David Roberts (smartgpx) wrote :

I'm out of my depth here, in several different areas.

1. I thought I had pushed a later revison to the location linked as a merge propose branch from the LP bzr-gtk page. But LP returns an error message rather than serving the branch. Should I delete it from LP and try again?

2. re: performance on platforms with better versions of pygtk. Putting in a check to see if a function is present is clearly going to be a performance hit compared with not doing the check. At run-time I don't see a way round that - either we check even though for most people it's a time-waster, or for some people there is a run-time error. Maybe the work-around is to make it a build-time option?

3. However... noone has marked this bug 'Affects me too' or logged a duplicate. Maybe the cost of a fix outweighs the benefits? So I'm content to simply run this as a local fork for my own benefit and leave the released version alone. There can't be very many bzr users wanting to struggle with an under-supported OS on a netbook with a 7" screen!

Jelmer Vernooij (jelmer) on 2011-02-14
Changed in bzr-gtk:
status: Triaged → Fix Committed
Jelmer Vernooij (jelmer) on 2011-02-18
Changed in bzr-gtk:
milestone: none → 0.100.0
Jelmer Vernooij (jelmer) on 2011-03-02
Changed in bzr-gtk:
status: Fix Committed → Fix Released
assignee: nobody → David Roberts (smartgpx)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions