On Wed, Oct 14, 2026 at 02:56:46PM -0300, Fabiano Rosas wrote: > Daniel P. Berrangé <[email protected]> writes: > > > On Mon, Sep 14, 2026 at 08:58:09PM -0300, Fabiano Rosas wrote: > >> Hi, I just wanted to share and ask for feedback on some container images > >> I've been building as part of my testing of migration pull-requests. > >> > >> From a Dockerfile from ./tests/docker/dockerfiles/ I'm producing the > >> following: > >> > >> $ docker images > >> qemu-build-base:11.0.0 b6efa198e93a 5.8GB > >> qemu-rootfs-base:11.0.0 72bcb5418f4d 4.08GB > >> qemu:11.0.0 018a3f0f4dcc 2GB > > > > snip > > > >> 2) Neither the QEMU build nor the distro repos are reliable enough to > >> allow me to just "go back in time" and rebuild at any moment, I need to > >> keep the artifacts cached to avoid rebuilding. Otherwise it comes time > >> to send a PR and I discover that some python piece has changed or the > >> distro messed up the older repository. > > > > Yes, in general building old QEMU on new distros periodically > > hits trouble. If building old QEMU, better reliability is > > achieved by using a distro release that was from the same > > timeframe as QEMU. Is using containers targetting such old > > distro versions not an option ? The tests/docker/dockerfiles > > from the old QEMU branch ought to work ? > > > > Yes, I'm doing just that. Some tweaks are needed still. For instance, my > script has something like this: > > dockerfile="tests/docker/dockerfiles/opensuse-leap.docker" > > sed -i 's/ncurses-devel//' $dockerfile > > if [ "$tag" = "10.1.0" ]; then > sed -i 's/libLLVM19//' $dockerfile > fi
If that's needed, shouldn't we patch the QEMU stable branch ? I would have thought that would be a problem for doing releases on stable if the containers have bugs ? > > How far back in time do you need/want to go for migration > > testing ? Is it sufficient to merely target versions for > > which mjt is still doing active maint work, so we can > > expect the containers to still work. > > > > I'm currently testing against the previous 3 releases. I think 2 > releases is probably enough. I guess if we test X -> Y and then later test Y -> Z, then we have transitively validated X -> Z. So in theory only 1 historical release is enough, but it makes sense to test one or two more variants just in case. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
