Bug 288881 - Sometimes after login the approver does not work
Summary: Sometimes after login the approver does not work
Status: RESOLVED FIXED
Alias: None
Product: telepathy
Classification: Unmaintained
Component: approver (show other bugs)
Version: git-latest
Platform: Ubuntu Linux
: NOR normal
Target Milestone: 0.4.0
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-13 10:59 UTC by George Kiagiadakis
Modified: 2012-07-06 12:47 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Kiagiadakis 2011-12-13 10:59:56 UTC
I have this weird problem on my laptop. Right after login, the approver doesn't work. All new channels are dispatched immediately to the text-ui. MC logs say that "no suitable approvers were found". However, the approver is running: it can be verified with qdbus and also from ~/.xsession-errors where I can clearly see the Tp::ClientRegistrar debug output saying that the approver was registered on the bus. Restarting kded solves the problem for the current session.

I fear this is some kind of race condition between kded and MC. A possible scenario is this: Our integration kded module starts, it requests the AccountManager, MC starts and registers itself on the bus, then the approver starts before MC is ready, it doesn't wait for MC because it doesn't use Tp::AccountManager, and meanwhile MC inspects the bus for existing clients, it finds none because the approver has not been registered yet, then the approver registers itself right before MC starts listening on the bus for new services.
Comment 1 Daniele E. Domenichelli 2011-12-13 11:29:28 UTC
I have the same problem, also unloading and loading the approver module works...
Perhaps installing a client file also for the approver will trick MC into believing that there is an approver then can be activated...
Comment 2 Martin Klapetek 2011-12-13 14:30:13 UTC
This could be possibly solved by (and is related to) bug 284779, then we could even assure correct loading order.
Comment 3 Daniele E. Domenichelli 2011-12-13 14:52:37 UTC
This might be a little hacky but it should work:
To ensure the correct loading order the approver we could have a file in 
/usr/share/dbus-1/services/org.freedesktop.Telepathy.Client.KDE.Approver.service

[D-BUS Service]
Name=/usr/share/dbus-1/services/org.freedesktop.Telepathy.Client.KDE.Approver
Exec=qdbus org.kde.kded /kded org.kde.kded.loadModule telepathy_kde_approver

and no client file.

Instead of starting the approver automatically at login, when MC starts, it will see that dbus is able to start a client that didn't install any .client file, therefore will start it to check its capabilities (this is what haze does, because it cannot have a .client file since its capabilities depend on the plugins installed). Then usually telepathy stuff (haze, for example) will exit and will be activated later on demand, but the kded module won't be unloaded and we will have the approver always running.
Comment 4 Daniele E. Domenichelli 2011-12-16 13:37:33 UTC
Git commit 5ebe32c9cce383fb998356adc07adb90baa18d8a by Daniele E. Domenichelli.
Committed on 16/12/2011 at 14:08.
Pushed by ddomenichelli into branch 'master'.

Add D-Bus Service file for approver

This fixes a race condition between kded and mission-control, the approver is
now started by mission control

BUG: 288881

M  +1    -0    src/CMakeLists.txt
A  +3    -0    src/org.freedesktop.Telepathy.Client.KDE.Approver.service
M  +2    -2    src/telepathy_kde_approver.desktop

http://commits.kde.org/telepathy-approver/5ebe32c9cce383fb998356adc07adb90baa18d8a