From journalctl: dbus-daemon[2153]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.46' (uid=0 pid=3580 comm="/usr/bin/python3.12 /usr/bin/blueman-applet" label="kernel") dbus-daemon[2153]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service not found. dbus-daemon[3334]: [session uid=0 pid=3334 pidfd=5] Successfully activated service 'org.bluez.obex' dbus-daemon[2153]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.59' (uid=0 pid=4366 comm="/usr/lib64/libexec/kdeconnectd" label="kernel") dbus-daemon[2153]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service not found. I fixed it by creating a dbus-org.bluez.service symlink to /usr/lib/systemd/system/bluetooth.service. Versions of other packages: kde-misc/kdeconnect-23.08.5-r1 net-wireless/blueman-2.4.3 sys-apps/dbus-1.15.8 sys-apps/systemd-255.7-r1
You need to run "systemctl enable bluetooth.service". It will create that symlink for you.
(In reply to Mike Gilbert from comment #1) > You need to run "systemctl enable bluetooth.service". It will create that > symlink for you. That shouldn't need to be done.
That's a policy question which is far broader than just bluetooth.
(In reply to Sam James from comment #3) > That's a policy question which is far broader than just bluetooth. Same thing shouldn't have been done for https://bugs.gentoo.org/577842 then otherwise you're just making an excuse. Just say you don't want to fix it. It keeps the conversation simpler.
Please keep assumptions like that to yourself.
If the maintainer decides there is a good reason to enable this by default that's fine.
(In reply to Mike Gilbert from comment #6) > If the maintainer decides there is a good reason to enable this by default > that's fine. So what is it exactly? Is it policy when issues like this get rejected or is it up to the maintainer (or anyone who rejects this issue) but say it's policy when they don't want it applied? Seriously it can't be both because if the maintainers can override policy and they have the final say then the policy by simplification is meaningless. Just say you don't want to.
Policy isn’t written in stone. What are you so upset about?
In this case, I don’t think there is actually any formal policy written anywhere. However, the unwritten convention in Gentoo is not to enable system services by default. We generally don’t deviate from that without reason.
(In reply to Mike Gilbert from comment #9) > In this case, I don’t think there is actually any formal policy written > anywhere. However, the unwritten convention in Gentoo is not to enable > system services by default. We generally don’t deviate from that without > reason. Nothing is being enabled here though. You're just creating an alias.
obex.service is a user service that doesn't run with superuser privileges. That's pretty safe to enable by default. bluetooth.service runs as root and accesses hardware. This seems a bit less safe to enable by default. bluetooth.service is in fact disabled by default due to the missing alias. If upstream wanted to enable dbus activation unconditionally, they could have put SystemdService=bluetooth.service in the dbus service definition. bluetooth.service also has WantedBy=bluetooth.target in the [Install] section. This target is used by udev rules to start bluez when a bluetooth dongle is plugged in. If we choose to enable the alias by default for dbus activation, we should also consider enabling the bluetooth.target reverse dependency. It is also probably worth giving bluetooth-mesh.service the same treatment for consistency.
I am unsure about manually creating the symlink. Looking to other distributions, they also seem to be entirely relying on people enabling/disabling bluetooth.service for that
