On 11/11/2023 18.33, Reinoud Zandijk wrote:
On Fri, Nov 10, 2023 at 10:12:38PM +0100, Reinoud Zandijk wrote:
On Thu, Nov 09, 2023 at 06:15:51PM +0100, Thomas Huth wrote:
On 09/11/2023 17.58, Daniel P. Berrangé wrote:
On Thu, Nov 09, 2023 at 04:35:56PM +0100, Philippe Mathieu-Daudé wrote:
...
You're right, Daniel. Seems like both, the Cirrus netbsd and the openbsd job
are currently broken and only output some help text instead of compiling
QEMU:

  https://gitlab.com/philmd/qemu/-/jobs/5497861511#L6834

... that's why the finish so fast.

IIRC last time I've seen them "working", they were running into the 80
minute timeout again.

So the netbsd and openbsd job are indeed not very useful anymore. I think we
should rather remove them and add a proper job via our own custom
KVM-capable runners instead.

Even though I am a co-maintainer of the NetBSD support for Qemu I am not quite
sure what testcase this is. Is this a regression test of installing NetBSD
from an ISO? That somehow times out? Where can I find the resulting console
output? Maybe the installer changed?

Re-reading the thread its about compiling Qemu on NetBSD. Doh. I am a novice
to the test kit you use so please forgive me if I don't make sense. Am I right
that it does install NetBSD OK, it then comes up and then tries to compile
Qemu on it but it fails due to some Python errors in the test script? Does it
use NetBSDs pkgsrc with its patches or has it its own method of dealing with
them?

No worries, the "make vm-build-netbsd" test itself is just working fine (after applying Philippe's fix from here: https://lore.kernel.org/qemu-devel/20231109150900.91186-1-phi...@linaro.org/ ).

This thread here is about the CI job that could run in the gitlab-CI... it's got a quite complicated setup - NetBSD is running as KVM guest on a runner on cirrus-ci.com, and that whole thing is triggered by a gitlab-CI job - so this setup is often broken and thus does not run by default in the CI. That's why I suggested to remove the job and replace it by a job that directly runs in a KVM-capable runner on the gitlab-CI instead of taking the detour via cirrus-ci.com.

 Thomas




Reply via email to