[01:25] <duflu> thomi: That glmark2 build failure... Don't fix it yet. I suspect the bigger problem is the API change, which I would like to revisit in Mir
[01:42] <thomi> duflu: ok
[02:30] <RAOF> Oh. Maybe *that's* why.
[02:30] <RAOF> Adding a new mir_egl_mesa_display_is_valid() without removing mir_egl_native_display_is_valid() seems a bit hostile :)
[02:58]  * duflu wonders if he's meant to understand RAOF's comment
[02:59] <RAOF> I was just wondering why I can't get racarr's enable-inprocess-egl branch to work with more sensible mesa changes.
[02:59] <RAOF> It was calling mir_egl_native_display_is_valid(), and mysteriously getting "false" for the answer.
[03:01]  * duflu nods cluelessly
[03:48] <RAOF> BAH! mir_demo_inprocess_egl is a Mir compositor itself. Of course it is.
[03:48] <RAOF> In related news: we *really* suck at useful error messages :)
[03:49] <RAOF> thomi: How's github mesa autopublishing coming?
[03:50] <thomi> RAOF: hmmm, good point - last I heard Martin said "leave it with me". then he had a baby
[03:50] <thomi> well, not *martin*, so much as his wife, I guess
[03:51] <RAOF> That would have been even bigger news :)
[03:51] <thomi> either way, I somehow doubt he's going to look at it in the next few days.
[03:51] <thomi> I'll make a note to ping Larry tomorrow - we just need network access added for the jenkins instance, shouldn't be a biggie
[06:03] <smspillaz> huh
[06:03] <smspillaz> so can someone explain to me how chromium can use 2GB of memory in the space of an hour ?
[06:04] <smspillaz> everything is getting oom-killed ... this is stupiud
[06:04] <smspillaz> *stupid
[06:04]  * smspillaz reboots
[06:07] <RAOF> Hm. grep /**/*.* is unlikely to return anything useful in a short period :)
[06:12] <duflu> smspillaz: Assuming it is real memory and not just address space bloat, it's likely some web page/script you had open
[06:12] <smspillaz> duflu: google docs
[06:13] <smspillaz> :(
[06:13] <smspillaz> I'd like to see what Google does with docs given that they've forked webkit and want to focus on delivering NaCl
[06:14] <smspillaz> it'd be kinda awesome to have docs without the massive overhead that comes from js
[06:16] <smspillaz> duflu: also, something tvoss and I figured out yesterday that's worth watching out for https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1165732
[06:16] <smspillaz> I was wondering why I periodically got them when working on compiz with boost::make_shared
[06:16] <RAOF> smspillaz: I've also got a bug filed about that, but I'm not sure that it's as well-specified.
[06:16] <smspillaz> RAOF: ah, I knew you'd beaten us to it
[06:17] <smspillaz> RAOF: bug link? we can mark it as a dupe
[06:17] <smspillaz> (the one tvoss filed at least)
[06:17] <tvoss> RAOF, smspillaz there is a comment on the bug report saying that it works fine with gcc 4.6 and 4.8
[06:17] <smspillaz> tvoss: this is usually the case :)
[06:17] <RAOF> Also, clang :)
[06:17] <smspillaz> they will still backport the fix if you ask
[06:17] <tvoss> RAOF, yup :)
[06:18] <smspillaz> also, hi
[06:18] <tvoss> RAOF, didn't know that you tracked down the multitude of ice bugs :) should have asked :)
[06:18] <RAOF> Hey smspillaz!
[06:18] <RAOF> tvoss: I didn't so much track it down as get annoyed enough to hit "submit" on one of the apport popups :)
[06:18] <tvoss> RAOF, ;)
[06:19] <tvoss> RAOF, same here
[06:20] <smspillaz> it'd be nice if gcc would print a trace of which line it was trying to compile when it hit an IRC
[06:20] <smspillaz> *ICE
[06:20] <smspillaz> I had the same problem when I was working on the compizconfig test suite some time ago, and it was a matter of blindly trying different designs until I didn't hit the bug anymore
[06:23] <RAOF> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1156457 is my go at the ICE bug.
[07:08]  * tvoss loves variadic templates
[07:19] <duflu> tvoss: Scary. What for? std::function/bind?
[07:19] <tvoss> duflu, compile-time signature generation for dbus messages :)
[07:31] <duflu> Free karma: https://code.launchpad.net/~vanvugt/mir/generalize-event/+merge/157310
[07:31] <duflu> I actually have a couple of branches depending on it already :P
[07:53] <RAOF> duflu: Enjoy.
[07:53] <Ranomier_> Hey whats wrong with it to write mir as a wayland client and work with wayland upstream, to release wayland2 wich is compatible with the  proprietary amd inten and nvidia driver?
[07:53] <Ranomier_> intel*
[07:58] <duflu> RAOF: Thanks. I just can't see it right now. Having excessive LP timeouts today
[07:58] <RAOF> Ranomier_: The last four posts of http://blog.cooperteam.net/?view=magazine have some details.
[08:20] <Ranomier_> Im not shure, it is right that u becoming the rights of my code if im developing on mir.
[08:21] <Ranomier_> sry -becoming +get
[08:22] <duflu> Ranomier_: Mir's libraries are meant to be LGPL so that you do not have to release the source to your code. Any library headers that mention GPL are a mistake and need to be fixed (changed to LGPL)
[08:22] <RAOF> Ranomier_: You need to sign the contributor agreement for us to accept patches to Mir, yes. That's not taking the rights to your code; it's essentially getting you to contribute patches under a MIT/X11/BSD-like license.
[08:23] <duflu> Authors do keep their own copyrights, so long as they're adding new features, right?
[08:23] <RAOF> Authors always keep their own copyrights, regardless of what they're doing.
[08:23] <duflu> RAOF: ... unless you work for a company that owns your copyrights. ;)
[08:24] <RAOF> Well, yeah.
[08:24] <duflu> You keep your own copyrights, unless you have signed them away in a contract
[08:24] <RAOF> But then the company is essentially the author, and *they* keep their own copyrights :)
[08:25] <duflu> And if you're a consumer (not contributor) of Mir, then LGPL means you are not required to give away your source. You can keep it private.
[08:25] <RAOF> Correct.
[08:25] <duflu> ... although if you ask IBM's lawyers they will tell you LGPL is very weak and you should always use MIT/X11/BSD instead
[08:26] <RAOF> *As long as you can swap out the Mir libraries that you're using.
[08:26] <duflu> Which ironically are much more terse licenses
[08:26] <RAOF> I don't know how weak LGPL is in practice, but in theory it's significantly stronger than MIT/X11/BSD.
[08:27] <duflu> I've had this argument, for years on end. I just did what the lawyers told me
[08:27] <duflu> That doesn't mean they're definitely right
[08:28] <RAOF> I'm using MIT elsewhere; it's kinda required for anything that you want to be useful on mobile.
[08:28] <duflu> RAOF: I mean the other way round -- it is high risk to use LGPL is proprietary code, because you're not necessarily fully protected in being able to conceal your own IP
[08:28] <RAOF> Ah, right.
[08:29] <duflu> I forget the exact reasons why. Weird given that's the point of LGPL
[08:29] <RAOF> Yeah, that wouldn't surprise me.
[08:29] <RAOF> Because it's like 20,000 words of licence? :)
[08:29] <duflu> Yeah, more words lead to more ambiguous clauses
[08:33] <duflu> It takes a special kind of person to enjoy law ;)
[10:32] <tvoss> katie, ping
[10:43] <katie> tvoss, am just in a meeting
[10:46] <tvoss> katie, can you ping me after that?
[10:47] <katie> tvoss, sure
[10:48]  * duflu goes to organise dinner
[10:50] <tvoss> katie, thx
[11:39] <katie> tvoss, ping
[11:40] <tvoss> katie, pong :) my question is answered with your reply to the edge thread
[11:40] <katie> tvoss.. great, i hoped that would be what you were looking for
[11:40] <tvoss> katie, yup :)
[12:02] <alf_> alan_g: Any more thoughts on display-server-main-loop?
[12:05] <alan_g> alf_: was just looking at that again
[12:06] <alf_> alan_g: ok
[14:51] <BigWhale> Greetings.
[15:04] <kdub> goood moring
[15:11] <alf_> kdub: goood eveing
[15:11] <alf_> status: iterating main loop proposal
[15:14] <kdub> status, iterating on the fbnative window....  hooking hwc into the framebuffer posting
[16:14] <racarr> Morning
[16:18] <alan_g> Evening
[16:27] <racarr> status: Working more on xkbcommon stuff, I got a prototype going by doing the mapping in Qt
[16:28] <racarr> I think...it might be time to remove droidinput::InputEvent though?
[16:37] <alf_> alan_g: updated display-server-main-loop MP
[16:37] <alan_g> alf_: looking
[16:58] <alf_> alan_g: updated (but waiting for diff to update too...)
[16:58] <alan_g> alf_: ack
[16:58] <racarr> alan_g: btw I merged trunk on enable-inprocess-egl if you can remove your needs fixing
[16:58] <racarr> so I can land it with raof and kdub later
[16:59] <alan_g> racarr: ack
[17:01] <alf_> racarr: does the example still crash? :)
[17:01] <alf_> racarr: (when shutting down)
[17:02] <racarr> alf_: Oh I guess.
[17:02] <racarr> Ill look at that before RAOF shows up
[17:03] <racarr> Right now I think I convinced myself tht I can remove droidinput::InputEvent
[17:03] <racarr> so I am going to do that before I get nervous about it again and forget how to do it
[17:18] <racarr> Easy https://code.launchpad.net/~robertcarr/mir/reorganize-shared-input-code/+merge/157702 :)
[18:25] <racarr> More refactoring pulled out of this droidinput::InputEvent removal branch https://code.launchpad.net/~robertcarr/mir/remove-dummy-dispatcher-policy/+merge/157716
[18:51] <BigWhale> Is there an update to Mir Hacking guide? Apparently I am missing some dependencies or I need to set some environment variables set:  EGL_LIBRARY EGL_INCLUDE_DIR
[19:18] <Cheery> I'm reading wayland specs right now, and soon I'll be reading yours.
[19:19] <Cheery> I've been proponent of both before, because I think choice is good.
[19:34] <Cheery> I get the feeling you've evaluated the wayland worse than I have
[19:35] <Cheery> that allows input event handling to be extended for more advanced devices.
[19:37] <Cheery> also making the shell a client app is okay.
[19:37] <Cheery> probably..
[19:59] <thomi> morning
[20:02] <racarr> Morning thomi
[21:08] <kgunn> robert_ancell: hey, was chatting with tedg earlier today around how we roll out mir/unity next...when things become default etc
[21:09] <kgunn> robert_ancell: i was thinking mir/unitynext are sort of lockstep
[21:09] <robert_ancell> kgunn, yes, except for the system compositor which we can roll out before unity next. However if we're focussing on the phone then they are lockstep
[21:09] <kgunn> robert_ancell: he was wondering about using mir as a system compositor
[21:10] <kgunn> robert_ancell: cool...you beat me to it :)
[21:10] <kgunn> robert_ancell: i'll note those slides about our road to convergence
[21:10] <robert_ancell> kgunn, my guess is if we'll end up doing the phone first so when we roll to desktop we might as well do both at once
[21:11] <robert_ancell> though unofficially you can probably run the system compositor before then for testing/being ahead of the curve
[21:11] <kgunn> robert_ancell: he was bringing this up in the context that the desktop guys would probably want as much to be default in 13.10
[21:12] <kgunn> fearing a frankenstein switch in 14.04...
[21:13] <thomi> folks: is there any way I can run the mir server on terminal X without having to start it from that terminal? I'm still struggling to get the mir benchmark stuff going from jenkins
[21:13] <thomi> ideally I could do: "mir --run-on-terminal 2" :)
[21:13] <robert_ancell> thomi, no, it's not VT aware so it just runs on the VT you started it on
[21:14] <robert_ancell> kgunn, frankenstein or big switch?
[21:15] <kgunn> robert_ancell: right...big switch...fearing lack of test/confidence
[21:16] <kgunn> but i would think we could just slowing make things default on s-series towards convergence/14.04....and viola...you get testing feedback
[21:16] <robert_ancell> kgunn, yes, not sure the safest strategy here. We either go fully in for both phone and desktop or we bring the phone code across when we're ready with it
[21:16] <kgunn> robert_ancell: my gut says the latter
[21:16] <robert_ancell> me too
[21:17] <robert_ancell> kgunn, though any slowing on desktop means putting the cost on the shell team to maintain the current unity. Easier decision to make from a Mir perspective than from theirs
[21:18] <kgunn> robert_ancell: true...but in reality the "maintenance" of current unity is _extremely_ manageable...if you catch my drift ;)
[21:19] <robert_ancell> kgunn, :)
[21:53] <thomi> RAOF: good news: mesa autolanding is back in action.
[22:57] <racarr> [       OK ] TestClientInput.clients_receive_us_english_mapped_keys (15 ms)
[22:57] <racarr> Whee
[23:01] <RAOF> racarr: Woo!
[23:01] <RAOF> thomi: Ta.
[23:02] <thomi> racarr: how come it takes 15ms?
[23:02] <thomi> RAOF: we should get notifications next time that job fails on Canonical IRC server
[23:03] <racarr> thomi: Eh. it doesn't always take that long but
[23:04] <racarr> it starts up a server and a client process and sends a few events and has some synchronization points
[23:04] <racarr> acceptance test
[23:04] <thomi> racarr: ahh, ok, not a unit test, that's just fine then :)
[23:05] <RAOF> Sam has just asked whether it's too early for coffee. Heresy!
[23:06] <thomi> it's never too early for coffee
[23:06] <RAOF> Correct!