[06:34] <duflu> anpok, anyone: Please look at reviewing this ASAP. It's going to block everything and everyone... https://code.launchpad.net/~vanvugt/mir/fix-1369389/+merge/234613
[07:30] <anpok> duflu: that mako failure is unrelated?
[07:31] <anpok> ah ok no network on the ci-n4
[07:31] <duflu> anpok: Yep
[08:47] <alf_> duflu: thanks for finishing the 0.7.2 release (tarball etc)
[08:49] <duflu> alf_: Thanks OK. I like to tie loose ends
[08:49] <duflu> *That's OK
[08:50] <duflu> (automatic dyslexic fingers)
[12:39] <racarr> Morning
[12:52] <greyback_> hey folks, brendand managed to hang shell, this is all the backtrace he's managed to get so far: http://paste.ubuntu.com/8350204/
[12:53] <greyback_> it appears to be blocked at mir::scene::SurfaceEventSource::attrib_changed - does that make sense to anyone?
[12:55] <anpok> why is there only one readable mirserver symbol?
[12:57] <greyback_> anpok: no idea
[12:58] <greyback_> he's on RTM, and I can't source him a dbg symbol package
[12:58] <alf_> greyback_: is it reproducible?
[12:58] <greyback_> http://ddebs.ubuntu.com/ubuntu-rtm/pool/universe/m/mir/ is missing anything to do with mirserver
[12:58] <greyback_> alf_: not reliably afaik
[13:00] <alf_> greyback_: anpok: The only codepath that would block there at poll() is blocking while sending event to the client. Do we know if the client has somehow hung? (btw, https://code.launchpad.net/~afrantzis/mir/fix-1350207-unresponsive-clients/+merge/233934 should help if this is the case).
[13:00] <greyback_> alf_: I suspect the client has indeed hung
[13:01] <greyback_> alf_: ok I'd postulate your MR will indeed fix this
[13:03] <alf_> greyback_: in order for this to be the case, the client has to have hung for enough time for us to send enough surface related events (not input) to fill the socket send buffer. Can't be sure without more information.