Source: ipxe Version: 1.21.1+git20250317.42a29d56+dfsg-1 Severity: normal X-Debbugs-Cc: [email protected]
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
