Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#3629 closed defect (fixed)

Gabble/XS communication broken in OLPC 12.1.0/Sugar 0.96 builds

Reported by: greenfeld Owned by: dsd
Priority: Urgent Milestone:
Component: Sugar Version: 0.96.x
Severity: Critical Keywords: 12.1.0
Cc: manuq Distribution/OS: OLPC
Bug Status: Assigned


Gabble/XS communication appears to be broken in OLPC 12.1.0 os11 when tested with a XS 0.7 schoolserver.

Registering to the server works fine; and the shared activities show in the Network view. But when Chat is shared on one XO publicly, the sharing computer sees other system(s) join, but said other systems never fully join and hang showing single-user mode status.

Distance similarly works over Salut but not using the XS server.

No obvious reason for why things are failing is found in the individual activity logs.

Change History (14)

comment:1 Changed 12 years ago by dsd

  • Owner changed from erikos to dsd
  • Status changed from new to assigned

comment:2 Changed 12 years ago by martin.langhoff

Repros with 12.1.0 os12 build vs XS 0.7. Investigating.

comment:3 Changed 12 years ago by erikos

  • Bug Status changed from Unconfirmed to Assigned
  • Milestone changed from Unspecified by Release Team to 0.96
  • Priority changed from Unspecified by Maintainer to Urgent
  • Severity changed from Major to Critical
  • Version changed from Unspecified to 0.96.x

On the joiner side we are not able to get valid contact handle for the learner that shared the activity. The GetAllMembers call does fail.

339596393.266597 DEBUG root: ActivityService.set_active: 1.
1339596394.350856 DEBUG sugar3.presence.activity: <_JoinCommand object at 0x599940 (sugar3+presence+activity+_JoinCommand at 0x707b10)>: Text channel < object at 0x7b1db0> is ready
1339596394.352654 DEBUG sugar3.presence.activity: <_JoinCommand object at 0x599940 (sugar3+presence+activity+_JoinCommand at 0x707b10)>: Tubes channel < object at 0xb8b1d0> is ready
1339596394.353541 DEBUG sugar3.presence.activity: <_JoinCommand object at 0x599940 (sugar3+presence+activity+_JoinCommand at 0x707b10)>: finished setting up tubes
1339596394.399974 DEBUG sugar3.presence.activity: got_all_members members dbus.Array([dbus.UInt32(7L), dbus.UInt32(8L)], signature=dbus.Signature('u')) local_pending dbus.Array([], signature=dbus.Signature('u')) remote_pending dbus.Array([], signature=dbus.Signature('u'))
1339596394.401419 DEBUG sugar3.presence.activity: __text_channel_members_changed_cb added dbus.Array([dbus.UInt32(7L), dbus.UInt32(8L)], signature=dbus.Signature('u')) removed () local_pending () remote_pending () channel_self_handle dbus.UInt32(7L)
1339596394.402531 DEBUG sugar3.presence.activity: <Activity object at 0x599fd0 (sugar3+presence+activity+Activity at 0x6e1c20)>: Join finished None
1339596394.418503 DEBUG sugar3.presence.activity: __get_all_members_cb dbus.Array([dbus.UInt32(7L), dbus.UInt32(8L)], signature=dbus.Signature('u')) dbus.UInt32(7433L)
1339596394.436480 DEBUG sugar3.presence.activity: __error_handler_cb DBusException(dbus.String(u'handle 0 is not currently a valid contact handle (type 1)'),)
** Message: console message: undefined @0: TypeError: 'null' is not an object

