|Summary:||'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'|
|Product:||[Fedora] Fedora||Reporter:||Igor Gnatenko <ignatenko>|
|Component:||virt-manager||Assignee:||Cole Robinson <crobinso>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||acathrow, berrange, crobinso, egmont, gscrivan, ignatenko, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-09-07 20:58:12 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 details.activate_default_page() File "/usr/share/virt-manager/virtManager/details.py", line 1389, in activate_default_page self.activate_default_console_page() File "/usr/share/virt-manager/virtManager/details.py", line 1383, in activate_default_console_page self.console.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__ self.init_terminal() File "/usr/share/virt-manager/virtManager/serialcon.py", line 329, in init_terminal self.terminal.set_cursor_blink_mode(Vte.TerminalCursorBlinkMode.ON) 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 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 <email@example.com> 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: https://bugzilla.redhat.com/show_bug.cgi?id=1114379 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