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

Asked by David Roberts on 2009-12-08

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?

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar GTK+ Frontends Edit question
Assignee:
No assignee Edit question
Solved by:
David Roberts
Solved:
2009-12-08
Last query:
2009-12-08
Last reply:
David Roberts (smartgpx) said : #1

To partially answer my own question -

the 'troublesome' line of code in revisionview.py was introduced at -r448.

Taking the version of revisionview.py from r447 and using that in the current tip release appears to give a working solution for a number of commands including gannotate, gbranch, gcheckout, ginfo, gmissing, gsend, gtags.

I'm not sure what functionality - if any - I am missing, or whether this 'hack' is in any way dangerous?

the 'visualise' command - in some ways the most interesting - now fails elsewhere - in branchwin.py with gtk.Action.set_tool_item_type. Perhaps there is a similar workaround?

David Roberts (smartgpx) said : #2

And as the final step in this stream of consciousness...

as before, set_tool_item_type became available in PyGtk 2.10, which I don't have.

commenting out the line gtk.Action.set_tool_item_type(... ) from viz/branchwin.py allows 'bzr visualise' to run.

there must be some reason why Daniel Schierbeck added that, but I'm not clear what I've lost by taking it away.

and following the same method, I've brought revisionview.py uptodate again and simply commented out line 53:gtk.link_button_set_uri_hook(... ) and all still seems to be well.

I'm marking this 'Problem solved'. If any bzr-gtk developer wants to tell me a more elegant way to tackle this I'm ready to listen. But "run a better operating system" isn't a useful answer - at least it's not Windows!

Vincent Ladeuil (vila) said : #3

I just created https://bugs.edge.launchpad.net/bzr-gtk/+bug/494140

It would be great if you can followup there and create a merge proposal with your modifications so we can find a fix.

Thanks for reporting the problem and investigating a working solution !

Jelmer Vernooij (jelmer) said : #4

On Tue, 2009-12-08 at 16:13 +0000, David Roberts wrote:
> New question #93341 on Bazaar GTK+ Frontends:
> https://answers.launchpad.net/bzr-gtk/+question/93341
>
> 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?
I think somebody was working on providing backwards compatibility with
older versions of PyGTK; perhaps that work is not complete.

Our intention certainly is to not rely on the very latest PyGTK
releases, and what ever is in Etch is something we should definitely
support.

Cheers,

Jelmer

David Roberts (smartgpx) said : #5

This was subsequently submitted as Bug #494140.

Progress on this has ceased. I had concluded that it was thought
unimportant. I have a private fork of the code which is running on
xandros to my satisfaction.

On 06/04/2010, Jelmer Vernooij <email address hidden> wrote:
> Your question #93341 on Bazaar GTK+ Frontends changed:
> https://answers.launchpad.net/bzr-gtk/+question/93341
>
> Jelmer Vernooij posted a new comment:
> On Tue, 2009-12-08 at 16:13 +0000, David Roberts wrote:
> > New question #93341 on Bazaar GTK+ Frontends:
> > https://answers.launchpad.net/bzr-gtk/+question/93341
> >
> > 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?
> I think somebody was working on providing backwards compatibility with
> older versions of PyGTK; perhaps that work is not complete.
>
> Our intention certainly is to not rely on the very latest PyGTK
> releases, and what ever is in Etch is something we should definitely
> support.
>
> Cheers,
>
> Jelmer
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

Jelmer Vernooij (jelmer) said : #6

On Wed, 2010-04-07 at 07:27 +0000, David Roberts wrote:
> Question #93341 on Bazaar GTK+ Frontends changed:
> https://answers.launchpad.net/bzr-gtk/+question/93341
>
> David Roberts posted a new comment:
> This was subsequently submitted as Bug #494140.
>
> Progress on this has ceased. I had concluded that it was thought
> unimportant. I have a private fork of the code which is running on
> xandros to my satisfaction.
Development on bzr-gtk has slowed down in the last year or so, so things
other than important bugs haven't really been addressed recently. We'd
be interested in merging your changes.

Cheers,

Jelmer

David Roberts (smartgpx) said : #7

I've pushed my fork again, this time to lp:~smartgpx/bzr-gtk/workaround_for_lp494140_B

Jelmer Vernooij (jelmer) said : #8

On Mon, 2010-04-12 at 15:16 +0000, David Roberts wrote:
> Question #93341 on Bazaar GTK+ Frontends changed:
> https://answers.launchpad.net/bzr-gtk/+question/93341
>
> David Roberts posted a new comment:
> I've pushed my fork again, this time to lp:~smartgpx/bzr-
> gtk/workaround_for_lp494140_B
>

Can you please request a merge into lp:bzr-gtk as well?

Thanks!

Cheers,

Jelmer