Bug 1113612

Summary: python bindings for graphics event have wrong value for address type
Product: [Fedora] Fedora Reporter: Eric Blake <eblake>
Component: libvirtAssignee: Eric Blake <eblake>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: agedosier, berrange, clalancette, crobinso, eblake, itamar, jforbes, laine, libvirt-maint, rbalakri, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-1.1.3.6-1.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1113316 Environment:
Last Closed: 2014-09-19 10:13:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1113316    
Bug Blocks:    

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:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
See this upstream thread:
https://www.redhat.com/archives/libvir-list/2014-June/msg01290.html

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>
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
    botched).
    
    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
    values.
    
    Signed-off-by: Eric Blake <eblake>

Comment 2 Fedora Update System 2014-09-14 19:00:31 UTC
libvirt-1.1.3.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2014-10432/libvirt-1.1.3.6-1.fc20

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