Bug 1113612 - python bindings for graphics event have wrong value for address type
Summary: python bindings for graphics event have wrong value for address type
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Eric Blake
QA Contact: Fedora Extras Quality Assurance
Depends On: 1113316
TreeView+ depends on / blocked
Reported: 2014-06-26 13:57 UTC by Eric Blake
Modified: 2014-09-19 10:13 UTC (History)
12 users (show)

Fixed In Version: libvirt-
Doc Type: Bug Fix
Doc Text:
Clone Of: 1113316
Last Closed: 2014-09-19 10:13:50 UTC

Attachments (Terms of Use)

Description Eric Blake 2014-06-26 13:57:27 UTC
Cloning to Fedora; F19, F20, and rawhide are all impacted. Rawhide will pick up the fix when it rebases to libvirt 1.2.6.

+++ This bug was initially created as a clone of Bug #1113316 +++

Description of problem:
Due to a bug in libvirt-api.xml, the python bindings have declared VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4 = 1 even though the C code has defined it as 0.  Python code trying to handle VIR_DOMAIN_EVENT_ID_GRAPHICS that uses the symbolic name to decode its callback parameter will be acting on the wrong information.

Version-Release number of selected component (if applicable):
The bug has been present in upstream libvirt since 0.8.0

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
See this upstream thread:

Comment 1 Eric Blake 2014-06-27 02:33:58 UTC
Moving to POST:
v1.0.5-maint (F19) and v1.1.3-maint (F20) now contain the backport of:

commit 9b291bbe20c36c0820c6e7cd2bf6229bf41807e8
Author: Eric Blake <eblake@redhat.com>
Date:   Wed Jun 25 14:54:36 2014 -0600

    docs: publish correct enum values
    We publish libvirt-api.xml for others to use, and in fact, the
    libvirt-python bindings use it to generate python constants that
    correspond to our enum values.  However, we had an off-by-one bug
    that any enum that relied on C's rules for implicit initialization
    of the first enum member to 0 got listed in the xml as having a
    value of 1 (and all later members of the enum were equally
    The fix is simple - since we add one to the previous value when
    encountering an enum without an initializer, the previous value
    must start at -1 so that the first enum member is assigned 0.
    The python generator code has had the off-by-one ever since DV
    first wrote it years ago, but most of our public enums were immune
    because they had an explicit = 0 initializer.  The only affected
    enums are:
    - virDomainEventGraphicsAddressType (such as
    VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31e
    (libvirt v0.8.0)
    - virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
    since commit 9fbaff0 (libvirt v1.2.3)
    - virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
    03e0e79 (not yet released)
    Thanks to Nehal J Wani for reporting the problem on IRC, and
    for helping me zero in on the culprit function.
    * docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
    Signed-off-by: Eric Blake <eblake@redhat.com>

Comment 2 Fedora Update System 2014-09-14 19:00:31 UTC
libvirt- has been submitted as an update for Fedora 20.

Comment 3 Fedora Update System 2014-09-19 10:13:50 UTC
libvirt- has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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