libivrt: Please revert policykit-1 changes

[Jeremy Bícha]

Debian Testing has a new version of policykit-1 that enables JavaScript rules instead of the legacy pkla syntax. The new version has not been accepted into Ubuntu main yet. (It is currently in lunar-proposed but I do not expect it to make it into Ubuntu 23.04.)

Therefore, please revert this commit copied from Debian, as recommended in the commit message.

https://salsa.debian.org/libvirt-team/libvirt/-/commit/b9b2923

Until this change is made, libvirt will be stuck in lunar-proposed because it has an unsatisfiable dependency in the release pocket of lunar.

[Christian Ehrhardt  (paelzer)]

I was waiting if policykit-1 would move to main in time, but you are right I can unblock this by doing that now.
We can still rebuild later if it happens to land.

I have another change pending that similarly resolves not yet finalized features for now to complete things for Lunar.

[Christian Ehrhardt  (paelzer)]

Well, when looking at it in detail it isn't that trivial.

On one hand I'll rebase to 9.0.0-2 as [2] is the other thing I want and the stabilization is good as well.

But we already have the suggested change [1] since it was part of the merge of 9.0.0-2.
To get rid of the policykit-1 dependency we will need more.
You'll see that [3] has no direct dependency to policykit-1.
Instead it has:
  Package: libvirt-daemon-system
  ...
  polkitd (>= 121+compat0.1-2) [linux-any],

This is what causes the locked migration right now, as only the on in proposed is providing that:

 polkitd | 0.105-33 | lunar | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 polkitd | 122-3 | lunar-proposed | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

The latter is the version that is stuck due to the duktape MIR processsing in bug 1997417 for now.

Just as we assumed when landing this in Debian (the later assumption was that the new polkit will make it in time eventually, but per your request we give up on that for now) we have to revert [4].

[1]: https://salsa.debian.org/libvirt-team/libvirt/-/commit/b9b2923
[2]: https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/177
[3]: https://launchpadlibrarian.net/650583774/buildlog_ubuntu-lunar-amd64.libvirt_9.0.0-1ubuntu1_BUILDING.txt.gz
[4]: https://salsa.debian.org/libvirt-team/libvirt/-/commit/c62b8b2

[Christian Ehrhardt  (paelzer)]

Uploaded

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 9.0.0-2ubuntu1

---------------
libvirt (9.0.0-2ubuntu1) lunar; urgency=medium

  * Merge 9.0.0-2 from Debian unstable (LP: #1993412)
    Also resolved the ask for a rebuild against recent libxen (LP: #2004163)
    Remaining changes:
    - libvirt-uri.sh, d/rules: Automatically switch default libvirt URI
      for users via user profile (xen URI on dom0, qemu:///system otherwise)
    - Disable libssh2 support (universe dependency)
    - d/control: add libzfslinux-dev to build-deps
    - d/control: drop libvirt-lxc, vbox and xen drivers to suggest
    - debian/patches/ubuntu/ovmf_paths.patch: adjust paths to secboot.fd UEFI
      Secure Boot enabled variants of the OVMF firmware and variable store for
      the paths where we ship these files in Ubuntu.
    - 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 a long time.
      + 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.
    - Update README.Debian with Ubuntu changes
    - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx
    - fix autopkgtests (LP 1899180)
      + d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making
        vmlinuz available and accessible (Debian bug 848314)
      + d/t/control: fix smoke-qemu-session by ensuring the service will run
        installing libvirt-daemon-system
      + d/t/smoke-lxc: fix smoke-lxc by ignoring potential issues on destroy as
        long as the following undefine succeeds
      + d/t/smoke-lxc: use systemd instead of sysV to restart the service
      + d/t/control, d/t/smoke-lxc: retry service restart and skip test if
        failing; This was flaky on some release/architectures
      + d/t/smoke-lxc: retry check_domain being flaky on arm64
    - dnsmasq related enhancements
      + run dnsmasq as libvirt-dnsmasq (LP: 1743718)
      + d/libvirt-daemon-system.postinst: add libvirt-dnsmasq user and group
      + d/libvirt-daemon-system.postrm: remove libvirt-dnsmasq user and group
        on purge
      + d/p/ubuntu/dnsmasq-as-priv-user: write dnsmasq config with user
        libvirt-dnsmasq and adapt the self tests to expect that config
      + d/libvirt-daemon-system.postinst: fix old libvirt-dnsmasq users group
      + Add dnsmasq configuration to work with system wide dnsmasq-base
    - d/p/ubuntu/set-default-machine-to-ubuntu.patch: to select default
      machine type correctly with newer qemu/libvirt
    - d/p/ubuntu/lp-1861125-ubuntu-models: recognize Ubuntu models for
      (LP 1861125) fixups
    - d/p/ubuntu/wait-for-qemu-kvm.patch - avoid hangs ...