For armhf you'd also need the following patch until the underlying issue is resolved.
-- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Description: fix tests on 32bit armhf There seems to be an underlying issue with gulong variables, for now mask the value in the test to get the correct 32bit result that it checks on. I forwarded the case in below IRC discussion, but the fix is only a band aid for our builds until the underlying issue is fixed. IRC snippet: <cpaelzer> danp: jtomko: but I wonder about the result - it works on all architectures but armhf for me - the version that is returned is odd <cpaelzer> it is 17830927092969874672 <jtomko> cpaelzer: the lower 32 bits of the number you posted are 6006000 <cpaelzer> hmm, so we could need a mask then on armhf <jtomko> virtDBusConnectGetLibVersion sets "t" as the type (u64) but passes a gulong there <cpaelzer> the type auto-set for var is <class 'dbus.UInt64'> <jtomko> cpaelzer: it might not be the only libvirt-dbus API broken on 32-bit. a quick 'git grep gulong' shows we use it even for APIs that take long long sometimes <cpaelzer> jtomko: just for confirmation ver &= 0xFFFFFFFF indeed "fixes" the issue <cpaelzer> but yes there might be a bigger underlying issue in regard to the gulong usage Forwarded: IRC Author: Christian Ehrhardt <christian.ehrha...@canonical.com> Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971171 Last-Update: 2019-06-30 --- a/tests/test_domain.py +++ b/tests/test_domain.py @@ -158,6 +158,8 @@ class TestDomain(libvirttest.BaseTestCla # on host CPU topology instead of its fake topology obj = self.bus.get_object('org.libvirt', '/org/libvirt/Test') ver = obj.Get('org.libvirt.Connect', "LibVersion", dbus_interface=dbus.PROPERTIES_IFACE) + # There is a problem on 32bit architectures, for now mask this value + ver &= 0xFFFFFFFF if ver == 6006000: pytest.skip("CPU toploogy is broken in libvirt 6.6.0 test driver")
