Bug 15325

Summary: Extensions for an interface conflict with tp-glib implementation of the same interface
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: tp-glibAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: blocker    
Priority: high    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Simon McVittie 2008-04-02 07:42:10 UTC 
If a project has an internal implementation of an interface (e.g. Hold), and telepathy-glib adds an implementation of the same interface, they will fight - specifically, they will try to add the same dbus-glib signals for the same DBusGProxy, causing an assertion failure.

We should fix this before releasing telepathy-glib with Hold (version 0.7.6), so setting as a blocker.

Desired functionality: suppose telepathy-glib and some project-specific extensions both implement the Hold interface. Then the project-specific extensions should be assumed to be right, and tp-glib's signal-adding should not happen.

My branch of telepathy-inspector can be used to reproduce this, if compiled against my tp-glib-smcv branch. The symptom is:

** (telepathy-inspector:22914): CRITICAL **: dbus_g_proxy_add_signal: assertion `g_datalist_id_get_data (&priv->signal_signatures, q) == NULL' failed
Comment 1 Simon McVittie 2008-04-04 06:52:16 UTC 
Fixed in 0.7.6, although projects with extensions will need an update too.

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.