Bug 15325 - Extensions for an interface conflict with tp-glib implementation of the same interface
Summary: Extensions for an interface conflict with tp-glib implementation of the same ...
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: unspecified
Hardware: Other All
: high blocker
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-02 07:42 UTC by Simon McVittie
Modified: 2008-04-04 06:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

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.