Build logs can be found at:

https://launchpad.net/ubuntu/+source/telepathy-glib/0.15.4-1ubuntu1

Interesting bits:

/account-channels/request-handle/create-success: 
GLib-GObject-WARNING **: cannot register existing type `TpDBusDaemon'
aborting...
Aborted

That's weird, it works fine for me here on Natty.

libtool: link: gcc -std=gnu99 -Wall -Wextra -Wdeclaration-after-statement -Wshadow -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare -Wnested-externs -Wpointer-arith -Wformat-security -Winit-self -Wno-missing-field-initializers -Wno-unused-parameter -g -O2 -Wl,-Bsymbolic-functions -Wl,-O1 -o .libs/test-account-channel-request account-channel-request.o -pthread -pthread  ../../tests/lib/.libs/libtp-glib-tests.a /build/buildd/telepathy-glib-0.15.4/telepathy-glib/.libs/libtelepathy-glib.so ../../telepathy-glib/.libs/libtelepathy-glib-internal.a -ldbus-glib-1 -ldbus-1 -lpthread /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so /usr/lib/x86_64-linux-gnu/libgthread-2.0.so -lrt /usr/lib/x86_64-linux-gnu/libglib-2.0.so -pthread

Notice that account-channel-request is being linked against the shared libtelepathy-glib.la, and also the static libtelepathy-glib-internal.la with the same contents. So yes, you really do have two TpDBusDaemon types, with different addresses - kaboom.

If it's possible to avoid having any tests that link both libtelepathy-glib-internal.la (to access _tp symbols) and libtp-glib-tests.la (to access miscellaneous test goo), that would be a good solution.

If not, then libtp-glib-tests.la will have to become an incomplete library, which requires anything linking libtp-glib-tests.la to also link either libtelepathy-glib-internal.la or libtelepathy-glib.la. This makes me a bit sad, 

This might be an Ubuntu-specific problem because Ubuntu's build environment seems to be using -Wl,-Bsymbolic-functions by default?

I think you're right, this test wasn't linking on those before:
http://cgit.freedesktop.org/telepathy/telepathy-glib/diff/tests/dbus/Makefile.am?id=ed21d5b431b6e8fa3ba78b0f638653fc13b4c5ac

(In reply to comment #3)
> If it's possible to avoid having any tests that link both
> libtelepathy-glib-internal.la (to access _tp symbols) and libtp-glib-tests.la
> (to access miscellaneous test goo), that would be a good solution.

Not really here. We do need both in this test.

I've been able to reproduce this failure on Debian by using -Bsymbolic. Patch to follow.

Created attachment 49243 [details] [review]
Link a second static library for libtp-glib-tests, against libtelepathy-glib-internal.la

Linking with -Bsymbolic (as done by default on recent Ubuntu) ends up
linking different parts of the executable against the copy of
libtelepathy-glib-internal in the shared library, and the copy in the
static library. This leads to mysterious GLib assertion failures.

Tests that need to access internal symbols (and thus link against
libtelepathy-glib-internal.la) must now use libtp-glib-tests-internal.la
instead of libtp-glib-tests.la.

There's currently no difference between the two except their dependencies,
but in principle, we could add test glue that also requires internal
symbols to libtp-glib-tests-internal while avoiding including it in
libtp-glib-tests.

Review of attachment 49243 [details] [review]:

Ugh. It kind of offends me that tests need internal symbols … but I guess it offends you too ;)

This change looks fine, ship it.

(In reply to comment #8)
> Ugh. It kind of offends me that tests need internal symbols … but I guess it
> offends you too ;)

In the cases I'm aware of where they're using internal symbols, it offends me less than it would if the shared library exposed the same things :-)

> This change looks fine, ship it.

Shipped it, only to master for the moment (it should be easy to backport if anyone wants it).