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 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 [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.
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.