Mako fails to connect to DBus and present Freedesktop notification service

[Michał J. Gajda]

I installed `mako` in hope it would play nicely with `sway`, but it seems that it is not performing its function on install:

1. Attempting to start `mako-notifier` as a user gives error message `Failed to acquire service name`. Probably because it is meant to be activated by `dbus`.
2. Sending a notification request by `gdbus` results in starting of `plasma-waitforname` executable instead and a hang.
3. Attempting to call `makoctl list` hangs, shows nothing.
4. Programs that attempt to call default FreeDesktop notification service hang. For example: `notify-send`, `keybase`.

This is the script I use to invoke default FreeDesktop notification service

```
gdbus call --session \
    --dest=org.freedesktop.Notifications \
    --object-path=/org/freedesktop/Notifications \
    --method=org.freedesktop.Notifications.Notify \
    "" 0 "" 'Hello world!' 'This is an example notification.' \
    '[]' '{"urgency": <1>}' 5000
```

These problems occur when using `sway` under `gdm`.
Ubuntu version 22.04.1 (jammy).

`mako-notifier` version 1.6-2

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: mako-notifier 1.6-2
ProcVersionSignature: Ubuntu 5.15.0-50.56-lowlatency 5.15.60
Uname: Linux 5.15.0-50-lowlatency x86_64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: pass
Date: Thu Oct 13 15:22:55 2022
InstallationDate: Installed on 2022-09-05 (38 days ago)
InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1)
SourcePackage: mako-notifier
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Cameron Ackerman (camja014)]

I believe I'm running into this issue as well. I am also running jammy/sway/gdm3.

Running `mako` gives the same "Failed to acquire service name: Permission denied" error.

Looking at `journalctl` logs, I see this line from AppArmor after attempting to start `mako`:

```
Nov 15 10:34:21 redacted dbus-daemon[2842]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="RequestName" mask="send" name="org.freedesktop.DBus" pid=22293 label="fr.emersion.Mako" peer_label="unconfined"
```

Adding the workaround from the following comment on GitHub, to /etc/apparmor.d/fr.emersion.Mako, resolves the issue for me:

https://github.com/emersion/mako/issues/257#issuecomment-1049087860

It seems the AppArmor profile is missing some permissions.

[Örjan Fors (orrriot)]

Version 1.7.1 has dropped AppArmor support.
https://github.com/emersion/mako/commit/0d95a1653616454e894f27edc329a9f3a7f96dc2

I still ran into this problem. Looks like the `/etc/apparmor.d/fr.emersion.Mako` file was still lingering there.

Worked fine after I ran this:
```
apt purge mako-notifier && apt install mako-notifier
```