FS#77681 - [bluez] Launch obexd directly instead of through a systemd service (Failed to start org.bluez.obex)
Attached to Project:
Arch Linux
Opened by hurricane pootis (HurricanePootis) - Wednesday, 01 March 2023, 00:02 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:18 GMT
Opened by hurricane pootis (HurricanePootis) - Wednesday, 01 March 2023, 00:02 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:18 GMT
|
Details
Description: Change bluez's obex dbus service to launch dbus
directly instead of relying on a systemd service
Additional info: https://bugs.kde.org/show_bug.cgi?id=464929 As of recently, at least since KDE 5.26, KDE has been unable to launch obexd through dbus. In the bug linked above, in both kde 5.26 and at least kde 5.27.2, KDE has been unable to launch obexd through dbus, and after a lot of testing of different configuration, the only thing that made obexd work on my system was having the dbus service launch it directly. Yes, I did try `systemctl --user enable obex`, and `# systemctl --global enable obex`, and `systemctl --user start obex`, and it never worked. For whatever reason, whenever dbus goes to start the org.bluez.obex.service, it exits with a status 1 (according to the dolphin output). That's why, I am creating this bug report so this patch can be introduced. I will try to test it out on GNOME later, whenever I get the chance, and I openly invite everyone who sees this to give it a whirl on their system. I'd hate for my fix to cause a lot of grief for other people. I have attached a patch file for the PKGBUILD itself, and a patch file for the service. Also, the reason why I am not going to bother submitting this patch upstream to bluez is that I don't know how likely it is that they will take this, nor do I have a git email setup. Steps to reproduce: 1) Install KDE, bluez, and bluedevil 2) Connect phone through bluetooth to the computer 3) Attempt to send a file through dolphin 4) See the following error: 'Failed to start org.bluez.obex.service: Process org.bluez.obex exite' Additional Thoughts: If y'all think its best that this patch also be sent upstream to bluez themselves, I would be down. But, I don't think those professional developers would appreciate a change like this coming from an "end-user" ðŸ˜. 
  bluez-patches.tar.xz
(0.9 KiB)
|
This task depends upon
Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:18 GMT
Reason for closing: Â Moved
Additional comments about closing: Â https://gitlab.archlinux.org/archlinux/p ackaging/packages/bluez/issues/1
Saturday, 25 November 2023, 20:18 GMT
Reason for closing: Â Moved
Additional comments about closing: Â https://gitlab.archlinux.org/archlinux/p ackaging/packages/bluez/issues/1
I just booted up a Fedora ISO, and two things happened. First, instead of system linking `/usr/lib/systemd/user/obex.service` to `/usr/lib/systemd/user/dbus-org.bluez.obex.service`, they instead just went ahead and basically enabled it globally with linking the systemd service to `/etc/systemd/user/dbus-org.bluez.obex.service`
Furthermore, obex actually worked, and didn't give a Exited with status 1. I am beginning to think this is an Arch issue, and I would like to see more people test this out. Could you possibly take the time to see if obex crashes. First, do, `# systemctl --global enable obex.service`, then try sending a file through Dolphin or your choice of file manager. After I post this message, I am going to test out GNOME and see if the issue exist there.
https://sources.debian.org/patches/bluez/5.66-1/allow-using-obexd-without-systemd-in-the-user-sessio.patch/
Maybe this is what we can apply to make KDE working. Can you try it?