On 01.08.2022 10:43, Julien Grall wrote: > (+ Committers) > > Hi Jan, > > On 01/08/2022 09:36, Jan Beulich wrote: >> On 29.07.2022 19:36, Julien Grall wrote: >>> Hi Jan, >>> >>> On 29/07/2022 07:22, Jan Beulich wrote: >>>> On 29.07.2022 03:04, osstest service owner wrote: >>>>> branch xen-unstable-smoke >>>>> xenbranch xen-unstable-smoke >>>>> job build-amd64-libvirt >>>>> testid libvirt-build >>>>> >>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git >>>>> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git >>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git >>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git >>>>> Tree: xen git://xenbits.xen.org/xen.git >>>>> >>>>> *** Found and reproduced problem changeset *** >>>>> >>>>> Bug is in tree: xen git://xenbits.xen.org/xen.git >>>>> Bug introduced: 66dd1c62b2a3c707bd5c55750d10a8223fbd577f >>>>> Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce >>>>> Last fail repro: >>>>> http://logs.test-lab.xenproject.org/osstest/logs/171909/ >>>>> >>>>> >>>>> commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f >>>>> Author: Oleksandr Tyshchenko <[email protected]> >>>>> Date: Fri Jul 15 22:20:24 2022 +0300 >>>>> >>>>> libxl: Add support for Virtio disk configuration >>>> >>>> Just in case you didn't notice it: Something's wrong here. I didn't look >>>> at the details at all. Please advise whether a fix will soon arrive or >>>> whether we should revert for the time being. >>> >>> We had discussion on IRC about this today. This is an issue in libvirt >>> rather than Xen. So I think a revert is not warrant here. >>> >>> Instead, it was suggested to force push because it is going to take some >>> times to fix libvirt (see more below). >>> >>> Oleksandr already sent a patch to fix libvirt [1]. The problem is even >>> if this is accepted, our testing branch for libvirt is 2 years behind >>> because they switched to Meson and Osstest has not been adapted to the >>> new build system. >>> >>> Anthony kindly offered to update Osstest. >>> >>> Regarding force pushing, I am waiting for the Osstest result to confirm >>> that only the libvirt tests are failing in staging (we already have the >>> results for smoke). So my plan is to force push on Monday. >>> >>> Please let me know on Monday morning if you have some concerns with this >>> approach. >> >> Actually I do - if we force push, the libvirt failure will stick, and >> hence potential further regressions introduced there would not be noticed. > > Well... We haven't had any push in libvirt for the past 2 years. So to > me it shows that nobody really care about the testing done. Therefore, I > don't see the problem if we don't spot further regressions.
I don't understand, or maybe I did express myself ambiguously: I'm not talking about libvirt regressions (in their code base), but about changes in our code regressing libvirt. > If we don't force push, we have two solutions: > 1) Revert Oleksandr's series > 2) Leave it until we have Osstest fixed *and* Oleksandr's patch > reached libvirt. > > The former is not an option for me, because Oleksandr's series is not at > fault. So this leave us to 2). > > So what's your proposal? It's still 1), no matter that I agree that Oleksandr's series is not directly at fault. Jan
