telepathy-gabble increasingly high cpu usage with jabber - Error log included

Created attachment 66781
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 3.4.2.3 from Debian unstable's 3.4.2.3-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
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
2/4] Now that camera-v1 has a caps URI, don't treat it as part of video-v1

Created attachment 66800
3/4] Verify that every caps 'ext' we ever advertise can be disco'd without error

Created attachment 66801
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.