Created attachment 39842 [details] trace with breakpoint in "salut_im_manager_new_channel" on the machine B Downstream Sugar/OLPC bug: http://dev.laptop.org/ticket/10400 How to reproduce: - open an activity on machine A - invite machine B to it - join the invitation on machine B - quit activity in machine A ---> a new invitation on machine B is launched, a chat activity in the color of machine B From debugging Sugar does try to handle a private-invitation from the Presence Service, which is a connection by a non-Sugar XMPP client (IMChannel). From tracing in "salut_im_manager_new_channel" on machine B I found out that we receive an uninvite signal. I have attached the traceback.
As described above we do send an uninvite message that gets triggered as an invitation on the Sugar side. Based on the logs on the receiver side we do get in here, since the room is unknown: http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-connection.c#n3393, on the sender side we do get in here http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-olpc-activity.c?h=telepathy-salut-0.4#n741 - the code in master has actually changed in that area, so I will have a look if that already fixed the issue.
Hmmm, moving to HEAD for telepathy-glib and telepathy-salut causes activities to not start anymore, calling GetActivity on the connection seem to fail. Maybe someone has an idea about that one or the original issue described.
Can you attach some Salut logs and perhaps some dbus-monitor logs too so we can see exactly what's going on? It's feasible that I have broken activity support in Salut master.
I have been doing some more analysis of the issue. The scenario is: - open an activity on machine A - invite machine B to it - join the invitation on machine B - quit activity in machine A ---> a new invitation on machine B is launched, a chat activity in the color of machine B When A quits the activity it tries to revoke the invitations and calls 'salut_olpc_activity_revoke_invitations' ( http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-olpc-activity.c?h=telepathy-salut-0.4#n680 ). As I understand it, this revokes the invitations that have been done to machines that have not accepted that invitation at this moment yet. For example A invites B and C, B did join, A quits and at that point the invitation to C should be revoked (side note: this actually is not handled cleanly see http://dev.laptop.org/ticket/11020). We seem to keep track of the invitations done and when it is accepted we try to remove the contact from our list ( http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-self.c?h=telepathy-salut-0.4#n978 ). The problem is that we do not get the SALUT_CONTACT_OLPC_ACTIVITIES changes on A (ActivitiesChanged), we only get signaled that the current activity of B changed. So we do not remove B from our list of invitations and hence when we quit the activity we try to revoke the invitation. I compared with a another sharing scenario without invitations where A shares publicly and B joins: here we do get the 'ActivitiesChanged' signal on A when B joins. It would be great if someone could comment on my findings and analysis from above, thanks in advance.
(In reply to comment #4) > When A quits the activity it tries to revoke the invitations and calls > 'salut_olpc_activity_revoke_invitations' ( > http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-olpc-activity.c?h=telepathy-salut-0.4#n680 > ). As I understand it, this revokes the invitations that have been done to > machines that have not accepted that invitation at this moment yet. For example > A invites B and C, B did join, A quits and at that point the invitation to C > should be revoked (side note: this actually is not handled cleanly see > http://dev.laptop.org/ticket/11020). Yeah that's how it's supposed to work iirc. > We seem to keep track of the invitations done and when it is accepted we try to > remove the contact from our list ( > http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-self.c?h=telepathy-salut-0.4#n978 > ). The problem is that we do not get the SALUT_CONTACT_OLPC_ACTIVITIES changes > on A (ActivitiesChanged), we only get signaled that the current activity of B > changed. So we do not remove B from our list of invitations and hence when we > quit the activity we try to revoke the invitation. I compared with a another > sharing scenario without invitations where A shares publicly and B joins: here > we do get the 'ActivitiesChanged' signal on A when B joins. On which side (which salut) are you not getting the ActivitiesChanged signal? B I guess? So, if I understood things correctly I think the bug is in B which doesn't not correctly handle the 'uninvite' stanza sent by A. Would be good if you could post Salut logs from A and B. Try to generate them with SALUT_DEBUG=all WOCKY_DEBUG=all GIBBER_DEBUG=all.
Created attachment 48464 [details] tp-salut log from machine A This is the log from machine A taken after A has closed the activity.
Created attachment 48465 [details] tp-salut log from machine B This is the log from machine B, taken after machine A left.
(In reply to comment #5) > > We seem to keep track of the invitations done and when it is accepted we try to > > remove the contact from our list ( > > http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/salut-self.c?h=telepathy-salut-0.4#n978 > > ). The problem is that we do not get the SALUT_CONTACT_OLPC_ACTIVITIES changes > > on A (ActivitiesChanged), we only get signaled that the current activity of B > > changed. So we do not remove B from our list of invitations and hence when we > > quit the activity we try to revoke the invitation. I compared with a another > > sharing scenario without invitations where A shares publicly and B joins: here > > we do get the 'ActivitiesChanged' signal on A when B joins. > > On which side (which salut) are you not getting the ActivitiesChanged signal? > B I guess? No, we do not get the ActivitiesChanged signal on A, which means that A can not adjust the list of invitations accordingly, remove B from that list so that he does not send him the uninvite signal anymore. > So, if I understood things correctly I think the bug is in B which doesn't not > correctly handle the 'uninvite' stanza sent by A. I actually think there are two bugs: one is that A should not send an uninvite signal if B did join already. The second bug is that B should handle an uninvite signal cleanly and remove the previous invitation if it has not joined yet (handled in #38712). > Would be good if you could post Salut logs from A and B. Try to generate them > with SALUT_DEBUG=all WOCKY_DEBUG=all GIBBER_DEBUG=all. I have attached the logs.
I just tested this on Fedora 16 with the following setup: tp-mission-control=5.9.2, tp-salut=0.5.1. and tp-glib=0.15.5, the behavior is the same, reproducible here as well.
-- 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-salut/issues/24.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.