RAOFMir should be buildable in the PPA again!02:28
dufluRAOF: Awesome-tastic02:37
dufluRAOF: Do we need more Mesa rebuilding?... https://bugs.launchpad.net/mir/+bug/116902203:43
ubot5Launchpad bug 1169022 in Mir "[regression] Mir cannot start any more (std::exception::what: Failed to initialize EGL display)" [Critical,New]03:43
RAOFduflu: You need the mir6 mesa building in the PPA as we speak.03:46
dufluRAOF: Kay,t a03:48
RAOFduflu: Should be good to go now, unless you're on i38604:15
dufluRAOF: Confirmed all fixed05:20
dufluRAOF: Would it make sense to create a new series in the Mir project for Mesa, with milestones "mirN" etc?05:21
dufluThen we could say where Mesa problems are fixed05:22
dufluRAOF: How about I do it and we see if it makes visual sense?05:23
RAOFThe problems that I'm aware of have been fixed pretty promptly, which makes documenting when they're fixed less useful.05:24
dufluRAOF: It's useful to clarify that "mir" bugs are not problems in lp:mir branch, or the trunk series05:24
dufluLeaving milestone blank is ambiguous so I'd like to fill it in05:24
duflu*clarify when05:25
RAOFEven when they're "fix released"?05:26
dufluRAOF: Yeah it looks too much like a mistake unless there's a milestone05:27
dufluRAOF: Where does the Mesa branch live?05:27
dufluOh, umm, hmm05:27
dufluRAOF: Done. You don't have to do anything. It just helps me keep bugs tidy... https://launchpad.net/mir/mesa05:38
dufluRAOF: Thanks for all your Mesa fixing today. It's nice to have a working platform again :)06:11
RAOFMaybe we can have a fully-working XMir platform tomorrow!06:11
dufluWhen did it stop working?06:12
* duflu hasn't looked in a while at xmir06:12
RAOFWith the use-dma-buf change.06:14
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== duflu_ is now known as duflu
alan_galf_, duflu : Good morning.08:32
duflualan_g, good afternoon08:33
alan_gI've just tried building trunk...08:33
alan_gLinking CXX executable ../../bin/mir08: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_gWhat has changed?08:33
duflualan_g: Fixed. Just update from the PPA08:33
alan_gduflu: thanks08:33
duflualan_g, https://bugs.launchpad.net/bugs/116782808:34
ubot5Launchpad bug 1167828 in Mir "lp:mir r582 FTBFS on fully updated raring (mir staging 0.0.2bzr580raring0)" [Critical,Fix released]08:34
alan_gAnything interesting been happening?08:35
alf_alan_g: Hi! How was the conference?08:36
alan_galf_: a lot of fun. (Except my talk was plagued by equipment failures.)08:36
duflumlankhorst: Morning/afternoon08:38
alan_gmlankhorst: morning08:38
alf_alan_g: Nice (for the fun part) :)08:38
alan_galf_: there were a few people that wished they could be employed to work on mir after my talk. (We can feel smug.)08:42
alf_alan_g: :) Does ACCU provide recordings of talks?08:44
alan_gSome are recorded (mine was - or at least it was supposed to be). They're not online yet.08:45
dufluThe grass is always greener... and sometimes it really is08:51
alan_gSome grass is brown and some has blown away. ;)08:53
dufluOh 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:57
alan_gduflu: I don't like LGPL either - but it exists08:59
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
kgunnmorin', welcome back alan_g !10:43
alan_gmorning kgunn - how's it been going?10:44
=== 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
racarr*cringe at light*13:34
alan_gracarr: afternoon13:34
racarralan_g: Did you enjoy your talk and conference?13:35
alan_gracarr: 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:36
racarralan_g: XD  I think that happens everytime13:40
alan_gracarr: a first for me13:45
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
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:46
racarrUpdates to ease-shell-configuration xkbcommon-mapper and rebuild-input-focus-selection14:48
alan_galf_: no objection to renaming for more general use, but not convinced by your proposal. Don't we want to block clients while pausing?14:48
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 client14:52
alan_galf_: so the name "unblock_clients()" isn't quite the right one?14:55
alan_galf_: is it more like "interrupt_blocked_calls()"14:57
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 exit14:59
alan_galf_: actually, could such calls be retried from within the frontend (leaving the client blocked)?14:59
alan_gOr am I getting too clever?15:00
kdubgood morning!15:00
kdubwelcome back alan_g15:00
alan_gGood afternoon15:00
alan_gkdub: thanks. Hope things went smoothly in my absence?15:01
alan_galf_: or "force_blocked_calls_to_complete()"15:03
alf_alan_g: @retrying, For our current approach and needs, I think this would complicate the situation15:03
kdubalan_g, smoothly enough :)15:03
* kdub wonders if the accu talks will be posted anywhere15:03
* alan_g knows his was recorded, but it isn't posted yet15:04
alf_alan_g: All of the suggestions are much better than "shutdown", I don't have a favorite :)15:04
alan_gkdub: racarr - want to help alf_  find a good name? ^^15:06
racarrstatus: 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
kdubalan_g, cool! hopefully they'll pop up somewhere over the next month15:06
kdubalf_, alan_g still getting my bearings back about that problem :)15:06
alf_kdub: I just want to give Shell::shutdown() (and friends) a more general name because I need to use it also while pausing/resuming15:07
alf_racarr: ^^15:07
racarrShell::suspend_clients ?15:07
racarrmakes it sound disciplinary XD15:08
alf_racarr: I need to do the opposite of suspend :)15:08
racarrI see15:09
alf_status: investigating bugs, implementing proper communications management when pausing/resuming15:10
alan_gstatus: catching up on MPs that appeared over last week.15:11
kdubstatus, hopefully moving my mp forward, working to some bug fixes, maybe doing some android display logging this afternoon15:12
alf_alan_g: I like this, sold!15:13
alan_galf_: if we ever decide to support automatic retry we can have force_requests_to_retry()15:15
alf_alan_g: yes15:20
* 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:07
racarrkdub: I am not revieing yet but will join a hangout if there is one going on to discuss it16:10
racarrhit a nice stopping point so unless anyone wants to hangout or anything before16:53
racarrEurope umps off16:54
racarrI am going to go for a walk and get some sunshine :) already up for 4 hours.16:54
kdubsunshine? in san francisco in april?16:57
racarrIt's beautiful!16:57
racarrWindy though16:57
racarralan_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 users16:57
racarrjust that the current code is becoming a mess16:58
alan_gracarr: 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.16:59
racarrOk! See you tomorro17:01
* alan_g wishes he wasn't first line support for a WindowsXP(Dutch) PC.17:05
=== alan_g is now known as alan_g|EOD
racarrBack. and back to the InputDispatcher17:32
kdubrsalveti, whoo, raring phablet images!18:42
rsalvetikdub: yup, soon to be the official (hopefully later today/tomorrow)18:43
kdubbumping all the mir android scripts to raring then! :)18:45
kdubracarr, is xkbcommon-mapper good to go?18:55
racarrkdub: Yeah!19:22
racarrkdub: I just flipped it to approved19:22
racarrnow you can type fun things like !@#$%^&()_+!19:22
thomimorning everyone20:12
kdubhello thomi20:13
thomiany Mir/QE emergencies I should know about?20:14
kdubthomi, no emergencies i know of, i sent a funny failure that might be of interest on my friday20:23
thomikdub: I saw that, thanks. I haven't seen it again, so I assume it was some network issue in the QA lab20:24
kdubyeah, thats all it looked like to me as well20:24
thomibetter mir benchmark graphs are up - still need that mesa bug fixed before they show anything useful though: http://people.canonical.com/~thomir/20:39
thomithere was a bug in the graph generation script - pyplot doesn't automatically order your x axis in date order :-/20:40
kdubhey racarr, does this quick mp look good to you? https://code.launchpad.net/~brandontschaefer/mir/replace-deprecated-auto-ptr/+merge/15899421:32
racarrugh I finished my23:59
racarrrework of the DispatcherController23:59
racarrand am happy with how the code came together, but somehow...something is going wrong on the integration test driving it all :(23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!