On 08/05/2025 18.08, Paolo Bonzini wrote:
On 5/8/25 16:26, Stefan Hajnoczi wrote:
On Tue, May 6, 2025 at 11:30 AM Paolo Bonzini <pbonz...@redhat.com> wrote:
The following changes since commit a9e0c9c0f14e19d23443ac24c8080b4708d2eab8:
Merge tag 'pull-9p-20250505' of https://github.com/cschoenebeck/qemu
into staging (2025-05-05 11:26:59 -0400)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstream
for you to fetch changes up to e6b9b79c3076777b791f72ebdbc9d37ad8005fe9:
gitlab: Enable CI for wasm build (2025-05-06 16:02:04 +0200)
----------------------------------------------------------------
* ci: enable RISC-V cross jobs
* rust: bump minimum supported version to 1.77
* rust: enable uninlined_format_args lint
* initial Emscripten support
* small fixes
I'm not sure why, but the following CI failure seems to be caused by
this pull request:
https://gitlab.com/qemu-project/qemu/-/jobs/9974291215#L4684
Please take a look, thanks!
It is a transient failure; it reproduces 30% of the time with
meson test --repeat 100 func-hppa-hppa_seabios
Please not that you should use -j1 when using --repeat ... otherwise the
same test will run in parallel multiple times and the instances might
destroy the output files of other tests while running.
... maybe we should put each test output in directory with a randomized name
if we want to support that way of running the same test in parallel...
even without the pull request (commit
a9e0c9c0f14e19d23443ac24c8080b4708d2eab8).
Before finding this I had already sent the first half (which should be safe
since it's all Rust code that isn't compiled on that runner---and for hppa
targets in general), but if you still have the merge commit perhaps you can
push it?
Looking at the log and tests/functional/test_hppa_seabios.py, it seems like
this test just fires up the hppa BIOS, checks for some strings and that's
it. However, it seems like qemu-system-hppa quits completely if the BIOS
cannot boot from any device - so it's likely a race: QEMU quits too fast,
while the test still tries to talk to it to shut down QEMU gracefully?
If I'm right this could likely be fixed by simply adding "-no-shutdown" to
the QEMU options here...?
Thomas
