Red Hat Bugzilla – Bug 1114379
'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'
Last modified: 2014-11-06 08:05:14 EST
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
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__
AttributeError: 'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'
I assume this is on rawhide? What version of vte3?
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.
We can safely drop those broken API calls anyways, so that will work around the issue:
Author: Cole Robinson <firstname.lastname@example.org>
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
(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.
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?
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.
This is how you can import a specific version:
from gi.repository import Vte
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 :(
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
Fixed in virt-manager-1.1.0-1.fc22
Upstream issue: https://bugzilla.gnome.org/show_bug.cgi?id=727379