+++ This bug was initially created as a clone of Bug #54879 +++ On Bug #54879, Jonny noticed that the service-point code in MC wasn't robust against having more than one distinct service point, and was completely untested. His patch for that simultaneously fixed ServicePoints and switched to non-deprecated APIs and ported them to next, which is unwelcome from the point of view of "make master work first". Things we need to do: 1) Test and fix service points 2) Switch from deprecated to non-deprecated APIs 3) Make it work on next This bug is just (1).
Created attachment 68272 [details] [review] Require GLib 2.32, for GHashTable set APIs (add, contains)
Created attachment 68273 [details] [review] McdConnection: build up our sets of emergency numbers over time To facilitate this, use nicer data structures. Most importantly, this means we don't critical whenever we get more than one distinct service point, as Jonny noticed while porting to Telepathy 1.0. It might slightly defeat the intention of the ServicePointsChanged signal, but in practice the list is probably never going to shrink, and if it does, it's probably wise to keep considering its old members to be an emergency number (the effect that that has is that plugins aren't allowed to influence channel requests). Also, don't leak the sets of emergency numbers when finalized.
Created attachment 68274 [details] [review] Add a regression test for service-points (matched by identifier) The side-effect they have within MC is that plugins aren't allowed to delay or reject channel requests; we ought to test that, really.
All the patches look fine.
Fixed in git for 5.15.1, thanks
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.