Red Hat Bugzilla – Bug 1113332
python bindings for graphics event have wrong value for address type
Last modified: 2015-03-05 02:40:27 EST
Cloning to RHEL 7 +++ 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 --- Additional comment from RHEL Product and Program Management on 2014-06-25 17:41:48 MDT --- Since this bug report was entered in bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Fixed upstream; 7.1 will get it via rebase: 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 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@redhat.com>
Verify it as follows. The result is expected. Move its status to VERIFIED. # rpm -q libvirt libvirt-python libvirt-1.2.8-8.el7.x86_64 libvirt-python-1.2.8-5.el7.x86_64 # grep -n VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4 /usr/lib64/python2.7/site-packages/libvirt.py 5674:VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4 = 0 # python -c "import libvirt; print libvirt.VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4" 0
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html