Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1114379 - 'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'
'gi.repository.Vte' object has no attribute 'TerminalCursorBlinkMode'
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-29 15:53 EDT by Igor Gnatenko
Modified: 2014-11-06 08:05 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-07 16:58:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Igor Gnatenko 2014-06-29 15:53:33 EDT
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 12:40:54 EDT
I assume this is on rawhide? What version of vte3?
Comment 2 Igor Gnatenko 2014-07-01 12:45:02 EDT
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 12:47:44 EDT
https://bugzilla.gnome.org/show_bug.cgi?id=732440
Comment 4 Cole Robinson 2014-07-02 09:23:18 EDT
We can safely drop those broken API calls anyways, so that will work around the issue:

commit 3c2dc15af77d393e492736c79166970bb029acc5
Author: Cole Robinson <crobinso@redhat.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 19:42:57 EDT
(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 19:51:28 EDT
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-25 20:02:07 EDT
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-25 20:39:42 EDT
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 07:39:39 EDT
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 08:23:40 EDT
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 16:58:12 EDT
Fixed in virt-manager-1.1.0-1.fc22
Comment 12 Egmont Koblinger 2014-11-06 08:05:14 EST
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.