[02:27] Woot! [02:28] Mir should be buildable in the PPA again! [02:37] RAOF: Awesome-tastic [02:37] ! [03:43] RAOF: Do we need more Mesa rebuilding?... https://bugs.launchpad.net/mir/+bug/1169022 [03:43] Launchpad bug 1169022 in Mir "[regression] Mir cannot start any more (std::exception::what: Failed to initialize EGL display)" [Critical,New] [03:46] duflu: You need the mir6 mesa building in the PPA as we speak. [03:48] RAOF: Kay,t a [03:48] ta [04:15] duflu: Should be good to go now, unless you're on i386 [05:20] RAOF: Confirmed all fixed [05:21] RAOF: Would it make sense to create a new series in the Mir project for Mesa, with milestones "mirN" etc? [05:22] Then we could say where Mesa problems are fixed [05:23] \ [05:23] Maybe? [05:23] RAOF: How about I do it and we see if it makes visual sense? [05:24] The problems that I'm aware of have been fixed pretty promptly, which makes documenting when they're fixed less useful. [05:24] RAOF: It's useful to clarify that "mir" bugs are not problems in lp:mir branch, or the trunk series [05:24] Leaving milestone blank is ambiguous so I'd like to fill it in [05:25] *clarify when [05:26] Even when they're "fix released"? [05:27] RAOF: Yeah it looks too much like a mistake unless there's a milestone [05:27] RAOF: Where does the Mesa branch live? [05:27] github.com/RAOF/mesa [05:27] Oh, umm, hmm [05:38] RAOF: Done. You don't have to do anything. It just helps me keep bugs tidy... https://launchpad.net/mir/mesa [06:11] RAOF: Thanks for all your Mesa fixing today. It's nice to have a working platform again :) [06:11] Heh. [06:11] Maybe we can have a fully-working XMir platform tomorrow! [06:12] When did it stop working? [06:12] * duflu hasn't looked in a while at xmir [06:14] With the use-dma-buf change. === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss === duflu_ is now known as duflu [08:32] alf_, duflu : Good morning. [08:33] alan_g, good afternoon [08:33] I've just tried building trunk... [08:33] Linking CXX executable ../../bin/mir [08:33] /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/libEGL.so: undefined reference to `mir_egl_native_display_is_valid' [08:33] What has changed? [08:33] alan_g: Fixed. Just update from the PPA [08:33] duflu: thanks [08:34] alan_g, https://bugs.launchpad.net/bugs/1167828 [08:34] Launchpad bug 1167828 in Mir "lp:mir r582 FTBFS on fully updated raring (mir staging 0.0.2bzr580raring0)" [Critical,Fix released] [08:35] Anything interesting been happening? [08:36] alan_g: Hi! How was the conference? [08:36] alf_: a lot of fun. (Except my talk was plagued by equipment failures.) [08:37] morning [08:38] mlankhorst: Morning/afternoon [08:38] mlankhorst: morning [08:38] alan_g: Nice (for the fun part) :) [08:42] 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] alan_g: :) Does ACCU provide recordings of talks? [08:45] Some are recorded (mine was - or at least it was supposed to be). They're not online yet. [08:51] The grass is always greener... and sometimes it really is [08:53] Some grass is brown and some has blown away. ;) [08:57] 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] duflu: I don't like LGPL either - but it exists === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [10:43] morin', welcome back alan_g ! [10:44] morning kgunn - how's it been going? === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === seb128_ is now known as seb128 === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [13:34] Morning [13:34] *cringe at light* [13:34] racarr: afternoon [13:35] alan_g: Did you enjoy your talk and conference? [13:36] 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] alan_g: XD I think that happens everytime [13:45] racarr: a first for me === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [14:46] 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] Updates to ease-shell-configuration xkbcommon-mapper and rebuild-input-focus-selection [14:48] 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] 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] alf_: so the name "unblock_clients()" isn't quite the right one? [14:57] alf_: is it more like "interrupt_blocked_calls()" [14:59] 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] alf_: actually, could such calls be retried from within the frontend (leaving the client blocked)? [15:00] Or am I getting too clever? [15:00] good morning! [15:00] welcome back alan_g [15:00] Good afternoon [15:01] kdub: thanks. Hope things went smoothly in my absence? [15:03] alf_: or "force_blocked_calls_to_complete()" [15:03] alan_g: @retrying, For our current approach and needs, I think this would complicate the situation [15:03] 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] alan_g: All of the suggestions are much better than "shutdown", I don't have a favorite :) [15:06] kdub: racarr - want to help alf_ find a good name? ^^ [15:06] status: Refactoring interface between shell and InputDispatcherController to fix some things. [15:06] 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] alan_g, cool! hopefully they'll pop up somewhere over the next month [15:06] alf_, alan_g still getting my bearings back about that problem :) [15:07] hmm [15:07] 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] racarr: ^^ [15:07] Shell::suspend_clients ? [15:07] Session::suspend [15:07] etc [15:08] makes it sound disciplinary XD [15:08] racarr: I need to do the opposite of suspend :) [15:09] ohhhh [15:09] I see [15:09] hmm [15:10] status: investigating bugs, implementing proper communications management when pausing/resuming [15:11] status: catching up on MPs that appeared over last week. [15:11] force_requests_to_complete() [15:12] status, hopefully moving my mp forward, working to some bug fixes, maybe doing some android display logging this afternoon [15:13] alan_g: I like this, sold! [15:14] \o/ [15:15] alf_: if we ever decide to support automatic retry we can have force_requests_to_retry() [15:20] 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] kdub: I am not revieing yet but will join a hangout if there is one going on to discuss it [16:53] hit a nice stopping point so unless anyone wants to hangout or anything before [16:54] Europe umps off [16:54] I am going to go for a walk and get some sunshine :) already up for 4 hours. [16:57] sunshine? in san francisco in april? [16:57] It's beautiful! [16:57] Windy though [16:57] 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] just that the current code is becoming a mess [16:59] 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] Ok! See you tomorro [17:01] w [17:05] * alan_g wishes he wasn't first line support for a WindowsXP(Dutch) PC. === alan_g is now known as alan_g|EOD [17:32] Back. and back to the InputDispatcher [18:42] rsalveti, whoo, raring phablet images! [18:43] kdub: yup, soon to be the official (hopefully later today/tomorrow) [18:45] bumping all the mir android scripts to raring then! :) [18:55] racarr, is xkbcommon-mapper good to go? [19:22] kdub: Yeah! [19:22] kdub: I just flipped it to approved [19:22] now you can type fun things like !@#$%^&()_+! [19:26] yay! [20:12] morning everyone [20:13] hello thomi [20:14] o/ [20:14] any Mir/QE emergencies I should know about? [20:23] thomi, no emergencies i know of, i sent a funny failure that might be of interest on my friday [20:24] 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] yeah, thats all it looked like to me as well [20:39] 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] there was a bug in the graph generation script - pyplot doesn't automatically order your x axis in date order :-/ [21:32] hey racarr, does this quick mp look good to you? https://code.launchpad.net/~brandontschaefer/mir/replace-deprecated-auto-ptr/+merge/158994 [23:59] ugh I finished my [23:59] rework of the DispatcherController [23:59] and am happy with how the code came together, but somehow...something is going wrong on the integration test driving it all :(