Patches on the way. They should hopefully be self-explanatory.
Created attachment 65232 [details] [review] 1/9] Install the examples and tests
Created attachment 65233 [details] [review] 2/9] Fix missing arguments to some functions in status-set I'm not 100% sure these values are right, but at least this test compiles now.
Created attachment 65234 [details] [review] 3/9] docs: resync Makefile.am with telepathy-glib
Created attachment 65235 [details] [review] 4/9] Install yts-version.h again --- Regression in my recent srcdir vs. builddir fixing.
Created attachment 65236 [details] [review] 5/9] Add DEBUG(), etc., macros based on the ones in telepathy-glib DEBUG ("%s", x) is more or less equivalent to g_debug ("%s: %s", __FUNCTION__, x). Similar for CRITICAL() and g_critical(), etc.
Created attachment 65237 [details] [review] 6/9] roster: debug when we add, or assume the presence of, a contact
Created attachment 65238 [details] [review] 7/9] YtsContact: debug when a contact gains, loses or is assumed to have a service
Created attachment 65239 [details] [review] 8/9] YtsContact: remember and replay service statuses for added services To reproduce a critical: * kill and restart MC * kill and restart Salut * run the demo client as of commit c792a82 * run the demo service (on the same laptop) The client often receives the service's status (a pseudo-PEP message) before it receives its capabilities (a XEP-0115 stanza). No order can be guaranteed for those two, because they follow different paths: status: * service receives client's _ytstenut._tcp * service pulls caps from client * service observes that client is interested in status * service pushes status to client caps: * service sends its own _ytstenut._tcp * client pulls caps from service This previously resulted in a critical warning and failure to process that status message. Now, the status is cached for future reference, and when the caps are retrieved, the old status is re-played.
Created attachment 65240 [details] [review] 9/9] YtsContact: don't crash if our contact or one of our services outlives us If the TpContact or one of the YtsService instances still exists after the YtsContact has been freed, and emits a signal to which the YtsContact is still subscribing, then we would crash with a use-after-free. Disconnect all of our signals to avoid that fate.
Created attachment 65242 [details] [review] YtsRoster: don't crash if contact's status arrives before TpContact Similar to a previously-fixed bug in YtsContact, the roster criticals and discards a status update if a contact's status is updated before the TpContact has arrived. This can be reproduced by killing and restarting MC, then Salut, then an example service. Fix it in much the same way as for YtsContact, by remembering the statuses for later.
Reviewed-by: danilo. Pushed.
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.