[01:25] 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] duflu: ok [02:30] Oh. Maybe *that's* why. [02:30] 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] I was just wondering why I can't get racarr's enable-inprocess-egl branch to work with more sensible mesa changes. [02:59] It was calling mir_egl_native_display_is_valid(), and mysteriously getting "false" for the answer. [03:01] * duflu nods cluelessly [03:48] BAH! mir_demo_inprocess_egl is a Mir compositor itself. Of course it is. [03:48] In related news: we *really* suck at useful error messages :) [03:49] thomi: How's github mesa autopublishing coming? [03:50] RAOF: hmmm, good point - last I heard Martin said "leave it with me". then he had a baby [03:50] well, not *martin*, so much as his wife, I guess [03:51] That would have been even bigger news :) [03:51] either way, I somehow doubt he's going to look at it in the next few days. [03:51] I'll make a note to ping Larry tomorrow - we just need network access added for the jenkins instance, shouldn't be a biggie === mmrazik is now known as mmrazik|afk [06:03] huh [06:03] so can someone explain to me how chromium can use 2GB of memory in the space of an hour ? [06:04] everything is getting oom-killed ... this is stupiud [06:04] *stupid [06:04] * smspillaz reboots [06:07] Hm. grep /**/*.* is unlikely to return anything useful in a short period :) [06:12] smspillaz: Assuming it is real memory and not just address space bloat, it's likely some web page/script you had open [06:12] duflu: google docs [06:13] :( [06:13] 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] it'd be kinda awesome to have docs without the massive overhead that comes from js [06:16] 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] Launchpad bug 1165732 in gcc-4.7 (Ubuntu) "GCC 4.7.3 internal compiler error when using std::make_shared" [Undecided,Confirmed] [06:16] I was wondering why I periodically got them when working on compiz with boost::make_shared [06:16] smspillaz: I've also got a bug filed about that, but I'm not sure that it's as well-specified. [06:16] RAOF: ah, I knew you'd beaten us to it [06:17] RAOF: bug link? we can mark it as a dupe [06:17] (the one tvoss filed at least) [06:17] RAOF, smspillaz there is a comment on the bug report saying that it works fine with gcc 4.6 and 4.8 [06:17] tvoss: this is usually the case :) [06:17] Also, clang :) [06:17] they will still backport the fix if you ask [06:17] RAOF, yup :) [06:18] also, hi [06:18] RAOF, didn't know that you tracked down the multitude of ice bugs :) should have asked :) [06:18] Hey smspillaz! [06:18] tvoss: I didn't so much track it down as get annoyed enough to hit "submit" on one of the apport popups :) [06:18] RAOF, ;) [06:19] RAOF, same here [06:20] 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] *ICE [06:20] 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] https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1156457 is my go at the ICE bug. [06:24] Launchpad bug 1156457 in gcc-4.7 (Ubuntu) "Invalid google mock code causes ICE" [Undecided,New] [07:08] * tvoss loves variadic templates [07:19] tvoss: Scary. What for? std::function/bind? [07:19] duflu, compile-time signature generation for dbus messages :) [07:31] Free karma: https://code.launchpad.net/~vanvugt/mir/generalize-event/+merge/157310 [07:31] I actually have a couple of branches depending on it already :P === alan_g is now known as alan_g|afk [07:53] duflu: Enjoy. [07:53] 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] intel* [07:58] RAOF: Thanks. I just can't see it right now. Having excessive LP timeouts today [07:58] Ranomier_: The last four posts of http://blog.cooperteam.net/?view=magazine have some details. === alan_g|afk is now known as alan_g [08:20] Im not shure, it is right that u becoming the rights of my code if im developing on mir. [08:21] sry -becoming +get [08:22] 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] 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] Authors do keep their own copyrights, so long as they're adding new features, right? [08:23] Authors always keep their own copyrights, regardless of what they're doing. [08:23] RAOF: ... unless you work for a company that owns your copyrights. ;) [08:24] Well, yeah. [08:24] You keep your own copyrights, unless you have signed them away in a contract [08:24] But then the company is essentially the author, and *they* keep their own copyrights :) [08:25] 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] Correct. [08:25] ... 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] *As long as you can swap out the Mir libraries that you're using. [08:26] Which ironically are much more terse licenses [08:26] I don't know how weak LGPL is in practice, but in theory it's significantly stronger than MIT/X11/BSD. [08:27] I've had this argument, for years on end. I just did what the lawyers told me [08:27] That doesn't mean they're definitely right [08:28] I'm using MIT elsewhere; it's kinda required for anything that you want to be useful on mobile. [08:28] 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] Ah, right. [08:29] I forget the exact reasons why. Weird given that's the point of LGPL [08:29] Yeah, that wouldn't surprise me. [08:29] Because it's like 20,000 words of licence? :) [08:29] Yeah, more words lead to more ambiguous clauses [08:33] It takes a special kind of person to enjoy law ;) === mmrazik is now known as mmrazik|afk [10:32] katie, ping === alan_g is now known as alan_g|tea [10:43] tvoss, am just in a meeting [10:46] katie, can you ping me after that? === alan_g|tea is now known as alan_g [10:47] tvoss, sure [10:48] * duflu goes to organise dinner [10:50] katie, thx [11:39] tvoss, ping [11:40] katie, pong :) my question is answered with your reply to the edge thread [11:40] tvoss.. great, i hoped that would be what you were looking for [11:40] katie, yup :) [12:02] alan_g: Any more thoughts on display-server-main-loop? [12:05] alf_: was just looking at that again [12:06] alan_g: ok === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === alan_g is now known as alan_g|tea [14:51] Greetings. [15:04] goood moring [15:11] kdub: goood eveing [15:11] status: iterating main loop proposal [15:14] status, iterating on the fbnative window.... hooking hwc into the framebuffer posting === alan_g|tea is now known as alan_g [16:14] Morning [16:18] Evening [16:27] status: Working more on xkbcommon stuff, I got a prototype going by doing the mapping in Qt [16:28] I think...it might be time to remove droidinput::InputEvent though? [16:37] alan_g: updated display-server-main-loop MP [16:37] alf_: looking [16:58] alan_g: updated (but waiting for diff to update too...) [16:58] alf_: ack [16:58] alan_g: btw I merged trunk on enable-inprocess-egl if you can remove your needs fixing [16:58] so I can land it with raof and kdub later [16:59] racarr: ack [17:01] racarr: does the example still crash? :) [17:01] racarr: (when shutting down) [17:02] alf_: Oh I guess. [17:02] Ill look at that before RAOF shows up [17:03] Right now I think I convinced myself tht I can remove droidinput::InputEvent [17:03] so I am going to do that before I get nervous about it again and forget how to do it === alan_g is now known as alan_g|life [17:18] Easy https://code.launchpad.net/~robertcarr/mir/reorganize-shared-input-code/+merge/157702 :) [18:25] More refactoring pulled out of this droidinput::InputEvent removal branch https://code.launchpad.net/~robertcarr/mir/remove-dummy-dispatcher-policy/+merge/157716 [18:51] 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] I'm reading wayland specs right now, and soon I'll be reading yours. [19:19] I've been proponent of both before, because I think choice is good. [19:34] I get the feeling you've evaluated the wayland worse than I have [19:35] that allows input event handling to be extended for more advanced devices. [19:37] also making the shell a client app is okay. [19:37] probably.. [19:59] morning [20:02] Morning thomi [21:08] robert_ancell: hey, was chatting with tedg earlier today around how we roll out mir/unity next...when things become default etc [21:09] robert_ancell: i was thinking mir/unitynext are sort of lockstep [21:09] 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] robert_ancell: he was wondering about using mir as a system compositor [21:10] robert_ancell: cool...you beat me to it :) [21:10] robert_ancell: i'll note those slides about our road to convergence [21:10] 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] though unofficially you can probably run the system compositor before then for testing/being ahead of the curve [21:11] 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] fearing a frankenstein switch in 14.04... [21:13] 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] ideally I could do: "mir --run-on-terminal 2" :) [21:13] thomi, no, it's not VT aware so it just runs on the VT you started it on [21:14] kgunn, frankenstein or big switch? [21:15] robert_ancell: right...big switch...fearing lack of test/confidence [21:16] 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] 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] robert_ancell: my gut says the latter [21:16] me too [21:17] 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] robert_ancell: true...but in reality the "maintenance" of current unity is _extremely_ manageable...if you catch my drift ;) [21:19] kgunn, :) === francisco is now known as Guest87879 [21:53] RAOF: good news: mesa autolanding is back in action. [22:57] [ OK ] TestClientInput.clients_receive_us_english_mapped_keys (15 ms) [22:57] Whee [23:01] racarr: Woo! [23:01] thomi: Ta. [23:02] racarr: how come it takes 15ms? [23:02] RAOF: we should get notifications next time that job fails on Canonical IRC server [23:03] thomi: Eh. it doesn't always take that long but [23:04] it starts up a server and a client process and sends a few events and has some synchronization points [23:04] acceptance test [23:04] racarr: ahh, ok, not a unit test, that's just fine then :) [23:05] Sam has just asked whether it's too early for coffee. Heresy! [23:06] it's never too early for coffee [23:06] Correct!