postrm fails in hirsute as the path generation for modules is broken

Example from Focal (how it should be):
 26 rm -f /var/run/qemu/Debian_1_5.0-5ubuntu9~backport20.04-202010241037~ubuntu20.04.1/ui-gtk.so
 27 rm -f /var/run/qemu/Debian_1_5.0-5ubuntu9~backport20.04-202010241037~ubuntu20.04.1/audio-*.so

This is generated from debversion in d/rules and probably changed a character that was changing on the last merge.

Until resolved affected users can rather safely run
  rm -rf /var/run/qemu/Debian

Afterwards the remove/purge will work.

prerm (and others) have the same issue:
        mkdir -p /var/run/qemu/Debian 1:5.1+dfsg-4ubuntu1
        cp /usr/lib/x86_64-linux-gnu/qemu/block-*.so /var/run/qemu/Debian 1:5.1+dfsg-4ubuntu1/

Due to the above it also might leave dirs like "1:5.1+dfsg-4ubuntu1" wherever it was running - bump severity

The string in --version is the same:
 QEMU emulator version 5.1.0 (Debian 1:5.1+dfsg-4ubuntu1)
 QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1)

Templates as well:
    mkdir -p /var/run/qemu/@PKGVERSION@
    cp /usr/lib/@ARCH@/qemu/block-*.so /var/run/qemu/@PKGVERSION@/

d/rules:
Focal:
 PKGVERSION := $(shell printf "Debian ${DEB_VERSION}" | tr --complement '[:alnum:]+-.~' '_')
Groovy:
 PKGVERSION := $(shell printf "Debian ${DEB_VERSION}" | tr --complement '[:alnum:]+-.~' '_')
Hirsute:
 PKGVERSION := $(shell printf "Debian ${DEB_VERSION}" | tr --complement '[:alnum:]+-.~' '_')

The same ... but Debian picked up the variable name and changed it later in d/rules
We have used PKGVERSION, Debian has changed it (nor later in d/rules and different format)
  PKGVERSION = Debian ${DEB_VERSION}
  SAVEMODDIR = /run/qemu/$(shell echo -n "${PKGVERSION}" | tr --complement '[:alnum:]+-.~' '_')

But to replace the maintainer scripts it used PKGVERSION which is before the tr and that has fixed special chars.

df9ba08d6cdb50bd66792db2b02a31e1fc8befef has also added

+# save block-extra loadable modules on upgrades
+# other module types for now (5.0) can't be loaded at runtime, only at startup
+ echo 'case $$1 in (upgrade|deconfigure) mkdir -p ${SAVEMODDIR}; cp -p ${libdir}/qemu/block-*.so ${SAVEMODDIR}/;; esac' \
+ >> debian/qemu-block-extra.prerm.debhelper
+ echo 'case $$1 in (purge|remove) rm -f ${SAVEMODDIR}/block-*.so;; esac' \
+ >> debian/qemu-block-extra.postrm.debhelper

We still have:
 25 AUTOGENERATED:= qemu-block-extra.prerm qemu-block-extra.postrm qemu-system-gui.prerm qemu-system-gui.postrm
133 »···for f in ${AUTOGENERATED} ; do \
134 sed -e 's%@ARCH@%${DEB_HOST_MULTIARCH}%g' \
135 »··· -e 's%@PKGVERSION@%${PKGVERSION}%g' \
136 »···»···»···< debian/$$f.in > debian/$$f ; \
137 done

Those two conflict
Problem is in d210c63c576 which we just don't need anymore.

Yet this unintentionally dropped DEB_HOST_MULTIARCH but that is recovered by ${libdir}

Fixed in PPA [1] for testing

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4348

Hi Christian,

At least one qemu guest is needed to reproduce the issue, correct? As I couldn't with a simple install/uninstall.

Hi Paride,
This is tied into upgrade mechanisms (as that is what it needs to fix, long running qemu's through an upgrade)
It needs an upgrade to happen to enter the bad state:
That upgrade doesn't have to be another version

For example:
$ apt install qemu-block-extra
$ apt install --reinstall qemu-block-extra

Triggers the bug in a fresh container.

That very same test now works fine with the fix in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4348

The maintainer scrips look less normal/formal (no more based ont he usual skeleton), but they work - use the .debhelper suffix that seems to be established and align with how Debian does it.

Fix can be uploaded, I'm just waiting for a few other bugs we have open to decide if I do one or many uploads (test and build queue is full enough).

Hmm, the other one takes at least a few day - maybe more due to other involved people being out for thanksgiving. Prepping this for a review.

MP here: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/394453

Thanks for the additional info!

I tried to reproduce this with piuparts, as it performs an install-upgrade-purge test by installing the package from the archive, upgrading it using the package to test, and then trying to remove it. It doesn't reproduce as apt-get detects the installed package has the same version of the proposed package, but it should have caught this at merge time.

This bug was fixed in the package qemu - 1:5.1+dfsg-4ubuntu2

---------------
qemu (1:5.1+dfsg-4ubuntu2) hirsute; urgency=medium

  * Fix upgrade module handling (LP: #1905377)
    This was accetped in a slightly different form in qemu_5.0-6 and therefore
    allows to drop some former delta that is now conflicting.
    Ubuntu still keeps enabling --enable-module-upgrades, but only for
    qemu-xen which doesn't exist in Debian
    - Drop d/qemu-block-extra.*.in, d/qemu-system-gui.*.in
    - d/rules: Drop generating package version into maintainer scripts

 -- Christian Ehrhardt <email address hidden> Tue, 24 Nov 2020 11:16:01 +0100

FYI - While the fix for this bug worked fine on qemu-block-extra (which is the only place module upgrade handling will be done in future). The dropping of any prerm for qemu-syste-gui has triggered bug 1906245.
That essentially surfaces as the same issue, but for qemu-syste-gui by the broken old prerm script. Bug 1906245 will fix that with another upload.

Due to 1:5.1+dfsg-4ubuntu2 being released on Friday plenty of people will run into this :-/
This FYI shall help to identify 1906245 quickly and once there resolved will get your updates going again.