Pebbled/eavesdropping is actually at fault. The problem is that QtDbus believes the eavesdropped method calls are actually sent to the eavesdropping process, so it will generate method-return messages for them, even if they are empty ( ie "void" returns) .

Thus, a race condition is created: the method-return from the eavesdropping app (e.g. pebbled) may come BEFORE the method-return from lipstick. Since the one generated by pebbled is incorrect (it has no return_id field), the application that generated the notification will believe lipstick did not generate a notification id for it. Thus, shall a new email/IM come in, the application will create another notification, instead of updating the original notification which is now effectively leaked (no one except lipstick knows its notification ID, so no app can delete it ).

I am not sure this bug is the sole cause of the duplicate/leaked notifications but it is certainly a bug in pebbled and other smar****ch apps.

See https://gitorious.org/javispedro-jol...a31e91b86dd0e4 for how I fixed it (using QDBusContext and setDelayedReply), http://www.merproject.org/logs/%23ne...09-20T14:49:31 for my rationale.