1339596401.214324 DEBUG root: ActivityService.set_active: 0.
1339596401.226808 DEBUG root: dbus.String(u'0d16e9c5-b1c1-489e-8da0-af9330b17cb6')
1339596401.678136 DEBUG root: ########## writing {"deleted": [], "shared_links": [], "current_tab": 0, "currents": [{"url": "file:///home/olpc/.library_pages/index.html", "history_index": 0, "title": "OLPC Library"}], "history": [[{"url": "file:///home/olpc/.library_pages/index.html", "title": "OLPC Library"}]]}
1339596401.701944 DEBUG root: datastore.write
1339596401.703257 DEBUG root: dbus_helpers.update: 0d16e9c5-b1c1-489e-8da0-af9330b17cb6, /home/olpc/.sugar/default/org.laptop.WebActivity/instance/1339596401, {'activity_id': dbus.String(u'9c7adbf38b7570e92ae3b41ee0a5c5fdaca0f6c0', variant_level=1), 'title_set_by_user': '0', 'uid': dbus.String(u'0d16e9c5-b1c1-489e-8da0-af9330b17cb6'), 'title': 'OLPC Library', 'timestamp': 1339596401, 'activity': 'org.laptop.WebActivity', 'share-scope': 'public', 'keep': '0', 'icon-color': '#5E008C,#FF2B34', 'mtime': '2012-06-13T14:06:41.702839', 'preview': '<omitted>', 'mime_type': 'text/plain'}, True
1339596401.718490 DEBUG root: Written object 0d16e9c5-b1c1-489e-8da0-af9330b17cb6 to the datastore.

comment:5 Changed 12 years ago by erikos

To make sure I did try to use the 'HandleOwners' property instead of the 'GetHandleOwners' method, but that gives as well an invalid contact handle. So the deprecation itself from the 'GetHandleOwners' method does not look to be the regression here.

comment:6 Changed 12 years ago by erikos

Another debugging sample:

  • share on 883
  • join with a 12.1.0 machine

---> sharing is possible

  • share on a 12.1.0 machine
  • join on 883

---> sharing is not possible, same contact handle error as above

comment:7 Changed 12 years ago by erikos

Ok, I compared a bit the steps an activity is going through when it is shared on an 11.3.0 system and our current one. That part that differs is that with latest Gabble we do not have a PROPERTIES_INTERFACE for our text channel see

If on an old-style system I do NOT tweak the properties like here I do get the same sharing experience we see with Gabble at the moment and on the receiver side the contact handle of the sharer is invalid.

If I interpret the telepathy docs correctly the Telepathy.Properties interface has been removed in favor of D-Bus properties, the once we need to set seem to be under Channel_Interface_Room_Config1. That is the next thing to look at, see if we can access that interface and if that brings us forward.

comment:8 Changed 12 years ago by erikos

Looks like this is the commit that removed the SetProperties for the channel:

I tried to downgrade the telepathy-stack (glib-0.15.5/salut-0.5.2/gabble-0.12.7) to before that commit but tp-glib exits there. There might be some issues with that approach. But an option that might be doable for 12.1.0.

The other one is refactor the SetProperties back in. Not sure how hard that exactly is.

I tried to get suggestions on the #telepathy channel but Friday night is probably not the best time for that :/

comment:9 Changed 12 years ago by manuq

  • Cc manuq added

comment:10 Changed 12 years ago by erikos

Ok, I think there are two different approaches to the issue:

  • bring back the SetProperties interface for the channel
  • use the new Channel_Interface_Room_Config1 dbus interface

I looked at the changes that are around and related and they are quite large. Probably not something we can do.

For using the Channel.Interface.RoomConfig1 interface we have to change telepathy-python so that we can access it. If you look at '/usr/lib/python2.7/site-packages/telepathy/_generated/' you can see the generated interfaces.

I would ask upstream what they think about it as well. And don't get distracted by 'did you try master' answers :)

comment:11 Changed 12 years ago by dsd

RoomConfig1 can be easily accessed over dbus, handed off from the regular telepathy-python API in the same fashion used throughout presence/ No need for telepathy-python work.

Setting the properties on the sharer side as was done before fixes this issue. In particular, the "anonymous" flag needs to be set to False (defaults to True). The source code comments say that it must be False to enable buddy resolution, so this is starting to make sense.

comment:13 Changed 12 years ago by dsd

  • Resolution set to fixed
  • Status changed from assigned to closed

Pushed to sugar-toolkit and sugar-toolkit-gtk3

comment:14 Changed 11 years ago by dnarvaez

  • Milestone 0.96 deleted

Milestone 0.96 deleted

Note: See TracTickets for help on using tickets.