Test failures on macOS 12

[Andrea Bolognani]

On Mon, Aug 08, 2022 at 08:54:14PM +0200, Christophe de Dinechin wrote:
> On Fri, May 06, 2022 at 03:00:14AM -0700, Andrea Bolognani wrote:
> > The other issue is in qemuxml2argvtest:
> >
> >  error : virCommandWait:2752 : internal error: Child process
> >    (/usr/libexec/qemu/vhost-user/test-vhost-user-gpu --print-capabilities)
> >    unexpected fatal signal 6: dyld[8896]: symbol not found in flat
> >    namespace '_virQEMUCapsGet'
> >  error : qemuVhostUserFillDomainGPU:394 : operation failed: Unable to
> >    find a satisfying vhost-user-gpu
>
> I don’t see this one.

Dang :(

> What I see instead is failures on qemucapabilitiestest.
> The tests seems to depend on a particular install path for the
> qemu-system- binaries:
>
>     binary = g_strdup_printf("/usr/bin/qemu-system-%s",
>                              data->archName);
>
> On macOS, there is something called “system integrity protection”
> which makes it a bit more difficult to add stuff to /usr/bin.
>
> However, I don’t really think that’s the problem.

We definitely shouldn't be looking at the contents of the build
machine's actual /usr/bin directory in our test suite! That'd be a
bug in our mocking machinery.

> I ran some tests with:
>
> VIR_TEST_DEBUG=1 VIR_TEST_RANGE=1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69 /Users/ddd/Work/libvirt/build/tests/qemucapabilitiestest
>
> The error I get seem to point to ‘hvf’ been unexected in the output:
>
> 15) 6.2.0 (x86_64)                                                    ...
> In '/Users/ddd/Work/libvirt/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml':
> Offset 7557
> Expect [c]
> Actual [hvf'/>
>   <flag name=‘c]
>
> I do not really understand what the test is supposed to do. It seems
> to be comparing with reference files, but where does it get the
> qemu capabilities to compare with from?

The test reads a .replies file from tests/qemucapabilitiesdata/,
parses it as if a QEMU binary had replied that way to our poking it,
figure out what the corresponding emulator capabilities are, format
them to XML and compare the result to the matching .xml file.

> How should I proceed?

I've prepared patches that should address the issue you're seeing:

  https://listman.redhat.com/archives/libvir-list/2022-August/233645.html

It'd be great if you could confirm that they work as intended.

-- 
Andrea Bolognani / Red Hat / Virtualization