usrmerge changes path of iptables - please update libvirt on a merge of 1.8.1-x (also affects backports to undo that path change)

For further awareness I added a UCA task as back in Bionic the paths are again different.
There also ebtables (which means all three binaries) are in /sbin/

That means on backports to Bionic this path needs to be adapted to match.

Hmm things seem to have raced in my build envs and containers.
Fortunately Eoan is already completed

# which ebtables iptables ip6tables
/usr/sbin/ebtables
/usr/sbin/iptables
/usr/sbin/ip6tables

Ok then I can make libvirt to use these now, but this is still important to know for backports to Bionic.

Hmm interesting ...

/usr/sbin/ebtables is managed by update alternatives.
But iptables continues to surprise.

In an sbuild build env of Eoan I get:
# which ebtables iptables ip6tables
/usr/sbin/ebtables
/sbin/iptables
/sbin/ip6tables

While in an Eoan container I have:
# which ebtables iptables ip6tables
/usr/sbin/ebtables
/usr/sbin/iptables
/usr/sbin/ip6tables

Let me recycle the container as it might have some old crap.
No it stays the same...

Both are on 2.0.10.4+snapshot20181205-1ubuntu1 / 1.6.1-2ubuntu3.

To make that three a Eoan VM as of today has the same as the container.

All of them (sbuild+lxd+vm) have the non usr path in the package itself.
dpkg -L iptables | grep 'bin\/iptables$'
/sbin/iptables

And the /usr/sbin path that exists in the container
Hmm, something in the container and the VM brings that /usr/sbin mapping to work which fails in the build environment, maybe because it is "just" a chroot?

/var/lib/dpkg/info/iptables.* has no further magic maintscripts that would explain.

For now in libvirt lets set the real paths as carried by iptables packages.
This will keep us on the safe side.

But that also means we are back at my initial assumption that on an iptables 1.8.1 merge one might want to remove that (unless /sbin/iptables is kept as compat, then I can clear it next cycle).

This bug was fixed in the package libvirt - 5.4.0-0ubuntu1

---------------
libvirt (5.4.0-0ubuntu1) eoan; urgency=medium

  * Merged with Debian git 5.3.0-1~1.gbp7b1637 and upstreams 5.4 release
    Among many other new features and fixes this includes fixes for:
    LP: #1759509 - virsh dompmwakeup fails to wake VM from dompmsuspend state
    Remaining changes:
    - Disable libssh2 support (universe dependency)
    - Disable firewalld support (universe dependency)
    - Set qemu-group to kvm (for compat with older ubuntu)
    - Additional apport package-hook
    - Autostart default bridged network (As upstream does, but not Debian).
      In addition to just enabling it our solution provides:
      + do not autostart if subnet is already taken (e.g. in guests).
      + iterate some alternative subnets before giving up
    - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is
      the group based access to libvirt functions as it was used in Ubuntu
      for quite long.
      + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests
        due to the group access change.
      + d/libvirt-daemon-system.postinst: add users in sudo to the libvirt
        group.
    - ubuntu/parallel-shutdown.patch: set parallel shutdown by default.
    - Update Vcs-Git and Vcs-Browser fields to point to launchpad
    - Xen related
      - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The
        section that adapts the path of the emulator to the Debian/Ubuntu
        packaging is kept.
      - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto
        set VRAM to minimum requirements
      - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts
      - Add libxl log directory
      - libvirt-uri.sh: Automatically switch default libvirt URI for users on
        Xen dom0 via user profile (was missing on changelogs before)
    - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from
      included_files to avoid build failures due to duplicate definitions.
    - Update README.Debian with Ubuntu changes
    - Enable some additional features on ppc64el and s390x (for arch parity)
      + systemtap, zfs, numa and numad on s390x.
      + systemtap on ppc64el.
    - d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making
      vmlinuz available and accessible (Debian bug 848314)
    - d/t/control, d/t/smoke-lxc: fix up lxc smoke test isolation
    - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx
    - Further upstreamed apparmor Delta, especially any new one
      Our former delta is split into logical pieces and is either Ubuntu only
      or is part of a continuous upstreaming effort.
      Listing related remaining changes in debian/patches/ubuntu-aa/:
      + 0001-apparmor-Allow-pygrub-to-run-on-Debian-Ubuntu.patch: apparmor:
        Allow pygrub to run on Debian/Ubuntu
      + 0003-apparmor-libvirt-qemu-Allow-read-access-to-overcommi.patch:
        apparmor, libvirt-qemu: Allow read access to overcommit_memory
      + 0007-apparmor-libvirt-qemu-Allow-owner-read-access-to-PRO.patch:
        apparmor, libvirt-qemu: Allow owner read acc...

First of all I beg your pardon, I'm sure there was a similar discussion recently but I only find this bug which is older. I think it was something paride found, so maybe it was on IRC?

Well I tried to proactively let you know via this bug months before anyway :-)

Well wherever that other recent discussion was I was made aware that people are affected
o/ gpiccoli

You (UCA) really have to fix this on backporting, just change the path override in d/rules.

For people affected the workaround for now is:
$ sudo ln -s /sbin/iptables /usr/sbin/iptables
$ sudo ln -s /sbin/ebtables /usr/sbin/ebtables
If you do that after libvirt is already installed do:
$ sudo systemctl restart libvirtd

The latter (or the install) will then auto-start the network as intended.

FYI - brought up again in bug 1853013
There it now is finally addressed it seems.

I'm marking this Fix Release as the bug is resolved in the duplicate that paelzer noticed