Created attachment 66781 [details]
gabble debug log from empathy
iChat appears to not like it when empathy (or is it telepathy or gabble?) response with an error code of 404 and item-not-found to a disco request.
It looks like it just sends the disco request again immediately. And again. And again causing telepathy-gabble to peg a CPU at 100% usage.
In the attached log, I've replaced the jabber server name with jabber.example.org.
dan@ is using Mac OS X Lion and Messages version 6.1 (11D1069)
I am using Empathy 184.108.40.206 from Debian unstable's 220.127.116.11-1+build1 package. Other Telepathy packages are:
$ dpkg -l|grep telepathy
ii banshee-extension-telepathy 2.4.0-1 all Telepathy extension for Banshee
ii gir1.2-telepathyglib-0.12 0.18.2-2 amd64 GLib Telepathy connection manager library (GObject-Introspection)
ii gir1.2-telepathylogger-0.2 0.4.0-1 amd64 Telepathy logger service - introspection
ii libfolks-telepathy25 0.6.9-1+b1 amd64 Telepathy backend for libfolks
ii libtelepathy-farstream2:amd64 0.4.0-3 amd64 Glue library between telepathy and farstream
ii libtelepathy-glib0:amd64 0.18.2-2 amd64 Telepathy framework - GLib library
ii libtelepathy-logger2:amd64 0.4.0-1 amd64 Telepathy logger service - utility library
ii remmina-plugin-telepathy 1.0.0-4 amd64 Telepathy plugin for remmina remote desktop client
ii telepathy-gabble 0.16.1-1 amd64 Jabber/XMPP connection manager
ii telepathy-haze 0.6.0-1 amd64 Telepathy connection manager that uses libpurple
ii telepathy-idle 0.1.12-1 amd64 IRC connection manager for Telepathy
ii telepathy-logger 0.4.0-1 amd64 Telepathy logger service - Daemon
ii telepathy-mission-control-5 1:5.12.1-2 amd64 management daemon for Telepathy real-time communication framework
ii telepathy-rakia 0.7.4-1 amd64 SIP connection manager for the Telepathy framework
ii telepathy-ring 2.1.0-1+b1 amd64 GSM and 3G UMTS Telepathy connection manager
ii telepathy-salut 0.8.0-2 amd64 Link-local XMPP connection manager for the Telepathy framework
We need to extend caps/trust-thyself.py to disco every caps bundle in our ext attribute, then make it pass again.
Created attachment 66798 [details] [review]
1/4] Add Google camera-v1 as a first-class caps bundle
This is partly a point of principle - given any caps bundle that we have
ever advertised support for, we should be prepared to define when asked -
but mainly a workaround for the iChat bug mentioned in commit af55ea3d.
If we return an error, it will keep disco'ing us repeatedly in a loop.
This leaves us with the problem of finding out what the bundle contains.
In Google's usage it is only its name that is important (ignoring that
XEP-0115 explicitly makes bundle names opaque), but replying to disco
requests for it requires us to be able to turn it into a set of 0 or
more capability URIs. Because of the Google server bug mentioned in
commit cd0da0a8, we can't just ask a Google client, because they're
all on Google servers, so they can't usefully be disco'd.
We assume here that it behaves like the voice-v1 and video-v1 bundles
in containing exactly one URI, and that that URI corresponds to the
bundle name in the same way.
Created attachment 66799 [details] [review]
2/4] Now that camera-v1 has a caps URI, don't treat it as part of video-v1
Created attachment 66800 [details] [review]
3/4] Verify that every caps 'ext' we ever advertise can be disco'd without error
Created attachment 66801 [details] [review]
4/4] Turn off deprecation warnings, this is a stable branch
Fixed in 0.16.3, 0.17.1. Cross-references: this bug is also Debian #687370, LP: #984132.