ninja command failing for upstream libvirt compilation

[bugproxy]

== Comment: #0 - SEETEENA THOUFEEK <email address hidden> - 2024-02-21 23:07:48 ==
+++ This bug was initially created as a clone of Bug #204087 +++

---Problem Description---
 ninja command failing for upstream libvirt compilation

---uname output---
x

Machine Type = x

Contact Information = x

---Steps to Reproduce---
 +++ This bug was initially created as a clone of Bug #204087 +++

---Problem Description---
- ninja command failing for upstream libvirt compilation

Contact Information = <email address hidden>

---Debugger---
A debugger is not configured

Machine Type = x

---uname output---
x

---Steps to Reproduce---
 Problem:
While compiling Upstream libvirt on bare-metal environments, the command "ninja -C build" fails.

Note:
The error is inconsistent but it is huge blocker for kvm-ci
To reproduce the error, it is advisable to do fresh compilation of upstream libvirt
The below description contains a small snippet of the error
Full error message/log is attached below as console.log

Prerequisites:
1. Bare-metal machine
2. dnf install git
3. pip3 install Ninja meson

Steps to reproduce:
1. git clone https://github.com/libvirt/libvirt.git -b master
2. cd libvirt
3. meson build --prefix=/usr -Dsystem=true -Ddriver_qemu=enabled -Ddriver_libvirtd=enabled -Ddriver_remote=enabled
4. ninja -C build

Error:
....
....
In file included from ../src/remote/remote_daemon.h:28,
                 from ../src/remote/remote_daemon_stream.h:23,
                 from ../src/remote/remote_daemon_stream.c:24:
src/remote/lxc_protocol.h:13:5: error: unknown type name 'remote_nonnull_domain'
     remote_nonnull_domain dom;
     ^~~~~~~~~~~~~~~~~~~~~
In file included from ../src/remote/remote_daemon.h:29,
                 from ../src/remote/remote_daemon_stream.h:23,
                 from ../src/remote/remote_daemon_stream.c:24:
src/remote/qemu_protocol.h:13:5: error: unknown type name 'remote_nonnull_domain'
     remote_nonnull_domain dom;
     ^~~~~~~~~~~~~~~~~~~~~
src/remote/qemu_protocol.h:14:5: error: unknown type name 'remote_nonnull_string'
     remote_nonnull_string cmd;
     ^~~~~~~~~~~~~~~~~~~~~
src/remote/qemu_protocol.h:22:5: error: unknown type name 'remote_nonnull_string'
     remote_nonnull_string result;
     ^~~~~~~~~~~~~~~~~~~~~
src/remote/qemu_protocol.h:37:5: error: unknown type name 'remote_nonnull_domain'
     remote_nonnull_domain dom;
     ^~~~~~~~~~~~~~~~~~~~~
src/remote/qemu_protocol.h:44:5: error: unknown type name 'remote_nonnull_domain'
     remote_nonnull_domain dom;
....

https://github.com/libvirt/libvirt/commit/dcfe548cb01d64e2bdeac456c428e578158232b9.

Please include this commit in latest canonical

[Frank Heimes (fheimes)]

Many thanks for raising this issue!

Which is the Ubuntu release you have used while facing this?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2024-02-23 00:22 EDT-------
(In reply to comment #4)
> Many thanks for raising this issue!
>
> Which is the Ubuntu release you have used while facing this?

We have seen this issue while testing baremetal with different distro where upstream compilation of libvirt fails and upstream community had provided patch fixing this. We have opened this bug to notify the other distro's which helps the distro team to be aware of the known issue running with patch identified so they could include these patch in respective release.

Can you check if you could recreate this issue on latest canonical ?

[Frank Heimes (fheimes)]

Looks like the commit is relatively new,
and fo far it's not incl. in the libvirt version that we currently have in 'noble' aka 24.04:
libvirt0 | 10.0.0-1ubuntu1 | noble | amd64, arm64, armhf, ppc64el, riscv64, s390x
So I've created a patched package, and started a test build here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp2054632
(Btw, we build the Ubuntu libvirt packages in a different way.)

[Sergio Durigan Junior (sergiodj)]

Hello,

As Frank mentioned, it would be really useful if we could actually reproduce this problem with our package. Also, I'm curious about something. If you are building libvirt directly from upstream sources, would it really make a difference if our package had the patch after all?

Thank you in advance.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2024-03-04 03:47 EDT-------
Hi Frank and all,
1.There is no functional problem was addressed with this bug fix.
2. if anyone uses libvirt 9.10.0 to less than 10.1.0. The parallel build on ppc will fail. Then we need this patch. So it is purely build time issue when you use parallel build.

Thanks & regards,
Narayana Murty

[Frank Heimes (fheimes)]

Hello Narayana Murty, okay, so we are on the same page.

Since we build the libvirt package in a different way that does not require this patch (and we don't see other/further failures while building the Ubuntu libvirt DEB packages),
and since any update of the libvirt package would come with a certain (regression) risk
and will also causes effort for all users having libvirt installed (either affected or not),
we will not pick up this patch for the Ubuntu DEB package (I guess that is understandable).

In case someone wants to compile the latest code manually from upstream,
and takes it (clones it) from there, he/she will nowadays with get the needed fix as well (since it's now incl. in master v10.1.0).
Hence no further action (or patching) is needed anymore in case of such a manual compile.

With that I'm closing this LP bug as "Invalid" - which is not an offence (even if the status may sound harsh), since 'Invalid' incl. situations known as "not a bug", which implies here that it is not a bug in the Ubuntu DEB package.

I hope you agree on that.