Bug#1137353: qemu dropped support for 32bit hosts but gnome-boxes depends on it

[Simon McVittie]

On Sat, 23 May 2026 at 19:18:19 +0300, Michael Tokarev wrote:
>That's already the case.  qemu-system-common is only built if any
>of qemu-system-$arch is built.  But I don't think it will help much.
>Because while 32bit systems was a major difference, there's no other
>similar changes expected.  So far we assume qemu-system is available
>on all 64bit architectures.

I thought qemu needs explicit porting for every new architecture? Or is 
that only necessary for KVM and new emulated architectures, with every 
new 64-bit architecture (let's say wtf64) immediately being able to 
emulate existing architectures (for example qemu-system-x86:wtf64) 
without writing new code?

At the moment, qemu seems to hard-code an allowlist of architectures:

     Package: qemu-system-common
     Architecture: amd64 arm64 loong64 mips64 mips64el ppc64 ppc64el riscv64 s390x sparc64

so next time we gain a new 64-bit architecture (let's say wtf64), no new 
qemu-system* packages will be built for it until the qemu maintainers 
add wtf64 to that list and similar ones. I don't think we want 
gnome-boxes:wtf64 to get built but not be installable: that would be a 
RC bug.

If your intention is that qemu will be built on every 64-bit 
architecture, then you could consider using

     Source: qemu
     Build-Depends: ..., architecture-is-64-bit, ...

     Package: qemu-system-x86  # etc.
     Architecture: any         # or maybe linux-any

although that would only work after removing the 32-bit builds of 
qemu-utils.

>BTW, (*-)Depends: qemu-system-common is a tough one.  The prob here
>is that qemu-system-common itself depends on one of qemu-system-foo
>packages, - due to old request from ubuntu.  I think I now got rid
>of this dependency, but it was there for quite some time.

For the version currently in unstable, which is the only one that 
matters for new unstable packages, that dependency is no longer there.

>>After uploading a version of gnome-boxes that doesn't build on armhf 
>>and i386, we'll need to ask the archive team to remove the old 
>>gnome- boxes:i386 and gnome-boxes:armhf binaries, and a similar 
>>request will be necessary to remove qemu*:i386 and qemu*:armhf 
>>packages that are no longer built, and probably similar for libvirt 
>>and libvirt-dbus. And then, after all that cleanup, qemu will 
>>finally be able to migrate.
>
>I guess it's just tip of an iceberg.  There are much more packages
>involved.  I'm filing more bugs like this one, for inter-inter-deps..

Looking at https://qa.debian.org/excuses.php?package=libvirt and 
https://qa.debian.org/excuses.php?package=qemu I think it's only:

- qemu itself
- qemubuilder
- libvirt
- libvirt-dbus
- gnome-boxes

cockpit-machines depends on libvirt-dbus, but is Architecture: all, and 
the testing machinery allows Arch: all packages to become uninstallable 
on architectures that are not amd64 or arm64, so that's OK.

`dak rm -R -n -b gnome-boxes gnome-devel libvirt-dbus cockpit-machines 
qemubuilder` on coccia doesn't complain about any other rdeps.

     smcv