Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Method "GetSelfHandle" with signature "" on interface "org.freedesktop.Telepathy.Channel.Interface.Group" doesn't exist #48

Open
rekado opened this issue Jan 5, 2025 · 9 comments

Comments

@rekado
Copy link

rekado commented Jan 5, 2025

Hello,

I've packaged the Sugar desktop and a number of activities for Guix System. I have deployed Guix System with the Sugar desktop to a little netbook and I'm trying to get the Chat activity to work.

The netbook running Sugar is connected to WLAN, as is another laptop running Sway. On the netbook I launch the Chat activity and share it with the neighborhood. On the other laptop I run Pidgin with avahi, and I see that a link-local XMPP account corresponding to the netbook account appears.

I can send a message to it, and this triggers a notification on Sugar desktop, but no message text is received. The Pidgin account also does not show up on the Sugar neighborhood view.

In the logs for the Chat activity I see this error message:

Method "GetSelfHandle" with signature "" on interface "org.freedesktop.Telepathy.Channel.Interface.Group" doesn't exist

Do you have any pointers as to how I could debug this?

I actually do have a local Prosody installation, but it looks like I cannot make Chat use an existing XMPP account, so I'm trying to get the link-local connections to work. I'd appreciate any hints!

@chimosky
Copy link
Member

chimosky commented Jan 5, 2025

The pidgin account not showing in the Sugar neighborhood view is expected because the neighborhood view shows buddies and activities - which only gets shown when an instance is shared -

For the error you're seeing, GetSelfHandle is deprecated it seems, so we'll have to move away from it.

If you can setup two separate instances of Sugar, you should be able to use Chat with both instances by sharing one instance and joining with the other - assuming they're on the same network -, is this what you tried?

@quozl
Copy link
Contributor

quozl commented Jan 5, 2025

I agree, this seems likely to be an API regression, so the place to look is Telepathy's source code. You could also try older revisions of Telepathy modules until it works differently.

https://help.sugarlabs.org/en/collaborating.html has a procedure for collaborating between two systems running Sugar.

@rekado
Copy link
Author

rekado commented Jan 8, 2025

Thanks for the quick response! I have been looking at the code of Telepathy Glib and haven't found anything obvious. I'm not terribly familiar with gobject introspection, glib, and dbus, so I'm reading up on how to best inspect the available interfaces and the provided methods. From what I gather the GetSelfHandle method ought to still exist in the version of Telepathy Glib that I'm using (deprecation notwithstanding).

I have in fact shared the Chat activity, which is necessary to let the user on Sugar send messages in the first place. I do see the Sugar account in Pidgin when the activity is shared. For future tests I'll set up a second system with Sugar (VM in qemu with bridge networking should be fine) and see if chat works this way.

@rekado
Copy link
Author

rekado commented Jan 8, 2025

I've launched d-feet to inspect the available dbus methods. On the session bus I see the bus org.freedesktop.Telepathy.Connection.salut.local_xmpp.bda7ede9, which provides an object /org/freedesktop/Telepathy/Connection/salut/local_xmpp/bda7ede9/MucChannel/1 implementing the interface org.freedesktop.Telepathy.Channel.Interface.Group. It offers the method GetSelfHandle() -> (UInt32 Self_Handle) and executing this method from d-feet without any input arguments returns the output 1.

This all seems correct.

The log generated by dbus-monitor indicates that it's not a problem with MucChannel/1, but with the ImChannel that is created when the message from Pidgin is received.

method call time=1736342823.022153 sender=:1.20 -> destination=:1.7 serial=62 path=/org/freedesktop/Telepathy/Connection/salut/local_xmpp/bda7ede9/ImChannel2; interface=org.freedesktop.Telepathy.Channel.Interface.Group; member=GetSelfHandle
[...]
error time=1736342823.026199 sender=:1.7 -> destination=:1.20 error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=62
   string "Method "GetSelfHandle" with signature "" on interface "org.freedesktop.Telepathy.Channel.Interface.Group" doesn't exist

The response to the introspection request just prior to calling GetSelfHandle looks like this (abridged):

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
  <interface name="org.freedesktop.DBus.Introspectable">
    <method name="Introspect">
      <arg name="data" direction="out" type="s"/>
    </method>
  </interface>
  <interface name="org.freedesktop.DBus.Properties"> [...] </interface>
  <interface name="org.laptop.Telepathy.ActivityProperties"> [...] </interface>
  <interface name="org.laptop.Telepathy.BuddyInfo"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.Sidecars1"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactInfo"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.Avatars"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.SimplePresence"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.Contacts"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.Aliasing"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection.Interface.Requests"> [...] </interface>
  <interface name="org.freedesktop.DBus.Properties"> [...] </interface>
  <interface name="org.freedesktop.Telepathy.Connection">
    [...]
    <method name="GetSelfHandle">
      <arg name="Self_Handle" type="u" direction="out"/>
    </method>
    [...]
  </interface>
  <node name="ContactList"/>
  <node name="ImChannel2"/>
  <node name="MucChannel"/>
</node>

I'm not sure what to make of this, but it looks like the ImChannel for a received external message does not implement the org.freedesktop.Telepathy.Channel.Interface.Group interface.

@rekado
Copy link
Author

rekado commented Jan 8, 2025

Perhaps things go wrong in _received_cb already:

        if self._activity_cb:
            try:
                self._text_chan[TelepathyGLib.IFACE_CHANNEL_INTERFACE_GROUP]
            except Exception:
                # One to one XMPP chat
                co = TelepathyGLib.IFACE_CONNECTION_INTERFACE_ALIASING
                nick = self._conn[co].RequestAliases([sender])[0]
                buddy = {'nick': nick, 'color': '#000000,#808080'}
            else:
                # Normal sugar3 MUC chat
                # XXX: cache these
                buddy = self._get_buddy(sender)

The backtrace shows that _get_buddy is called, which seems to be wrong in this scenario. Since this is an external XMPP message I would expect the except clause to be executed. I'll try to poke around a bit more to see what _text_chan this is and why there is no exception upon accessing its IFACE_CHANNEL_INTERFACE_GROUP field.

@rekado
Copy link
Author

rekado commented Jan 8, 2025

I managed to send a message from my laptop running Pidgin to Chat on the netbook running Sugar with this patch:
chat.txt

It seems to me that the exception is never raised, because _one_to_one_connection_ready_cb will always assign to text_channel[TelepathyGLib.IFACE_CHANNEL_INTERFACE_GROUP]. Hence accessing this field never raises an exception. My patch explicitly sets a property when a one-to-one connection is established and checks that property.

@quozl
Copy link
Contributor

quozl commented Jan 8, 2025

Hmm, looks like you have it in hand. Let us know when you have figured it out. A regression in any of the dependencies seems likely.

@rekado
Copy link
Author

rekado commented Jan 8, 2025

Do you happen to know if this works as intended in an installation with blessed dependency versions? It is unclear to me what exception is assumed to be raised here, but from what I understand a key error is expected in the one-to-one case, which cannot ever be raised as the key is ensured to be assigned to.

(I haven't yet tested if my patch breaks the common case of communication between Chat instances.)

@quozl
Copy link
Contributor

quozl commented Jan 8, 2025

Well, last I checked, yes it did. But I don't have a clear idea of release versions. Have a look at Sugar Live Build or OLPC OS.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants