On 16/08/2021 13.11, Daniel P. Berrangé wrote:
On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
On 210816 1001, Peter Maydell wrote:
On Sat, 14 Aug 2021 at 07:10, Thomas Huth <th...@redhat.com> wrote:
Hi Peter,
in case we're going to have an -rc4, here's a pull request that contains
the fixes for getting the gitlab-CI green again. I also added some doc
updates since they should be completely riskless. But if we won't have an
rc4 due to other reasons, this pull request here certainly also does not
justify another RC, so please ignore this PR in that case.
The following changes since commit 703e8cd6189cf699c8d5c094bc68b5f3afa6ad71:
Update version for v6.1.0-rc3 release (2021-08-10 19:08:09 +0100)
are available in the Git repository at:
https://gitlab.com/thuth/qemu.git tags/pull-request-2021-08-11
for you to fetch changes up to 36b508993c4dcc6b3ef4b5c00e293ee9560926ee:
docs/about/removed-features: Document removed machines from older QEMU
versions (2021-08-11 15:39:09 +0200)
CI run can be seen here:
https://gitlab.com/thuth/qemu/-/pipelines/351602605
----------------------------------------------------------------
* Fixes for the gitlab-CI (fix the hanging build-oss-fuzz pipeline)
* Add documentation about features that have been removed in older versions
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/6.1
for any user-visible changes.
https://gitlab.com/qemu-project/qemu/-/jobs/1505950978
Looks like build-oss-fuzz is still timing out, even without the issue
in the vhost-usr-blk test.
It worked fine in the staging branch, finished within 40 minutes:
https://gitlab.com/qemu-project/qemu/-/jobs/1504868929
At this point the job should essentially just
build + test qemu-system-i386 with some extra time spent on linking
the fuzzer and briefly running through all the fuzzer configs. Maybe the
only way to make this work is to split the job into a build + test
stage?
At this point I think we should just disable the job in gitlab entirely.
We've spent too long debugging this, while leaving CI red for everyone.
I don't think so. That seems to be a new, unrelated problem:
Running test qtest-i386/usb-hcd-ehci-test
socket_accept failed: Resource temporarily unavailable
**
ERROR:../tests/qtest/libqtest.c:319:qtest_init_without_qmp_handshake: assertion failed: (s->fd
>= 0 && s->qmp_fd >= 0)
ERROR qtest-i386/usb-hcd-ehci-test - Bail out!
ERROR:../tests/qtest/libqtest.c:319:qtest_init_without_qmp_handshake: assertion failed: (s->fd
>= 0 && s->qmp_fd >= 0)
That "socket_accept failed: Resource temporarily unavailable" sounds like
the build machine was maybe temporarily overloaded?
Question is why the test framework was running into a timeout afterwards
here instead of bailing out immediately?
Thomas
