[08:26] <duflu> anpok: I checked errors.ubuntu.com today and found a couple of new USC crashes that are happening in the Mir input code. Have a look (for Criticals or new bugs): https://launchpad.net/mir/+milestone/1.0.0
[08:26] <duflu> I only picked the ones known to occur in 17.04
[08:53] <duflu> alf_: Do you have an upstream link for your protobuf fix?
[08:53] <duflu> "re-fix"
[09:25] <anpok> duflu: I think they have the same root cause..
[09:25] <duflu> Win
[09:26] <duflu> Killing two bugs with one fix
[09:38] <alan_g> anpok: greyback: questions answered? https://code.launchpad.net/~alan-griffiths/miral/raii-for-blob-and-cookie/+merge/319229
[09:41] <anpok> alan_g: oh because of the operator MirBlob*..
[09:41] <anpok> I didnt realize friend can do that..
[09:43] <alan_g> That's the Barton & Nackman trick
[09:44] <alan_g> Although the use with "deleted" wasn't possible in the '90s
[09:45] <anpok> ah friend injects the function at global scope and delete does the opposite..
[09:46] <anpok> so it avoids that the one with MirBlob* is even considered
[09:46] <alan_g> s/global scope/namespace scope/
[09:46] <alan_g> But yes
[09:46] <alan_g> The one with MirBlob* is in the overload set, but not selected as it requires a user written conversion
[15:58] <alan_g> camako: need any more answers? https://code.launchpad.net/~alan-griffiths/mir/drag-and-drop-II/+merge/319820
[16:06] <camako> alan_g, probably ... I'll continue the review
[16:06]  * bschaefer should review as well
[16:07] <alan_g> more eyes fewer bugs
[16:08] <alan_g> (maybe)
[16:09] <bschaefer> ideally :)
[16:13] <bschaefer> alan_g, a handle is just the raw data a drag and drop will be passing? (just an arbitrary amount of bytes i assume)
[16:13] <bschaefer> we could alway typedef it but meh should be fine as a vector
[16:13] <alan_g> bschaefer: it's a key (an ssid registered with content hub)
[16:14] <alan_g> But Mir doesn't need to care
[16:14] <bschaefer> o yeah i see  std::vector<uint8_t> const handle{std::begin(uuid), std::end(uuid)};
[16:14] <bschaefer> thats fair, was just thinking it didnt give much info on what it was
[16:16]  * bschaefer looks up what handle actually means and it fits perfectly here