** Description changed: [Impact] - * libvirt became FTBFS in xenial due to other changes. + * libvirt became FTBFS in xenial due to other changes. Most likely a + newer deboostrap that was used. - * The fix just modifies the self-tests (not the active code that runs - in an ubuntu users env) + * The fix just modifies the self-tests (not the active code that runs in + an ubuntu users env) - * The change is already active in Ubuntu in later releases via - https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3 + * The change is already active in Ubuntu in later releases via https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3 + https://salsa.debian.org/libvirt-team/libvirt/commit/7baa0daf + https://salsa.debian.org/libvirt-team/libvirt/commit/0ce5eb75 [Test Case] - * Build libvirt in Xenial on LP infra and while doing so do not trigger test fails in - test-openpty and test-posix_openpt + * Build libvirt in Xenial on LP infra and while doing so do not trigger + test fails in test-openpty and test-posix_openpt [Regression Potential] - * Since we only change self-test code that runs at build time the runtime should show now - regressions. The one thing I can think of is that a rebuild could always change something - (even a no change rebuild) but since we want to bundle it with other SRUs there would be a - rebuild anyway - hence I'd think this has no regression risk of its own. + * Since we only change self-test code that runs at build time the runtime + should show now + regressions. The one thing I can think of is that a rebuild could + always change something + (even a no change rebuild) but since we want to bundle it with other + SRUs there would be a + rebuild anyway - hence I'd think this has no regression risk of its + own. [Other Info] - - * This should not be fixed standalone but bundled with some other SRU to avoid useless rebuilds - - and even more so - users downloading updates for now gain. + + * This should not be fixed standalone but bundled with some other SRU to avoid useless rebuilds + - and even more so - users downloading updates for now gain. --- Due to a unknown other update libvirt became an FTBFS in Xenial. The issue shows up at build on launchpad infra and has two seld-tests broken. From the build log: FAIL: test-openpty ================== openpty returned -1 FAIL test-openpty (exit status: 1) FAIL: test-posix_openpt ======================= ../../../../gnulib/tests/test-posix_openpt.c:52: assertion '0 <= master' failed FAIL test-posix_openpt (exit status: 134) - - This is somewhat familiar to bug 1641615 but showing up again in Xenial now for yet unknown reasons. + This is somewhat familiar to bug 1641615 but showing up again in Xenial + now for yet unknown reasons. The later re-occurrence of this outside of Xenial was later on fixed by [1] for good. Probably now triggering by some SRu of a lib into Xenial (or unlikely some change in the builder setup). We want to add that to Xenial as well to have it build fine again. [1]: https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843674 Title: FTBFS of libvirt in Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1843674/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
