Bug 190960 - bluez-pin D-Bus service not automatically started for X sessions
Summary: bluez-pin D-Bus service not automatically started for X sessions
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez-pin (Show other bugs)
(Show other bugs)
Version: 5
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: David Woodhouse
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-07 13:00 UTC by Roland Wolters
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-10 09:53:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Roland Wolters 2006-05-07 13:00:24 UTC
Description of problem:
When I try to send files to my mobile bluetooth phone with either the obex 
object push client or with obex file transfer (both provided by bde-bluetooth 
which is not part of Fedora Core yet) it does not work, and I see an error 
in /var/log/messages:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez.PinAgent was not 
provided by any .service files

When I change the pin helper in /etc/bluetooth/hcid.conf from 
"dbus_pin_helper" to "/usr/bin/bluepin" everything works fine: I get a pop up 
asking for the pin and after entering this the data transfer is running as it 
should.

Comment 1 Ilya Konstantinov 2006-06-16 18:14:23 UTC
First, please change the summary of the bug to:
bluez-pin D-Bus service not automatically started for X sessions

If we'll add a .service file, it'll activate in the context of the system D-Bus
daemon and therefore wouldn't connect to our desktop. For now, there's no way to
add D-Bus .service files which'll activate only within the context of a session
D-Bus daemon.

The solution for now might be plugging bluez-pin into /etc/X11/xinit/xinitrc.d/
so it'll get started for each session.

Comment 2 David Woodhouse 2006-06-16 18:32:22 UTC
(In reply to comment #1)
> The solution for now might be plugging bluez-pin into /etc/X11/xinit/xinitrc.d/
> so it'll get started for each session.

We already created /etc/xdg/autostart/bluez-pin.desktop which ought to have the
desired effect. But the bluez-pin package _really_ ought to be owned by someone
who isn't entirely clueless about such things. 

Comment 3 Roland Wolters 2006-06-16 23:36:28 UTC
Topic changed as requested.
One thing to add, because it is about desktop sessions, and I want to be 
clear: I use the KDE desktop.

Comment 4 David Woodhouse 2006-06-17 08:41:54 UTC
I was told that /etc/xdg/autostart/bluez-pin.desktop should be honoured by all
desktop environments.

Comment 5 Ilya Konstantinov 2006-06-17 09:25:47 UTC
Could it be that this bug was filled by someone who hasn't restarted his X
session after installing bluez-pin?

We obviously need a method to start bluez-pin in all user sessions upon
installation; it's technically unnecessary to wait for a restart. D-Bus services
could work just great for this *if* we could specify that the service should be
started within sessions only.

Comment 6 Roland Wolters 2006-08-19 00:22:26 UTC
@Ilya: nope, bluez-pin was automatically installed on my machine so I 
definitely restarted X several times after installing bluez-pin.

Comment 7 David Woodhouse 2006-09-10 09:53:29 UTC
If KDE isn't honouring the /etc/xdg/autostart file, please file a bug against KDE.


Note You need to log in before you can comment on or make changes to this bug.