|Summary:||Haze accounts loses sync with Gnome-Shell|
|Product:||Telepathy||Reporter:||Laurent Bigonville <bigon>|
|Component:||mission-control||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|Priority:||medium||CC:||bigon, pedrogfrancisco, xclaesse|
|i915 platform:||i915 features:|
Gnome Shell Me menu unaware of tp-haze
Description Laurent Bigonville 2012-05-08 04:30:12 UTC
Created attachment 61216 [details] MC logs Hi, From times to times, when booting my machine my MSN (using telepathy-haze) is not connecting automatically when gnome-shell is starting. Telepathy-haze is not running at all. Explicitly setting the status or disabling/reenabling the account makes tp-haze to be spawned and getting connected.
Comment 1 Laurent Bigonville 2012-06-20 02:14:22 UTC
Created attachment 63253 [details] Backtrace I'm not sure this is 100% related, but sometimes, MC is crashing with the following backtrace. Is it possible that MC is crashing mid-air and thus not connecting the next account in its list?
Comment 2 Laurent Bigonville 2012-07-13 09:46:16 UTC
Mhhh I think I've found the issue (and it's maybe PEBCAK) "mc-tool show" was saying: Connects: only when requested I've set the auto-connect to on. Let's see if I can still reproduce this. But, AFAIK mc was connecting some (gabble) accounts even if the auto-connect was not enabled.
Comment 3 Xavier Claessens 2012-07-13 09:50:28 UTC
I think empathy's MC plugin for GOA is racy. It does not wait for the "ready" function to be called before emitting signals. That could explain some issues...
Comment 4 Xavier Claessens 2012-07-13 09:50:57 UTC
ah, this is about tp-haze... sorry wrong bug then :)
Comment 5 pedrogfrancisco 2012-07-13 13:43:42 UTC
I can get the issue even when not connecting. It's as if haze disconnects from the rest of the status: snippet of output of various "mc-tool show": HAZE: Presences: Automatic: available (2) "" Current: available (2) "" <------------------- Requested: available (2) "" <------------------- Changing: no GOA FBook: Presences: Automatic: available (2) "" Current: dnd (6) "" Requested: busy (6) "" Changing: no GOA GTalk: Presences: Automatic: available (2) "" Current: dnd (6) "" Requested: busy (6) "" Changing: no
Comment 6 pedrogfrancisco 2012-07-17 14:03:44 UTC
Created attachment 64315 [details] Gnome Shell Me menu unaware of tp-haze Gnome Shell menu seems to be unaware of tp-haze existence (see attached file). Is it normal?
Comment 7 pedrogfrancisco 2012-07-18 11:01:18 UTC
I'm thinking the screenshot isn't clear: with only Haze enabled, Gnome Shell menu has a greyed out 'Available/Unavailable' menu, suggesting Haze isn't properly announcing to Gnome-Shell it is enabled.
Comment 8 pedrogfrancisco 2012-07-21 11:55:11 UTC
How to reproduce: 1. Create any Haze account (tested with Yahoo and Windows Live (MSN)) 2. Verify using Gnome-Shell menu, status changes to Busy with setting "Notifications off", to online with "Notifications on" and to offline with "Unavailable". 3. Logout and login (or reboot) 2. Verify using Gnome-Shell menu, status does NOT change to Busy with setting "Notifications off", to online with "Notifications on" and to offline with "Unavailable". Other accounts (i.e., not Haze) work fine.
Comment 9 pedrogfrancisco 2012-07-31 10:13:39 UTC
Actually login and logout is not enough, a reboot is required. I'm guessing some kind of call (D-Bus?) is made registering Haze with something when the Haze account is created (some "internal" state/component which survives a logout) but when the Haze account is read from a file such as the accounts' config it is not registered with such "internal" component.
Comment 10 pedrogfrancisco 2012-08-02 23:20:06 UTC
Ok, it seems I was wrong. I seem to have fixed the problem by having a .config/autostart/mission-control.desktop which has Exec=/usr/libexec/mission-control-5 . Previously I would have Empathy starting at Gnome-Shell startup using a similar approach. Considering that if I try something like $ ./telepathyKillAllComponentes.sh ; empathy-accounts empathy accounts will show only GOA accounts the first time it's run (but show all of them the second time) I'll guess forcing Empathy to start at Gnome-Shell startup was messing things up by exposing some kind of race condition. Either that or one of the latest telepathy-glib updates did something for this.
Comment 11 Laurent Bigonville 2012-11-13 20:07:33 UTC
Created attachment 70028 [details] [review] Increase timeout During this summer, Guillaume looked with me at this bug. We found that one DBUS call was timing out, increasing the timeout was fixing this. He also thought that it was related to folks blocking gnome-shell. Unfortunately, I'm still seeing this in gnome-shell 3.6 too. If I've understood correctly, this shouldn't happen anymore as folks has been decoupled out of gnome-shell. The attached patch has been made against tp-mc 5.12.1
Comment 12 Simon McVittie 2012-11-14 13:47:09 UTC
Comment on attachment 70028 [details] [review] Increase timeout Review of attachment 70028 [details] [review]: ----------------------------------------------------------------- There are more instances of calls to introspect a client: I feel as though if we extend one, we should extend them all. (We shouldn't extend the timeout when we call HandleChannels or similar, though.) In _mcd_client_proxy_get_interfaces_cb we call Get or GetAll 3 times. In mcd_client_proxy_introspect there is a call to GetAll. ::: telepathy-mission-control-5-5.12.1/debian/patches/path_cassidy.patch @@ +4,5 @@ > + > + _mcd_client_proxy_inc_ready_lock (self); > + > +- tp_cli_dbus_properties_call_get (self, -1, > ++ tp_cli_dbus_properties_call_get (self, G_MAXINT, Strictly speaking, the infinite timeout is G_MAXINT32 (although they're numerically the same on any sane platform). I'd prefer to use the named constant to make the meaning obvious: #include <dbus/dbus.h> #ifndef DBUS_TIMEOUT_INFINITE /* dbus < 1.4.12 didn't have this */ # define DBUS_TIMEOUT_INFINITE G_MAXINT32 #endif ... tp_cli_dbus_properties_call_get (self, DBUS_TIMEOUT_INFINITE, ...
Comment 13 Simon McVittie 2012-11-14 13:49:47 UTC
(In reply to comment #11) > We found that one DBUS call was timing out, increasing the timeout was > fixing this. It seems a vaguely reasonable thing to do, although I can't help thinking that any Client that doesn't respond to us within 25 seconds has bigger problems... Can you get a dbus-monitor log from this call into a Client timing out? > Unfortunately, I'm still seeing this in gnome-shell 3.6 too. If I've > understood correctly, this shouldn't happen anymore as folks has been > decoupled out of gnome-shell. Yes, in 3.5.4.
Comment 14 Laurent Bigonville 2012-12-06 09:59:40 UTC
MMMh... So I was a wrong, the patch I've proposed was about the notifications not being displayed in gnome-shell, not about the accounts being out of sync... sorry for the confusion :/
Comment 15 GitLab Migration User 2019-12-03 20:11:52 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/56.