Source: ipxe
Version: 1.21.1+git20250317.42a29d56+dfsg-1
Severity: normal
X-Debbugs-Cc:
pkg-qemu-devel@lists.alioth.debian.org
Hi!
Starting with version 10.0, upstream qemu dropped support for
64bit targets on 32bit hosts. This means that, for example,
there's no qemu-system-x86_64 or qemu-system-loongarch64 on i386
or armel. This makes the testsuite (debian/tests/) to fail on
all 32bit architectures. If host architecture is 32bit, we can
not test 64bit qemu targets anymore.
How to achieve this is a good question though. The problem is
that it should be done before trixie freeze, since I'm targetting
qemu 10.0 for trixie due to various reasons. However, the timing
with releases and the freeze is a bit unfortunate, - I uploaded
qemu 10.0.0-rc1 to unstable just yesterday.
At the very least, on i386 you have to run qemu-system-i386, not qemu-system-x86_64.
Looking at the current d/tests/control in ipxe, I see the deps
for qemu are all wrong. For quite some time already, qemu
provides debian naming virtual packages for each qemu-system-foo
executable this package ships. For example, if you use
qemu-system-loong64 in your tests (this is a debian arch name,
not qemu arch name), you should depend on qemu-system-loong64,
and run qemu-system-loong64. No matter which actual package
provides this binary, it will be installed. The same is true
for upstream qemu architecture naming (loongarch64 in this case),
if you prefer that. In particular, please don't use
Depends: qemu-system-loongarch | qemu-system-misc
Instead, please do use:
Depends: qemu-system-loong64
since this is the binary you want to run. In d/tests/qemu-cmd,
you can use qemu-system-$arch in all cases (but with different
args), though this is definitely not mandatory.
Thanks,
/mjt
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)