[02:27] <RAOF> Woot!
[02:28] <RAOF> Mir should be buildable in the PPA again!
[02:37] <duflu> RAOF: Awesome-tastic
[02:37] <duflu> !
[03:43] <duflu> RAOF: Do we need more Mesa rebuilding?... https://bugs.launchpad.net/mir/+bug/1169022
[03:46] <RAOF> duflu: You need the mir6 mesa building in the PPA as we speak.
[03:48] <duflu> RAOF: Kay,t a
[03:48] <duflu> ta
[04:15] <RAOF> duflu: Should be good to go now, unless you're on i386
[05:20] <duflu> RAOF: Confirmed all fixed
[05:21] <duflu> RAOF: Would it make sense to create a new series in the Mir project for Mesa, with milestones "mirN" etc?
[05:22] <duflu> Then we could say where Mesa problems are fixed
[05:23] <RAOF> \
[05:23] <RAOF> Maybe?
[05:23] <duflu> RAOF: How about I do it and we see if it makes visual sense?
[05:24] <RAOF> The problems that I'm aware of have been fixed pretty promptly, which makes documenting when they're fixed less useful.
[05:24] <duflu> RAOF: It's useful to clarify that "mir" bugs are not problems in lp:mir branch, or the trunk series
[05:24] <duflu> Leaving milestone blank is ambiguous so I'd like to fill it in
[05:25] <duflu> *clarify when
[05:26] <RAOF> Even when they're "fix released"?
[05:27] <duflu> RAOF: Yeah it looks too much like a mistake unless there's a milestone
[05:27] <duflu> RAOF: Where does the Mesa branch live?
[05:27] <RAOF> github.com/RAOF/mesa
[05:27] <duflu> Oh, umm, hmm
[05:38] <duflu> RAOF: Done. You don't have to do anything. It just helps me keep bugs tidy... https://launchpad.net/mir/mesa
[06:11] <duflu> RAOF: Thanks for all your Mesa fixing today. It's nice to have a working platform again :)
[06:11] <RAOF> Heh.
[06:11] <RAOF> Maybe we can have a fully-working XMir platform tomorrow!
[06:12] <duflu> When did it stop working?
[06:12]  * duflu hasn't looked in a while at xmir
[06:14] <RAOF> With the use-dma-buf change.
[08:32] <alan_g> alf_, duflu : Good morning.
[08:33] <duflu> alan_g, good afternoon
[08:33] <alan_g> I've just tried building trunk...
[08:33] <alan_g> Linking CXX executable ../../bin/mir
[08:33] <alan_g> /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/libEGL.so: undefined reference to `mir_egl_native_display_is_valid'
[08:33] <alan_g> What has changed?
[08:33] <duflu> alan_g: Fixed. Just update from the PPA
[08:33] <alan_g> duflu: thanks
[08:34] <duflu> alan_g, https://bugs.launchpad.net/bugs/1167828
[08:35] <alan_g> Anything interesting been happening?
[08:36] <alf_> alan_g: Hi! How was the conference?
[08:36] <alan_g> alf_: a lot of fun. (Except my talk was plagued by equipment failures.)
[08:37] <mlankhorst> morning
[08:38] <duflu> mlankhorst: Morning/afternoon
[08:38] <alan_g> mlankhorst: morning
[08:38] <alf_> alan_g: Nice (for the fun part) :)
[08:42] <alan_g> alf_: there were a few people that wished they could be employed to work on mir after my talk. (We can feel smug.)
[08:44] <alf_> alan_g: :) Does ACCU provide recordings of talks?
[08:45] <alan_g> Some are recorded (mine was - or at least it was supposed to be). They're not online yet.
[08:51] <duflu> The grass is always greener... and sometimes it really is
[08:53] <alan_g> Some grass is brown and some has blown away. ;)
[08:57] <duflu> Oh I just noticed... In the Android headers Google has dual licensed a few of them. There are separate copies with different licenses (GPL and Apache). Seems Google doesn't like LGPL either (like IBM)
[08:59] <alan_g> duflu: I don't like LGPL either - but it exists
[10:43] <kgunn> morin', welcome back alan_g !
[10:44] <alan_g> morning kgunn - how's it been going?
[13:34] <racarr> Morning
[13:34] <racarr> *cringe at light*
[13:34] <alan_g> racarr: afternoon
[13:35] <racarr> alan_g: Did you enjoy your talk and conference?
[13:36] <alan_g> racarr: I did. (Although having a mini-displayport/VGA adaptor break 15min before talk and my reserve/netbook crash during the talk didn't make it easy)
[13:40] <racarr> alan_g: XD  I think that happens everytime
[13:45] <alan_g> racarr: a first for me
[14:46] <alf_> alan_g: kdub: I am considering renaming Shell::shutdown() (and all other related shutdown methods) to ::unblock_clients(), since I need to use it while pausing/resuming. Objections?
[14:48] <racarr> Updates to ease-shell-configuration xkbcommon-mapper and rebuild-input-focus-selection
[14:48] <alan_g> alf_: no objection to renaming for more general use, but not convinced by your proposal. Don't we want to block clients while pausing?
[14:52] <alf_> alan_g: Yes. The plan is to stop the communicator when pausing, and restart it when resuming. My current approach is to stop() the io_service processing, so new connections/requests will block until we resume. However, for this to work I need to stop all the io_service threads, which poses the same problems with our shutdown sequence (a client may be blocked waiting for a buffer), hence I need to use the same mechanism for unblocking the client
[14:55] <alan_g> alf_: so the name "unblock_clients()" isn't quite the right one?
[14:57] <alan_g> alf_: is it more like "interrupt_blocked_calls()"
[14:59] <alf_> alan_g: It's step two of the process: 1. stop io_service 2. unblock pending blocked client requests and allow them to finish 3. wait for io_service threads to exit
[14:59] <alan_g> alf_: actually, could such calls be retried from within the frontend (leaving the client blocked)?
[15:00] <alan_g> Or am I getting too clever?
[15:00] <kdub> good morning!
[15:00] <kdub> welcome back alan_g
[15:00] <alan_g> Good afternoon
[15:01] <alan_g> kdub: thanks. Hope things went smoothly in my absence?
[15:03] <alan_g> alf_: or "force_blocked_calls_to_complete()"
[15:03] <alf_> alan_g: @retrying, For our current approach and needs, I think this would complicate the situation
[15:03] <kdub> alan_g, smoothly enough :)
[15:03]  * kdub wonders if the accu talks will be posted anywhere
[15:04]  * alan_g knows his was recorded, but it isn't posted yet
[15:04] <alf_> alan_g: All of the suggestions are much better than "shutdown", I don't have a favorite :)
[15:06] <alan_g> kdub: racarr - want to help alf_  find a good name? ^^
[15:06] <racarr> status: Refactoring interface between shell and InputDispatcherController to fix some things.
[15:06] <alf_> alan_g: kdub: Shell::unblock_clients(), Shell::interrupt_block_calls(), Shell::force_blocked_calls_to_complete(), Shell::unblock_client_requests(), Shell::force_block_client_requests_to_complete() ...
[15:06] <kdub> alan_g, cool! hopefully they'll pop up somewhere over the next month
[15:06] <kdub> alf_, alan_g still getting my bearings back about that problem :)
[15:07] <racarr> hmm
[15:07] <alf_> kdub: I just want to give Shell::shutdown() (and friends) a more general name because I need to use it also while pausing/resuming
[15:07] <alf_> racarr: ^^
[15:07] <racarr> Shell::suspend_clients ?
[15:07] <racarr> Session::suspend
[15:07] <racarr> etc
[15:08] <racarr> makes it sound disciplinary XD
[15:08] <alf_> racarr: I need to do the opposite of suspend :)
[15:09] <racarr> ohhhh
[15:09] <racarr> I see
[15:09] <racarr> hmm
[15:10] <alf_> status: investigating bugs, implementing proper communications management when pausing/resuming
[15:11] <alan_g> status: catching up on MPs that appeared over last week.
[15:11] <alan_g> force_requests_to_complete()
[15:12] <kdub> status, hopefully moving my mp forward, working to some bug fixes, maybe doing some android display logging this afternoon
[15:13] <alf_> alan_g: I like this, sold!
[15:14] <alan_g> \o/
[15:15] <alan_g> alf_: if we ever decide to support automatic retry we can have force_requests_to_retry()
[15:20] <alf_> alan_g: yes
[16:07]  * kdub wonders if there's anything i can do to ease the review of server-render-window... maybe a quick hangout with anyone who's reviewing?
[16:10] <racarr> kdub: I am not revieing yet but will join a hangout if there is one going on to discuss it
[16:53] <racarr> hit a nice stopping point so unless anyone wants to hangout or anything before
[16:54] <racarr> Europe umps off
[16:54] <racarr> I am going to go for a walk and get some sunshine :) already up for 4 hours.
[16:57] <kdub> sunshine? in san francisco in april?
[16:57] <racarr> It's beautiful!
[16:57] <racarr> Windy though
[16:57] <racarr> alan_g: We can talk about the server configuration if you want...I don't know. I'm not really seeing a hierarchy that can make it better for the class users
[16:58] <racarr> just that the current code is becoming a mess
[16:59] <alan_g> racarr: It's a bit close to EOD for me - my wife is calling. I'll try to come up with an approach before you wake up tomorrow.
[17:01] <racarr> Ok! See you tomorro
[17:01] <racarr> w
[17:05]  * alan_g wishes he wasn't first line support for a WindowsXP(Dutch) PC.
[17:32] <racarr> Back. and back to the InputDispatcher
[18:42] <kdub> rsalveti, whoo, raring phablet images!
[18:43] <rsalveti> kdub: yup, soon to be the official (hopefully later today/tomorrow)
[18:45] <kdub> bumping all the mir android scripts to raring then! :)
[18:55] <kdub> racarr, is xkbcommon-mapper good to go?
[19:22] <racarr> kdub: Yeah!
[19:22] <racarr> kdub: I just flipped it to approved
[19:22] <racarr> now you can type fun things like !@#$%^&()_+!
[19:26] <kdub> yay!
[20:12] <thomi> morning everyone
[20:13] <kdub> hello thomi
[20:14] <thomi> o/
[20:14] <thomi> any Mir/QE emergencies I should know about?
[20:23] <kdub> thomi, no emergencies i know of, i sent a funny failure that might be of interest on my friday
[20:24] <thomi> kdub: I saw that, thanks. I haven't seen it again, so I assume it was some network issue in the QA lab
[20:24] <kdub> yeah, thats all it looked like to me as well
[20:39] <thomi> better mir benchmark graphs are up - still need that mesa bug fixed before they show anything useful though: http://people.canonical.com/~thomir/
[20:40] <thomi> there was a bug in the graph generation script - pyplot doesn't automatically order your x axis in date order :-/
[21:32] <kdub> hey racarr, does this quick mp look good to you? https://code.launchpad.net/~brandontschaefer/mir/replace-deprecated-auto-ptr/+merge/158994
[23:59] <racarr> ugh I finished my
[23:59] <racarr> rework of the DispatcherController
[23:59] <racarr> and am happy with how the code came together, but somehow...something is going wrong on the integration test driving it all :(