Valentin David

> +1 on merge but perhaps -1 on merge for 2.63 unless we absolutely have to. We are waiting on releases from bases anyway, so we should not merge it...

Ah! Nobody saw it. Oops. But I was building glibc unpatched. I have just fixed it.

> We can make that service a no-op on systems without apparmor, we could handle that internally in snapd-apparmor The service already has `ConditionSecurity=apparmor`.

> It doesn't really matter if something is an app or service in the sense that if we get things right for services, it works for apps as well. Do...

> it's still not clear to me: why are you renaming the `name="org.freedesktop.PolicyKit1" match on the D-Bus rules? Here is the commit message for it: udisks2 which uses the C...

There is two ways to address in d-bus, unique connection name or well-known name. See https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus Forcing a name in the apparmor rule forces to use a well-known name. Udisks2...

@alexmurray, In [gdbusproxy.c](https://gitlab.gnome.org/GNOME/glib/-/blob/87b4771d1f4f1cf110b43c1eaa136fa069c0c270/gio/gdbusproxy.c), `g_dbus_proxy_call_internal`seems to use `get_destination_for_call` which uses `proxy->priv->name_owner` which should be the should be the result of `org.freedesktop.DBus.GetNameOwner` which according to the [specifications](https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-name-owner) should be the unique name....

@alexmurray @mvo5 I cannot build the snap of snapd locally anymore since this PR. Was something changed in the way to build the snap? I have tried using snapcraft 4.x...

Opened #12348 to fix it.

The changes required in snapd: https://github.com/snapcore/snapd/pull/11038