On 29.05.2026 09:23, Martin Pitt wrote:
And for arch-all package, things are different. In particular, you
don't adjust the package when arch-specific dependencies changes.
Instead, it is the autopkgtest system which just omits testing this
package once the dependencies disappears on some architectures.
So you are saying it didn't actually block anything? Indeed I couldn't find a
blocker.
Yes it didn't. Things here are a bit shady though, hence my confusion.
When I looked at the tracker.d.o pages, it's been said there that
"updating libvirt package will make cockpit-machines:i386 uninstallable"
(or something close to that, I don't remember the exact wording). So I
assumed cockpit-machines is arch:any and with dependency on libvirt.
However, this was due to a cruft left in testing still, - the migration-
blockers scripts see that cruft (libvirt:i386, qemu:i386) and decides
the new packages wont work.
Now, cruft has been removed, libvirt is clean, and nothing is blocking
its migration anymore.
Please excuse me for all this noise and for your attention. I filed
this bug report entirely by mistake.
No worries! If anything, it at least helped to spot that libvirt packaging
bug, i.e. the daemon should continue to be available on all arches, just not
depend on -qemu on 32 bit.
Closing this bug now.
It raced with my upload.
Please don't rush anything here. Your package is fine.
OK! I'll revert the architecture change.
Yes, thank you very much! I didn't want you to do any of that,
obviously :)
/mjt
