Bug 1114379 - 'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'
Summary: 'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-06-29 19:53 UTC by Igor Gnatenko
Modified: 2014-11-06 13:05 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-09-07 20:58:12 UTC
Type: Bug

Attachments (Terms of Use)

Description Igor Gnatenko 2014-06-29 19:53:33 UTC
Error launching details: 'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 786, in _show_vm_helper
  File "/usr/share/virt-manager/virtManager/details.py", line 1389, in activate_default_page
  File "/usr/share/virt-manager/virtManager/details.py", line 1383, in activate_default_console_page
  File "/usr/share/virt-manager/virtManager/console.py", line 1599, in activate_default_console_page
    self._show_serial_tab(name, serialidx)
  File "/usr/share/virt-manager/virtManager/console.py", line 1658, in _show_serial_tab
    serial = vmmSerialConsole(self.vm, target_port, name)
  File "/usr/share/virt-manager/virtManager/serialcon.py", line 319, in __init__
  File "/usr/share/virt-manager/virtManager/serialcon.py", line 329, in init_terminal
  File "/usr/lib64/python2.7/site-packages/gi/module.py", line 320, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib64/python2.7/site-packages/gi/module.py", line 139, in __getattr__
    self.__name__, name))
AttributeError: 'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'

Comment 1 Cole Robinson 2014-07-01 16:40:54 UTC
I assume this is on rawhide? What version of vte3?

Comment 2 Igor Gnatenko 2014-07-01 16:45:02 UTC
0.36.3 on rawhide. 

That's after connect to lxc with virt-manager and add container with sh. I've tried to open console in virt-manager.

Comment 3 Igor Gnatenko 2014-07-01 16:47:44 UTC

Comment 4 Cole Robinson 2014-07-02 13:23:18 UTC
We can safely drop those broken API calls anyways, so that will work around the issue:

commit 3c2dc15af77d393e492736c79166970bb029acc5
Author: Cole Robinson <crobinso>
Date:   Wed Jul 2 09:18:59 2014 -0400

    serialcon: Remove some redundant VTE API calls
    Latest VTE doesn't seem to provide set_emulation anymore, and the other
    two seem to be the default anyways. This also avoids some VTE bindings
    breakage on current rawhide:

But something is still broken on the VTE side

Comment 5 Egmont Koblinger 2014-07-25 23:42:57 UTC
(In reply to Cole Robinson from comment #4)

> But something is still broken on the VTE side

I don't think so.

VTE-0.37's API is incompatible with VTE-0.36.  But, for exactly this reason, the library installs with a different name ("vte2.90" vs. "vte-2.91").

The two variants can safely coexist (Rawhide ships both), and in order to include its headers, link to it, or to use the library, you always need to specify the exact name (including the 2.90 or 2.91 version specifier).  Pretty much as if the two libraries had nothing to do with each other.

If you're coding your app against vte-0.36's API but try to link with libvte-2.91, that's an error on your side.

Comment 6 Cole Robinson 2014-07-25 23:51:28 UTC
This is a python application using gobject introspection to interact with vte, there is no explicit linking taking place on our side. We are just doing 'from gi.repository import Vte'. Are there multiple Vte API versions available via gobject introspection?

Comment 7 Egmont Koblinger 2014-07-26 00:02:07 UTC
There should be.

vte3-devel-0.36.3-2.fc22.x86_64.rpm ships /usr/share/gir-1.0/Vte-2.90.gir
vte291-devel-0.37.2-2.fc22.x86_64.rpm ships /usr/share/gir-1.0/Vte-2.91.gir
I guess these are the relevant files.

Unfortunately I don't know anything about GIR or how Python chooses the version, but I'm almost sure there's a way to specify.

When coding in C, you can't include/link against vte in general, you can only include or link either vte-2.90 or vte-2.91.  I don't know how "import Vte" figures out which one to use.

Comment 8 Egmont Koblinger 2014-07-26 00:39:42 UTC
This is how you can import a specific version:

import gi
gi.require_version('Vte', '2.90')
from gi.repository import Vte

Comment 9 Egmont Koblinger 2014-07-28 11:39:39 UTC
The more I think about it, the more certain I become that GIR is fundamentally horribly brain-damaged.

The C standard library framework, by putthing the major library version in the SONAME, has for decades solved the problem of installing parallel incompatible versions of the same runtime library along each other and keep applications working.  The way Gnome stores its libraries and header files extend this to the development environment too: you can install multiple development package versions in parallel and choose in your project which one you develop for.  The key in doing this is always that you have to specify the major version number.

And then here comes python GIR which breaks these fundamentals.  From now on, you can have a perfectly working code on your system, then install a newer, backwards incompatible major version of a library *along* with the existing version, and suddenly your code breaks.

This is nonsense :(

Comment 10 Cole Robinson 2014-07-28 12:23:40 UTC
Probably best to open a bug against gobject-introspection so relevant developers will read your comment, I don't think any of them are watching here

Comment 11 Cole Robinson 2014-09-07 20:58:12 UTC
Fixed in virt-manager-1.1.0-1.fc22

Comment 12 Egmont Koblinger 2014-11-06 13:05:14 UTC
Upstream issue: https://bugzilla.gnome.org/show_bug.cgi?id=727379

Note You need to log in before you can comment on or make changes to this bug.