So for the code I'm working on, some components will be running confined and only have access to their own service IDs, while there will also be an unconfined process acting as a central registry that wants to know about the accounts that have active services for any of the related confined processes.
Are you seriously saying that I should use one API for some of these processes and a totally different one for the others? At the D-Bus level, everything seems to be doing what I want and would expect: it is just the client library getting in the way. And from what you've described, my patch should have no impact to confined applications using the new API, since the D-Bus service will only return a single service per account there. This just makes the client library functional in the unconfined case rather than just acting unpredictably. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1602159 Title: Manager class only provides access to one (random?) service ID for an account To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/online-accounts-api/+bug/1602159/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
