| 2019-09-12 06:45:05 |
Christian Ehrhardt |
description |
[Impact]
* libvirt became FTBFS in xenial due to other changes.
* 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
[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
[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.
[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.
---
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.
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 |
[Impact]
* 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 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
[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.
[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.
---
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.
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 |
|
