[01:15] <duflu> RAOF: After my comment yesterday, I arrived to find a dead spider on the desk today :)
[02:09] <RAOF> duflu_: Ominous!
[04:41] <RAOF> Hm. How do you tell QtCreator to run a parallel make?
[06:34] <Mirv> duflu: did you see me and cyphermo_x's comments at bug #1252144? the test still seems to fail in the build environment of the daily-build PPA, plus it was spotted that after the patch it's a segfault, not a test fail
[06:34]  * duflu looks
[06:36] <duflu> Mirv: OK, thanks. The logs yesterday were hinting it wasn't a timeout anyway
[06:37] <duflu> I did run it against helgrind, but we've lagged behind in our helgrind testing and there's much noise
[06:38] <Mirv> what is strange to me in terms of reproducing is that I thought both PPA:s had similar kind of non-virtualized builders, but apparently not
[06:53] <RAOF> Hm. I wonder how often acceptance-tests.ServerDisconect.* hangs...
[07:02] <duflu> No idea. It's not in the list (?) ... https://bugs.launchpad.net/mir/+bugs?field.tag=testsfail
[07:23]  * duflu was worried for a moment... 
[07:23] <duflu> [[07:24] <tvoss_> duflu, :)
[07:26] <duflu> That's fun. Our tests run faster if pinned to a single CPU core (taskset)
[07:29] <tvoss_> duflu, under valgrind? might well be
[07:30] <duflu> Yep
[08:17] <duflu> Mirv: OK I now have a good explanation of why just that test is failing, and have synthesized a similar failure + segfault. Another MP coming
[08:21] <alf_> duflu: \o/
[08:22] <didrocks> awesome! :)
[08:24] <alf_> duflu: didrocks: FWIW, I tried to reproduce the issue by ssh-ing and building the package in a devirtualized builder yesterday, but couldn't get the error...
[08:24] <duflu> Why valgrind can't see that uninitialized value, I don't know. But the C++11 docs seem to say it should and will be uninitialized. And it's surrounded by variables that are explicitly initialized
[08:25] <didrocks> alf_: argh, let's see duflu's explanation once he will get the MP up then… That was the only common sense diff between the 2 ppas I could have come up with
[08:27] <duflu> https://code.launchpad.net/~vanvugt/mir/fix-1252144-v2.trunk/+merge/195718
[08:30] <didrocks> it's interesting that it only happen in one ppa, and reliably there…
[08:30] <duflu> didrocks: Yes, something different about the default memory layout/contents. Possibly due to a different library or kernel
[08:31] <duflu> I notice the logs say it's failing on kernel 3.2
[08:32] <didrocks> oh, devirtualized should use a precise kernel
[08:32] <didrocks> juts weird that alf_ didn't reproduce
[08:37] <alf_> didrocks: hmm, the devirtualized builder I used has 2.6.32 (10.04)
[08:38] <didrocks> oh, maybe different ones ;)
[10:36] <alf_> greyback: Hi! Any luck with the EGL issues?
[10:38] <greyback> alf_: hey. No, I didn't get much further (sorry, forgot to send you mail). Setting EGL_PLATFORM manually helped a bit
[11:25] <tsdgeos> you guys that know much more *gl than me
[11:25] <tsdgeos> is EGL+regularOpenGL something that works on the desktop?
[11:32] <mlankhorst> no idea
[11:48] <xnox> tsdgeos: the question is weather hardware/drivers expose EGL, e.g. AMD drivers on the desktop do expose EGL, but no others.
[11:49] <xnox> http://www.g-truc.net/post-0457.html is a good read.
[13:30] <alf_> greyback: Can I just install qtubuntu etc on the desktop? It brings in hybris which usually messes up desktop EGL
[13:33] <greyback> alf_: the hybris dependency is actually build-time
[13:34] <alf_> greyback: however the qtubuntu-android binary package depends on hybris
[13:34] <greyback> alf_: but I don't think the package dependencies reflect that
[13:34] <greyback> right
[13:35] <greyback> easiest would be to check out lp:qtubuntu, install libhybris-dev, run "qmake CONFIG+=mirserver CONFIG+=mirclient CONFIG+=debug", make && make install
[13:36] <greyback> then remove libhybris
[13:36] <alf_> greyback: ok
[13:45] <kgunn> read scrollback, that's kinda scary that there are so many different kernels we're using on validation systems (...on desktop)
[13:45] <kgunn> isn't there supposed to be 1 kernel ver/cfg to be used (period)
[13:52] <alf_> greyback: reproduced problem, looking into it...
[13:53] <greyback> alf_: cool. Let me know if you need anything.
[13:59] <alf_> greyback: FYI, using "sudo update-alternatives --config x86_64-linux-gnu_egl_conf" and then "sudo ldconfig" allows us to select mesa even in the presence of libhybris
[14:00] <greyback> alf_: nice, thanks
[14:00] <greyback> info like this should really be in a wiki page somewhere
[14:21] <kgunn> didrocks: Mirv we all good with mir update now ?
[14:21] <didrocks> kgunn: there is a patch from duflu
[14:21] <didrocks> kgunn: but it seems the CI system doesn't want from it
[14:21] <kgunn> didrocks: crap...will go check
[14:21] <didrocks> kgunn: I asked kenvandine to start where Mirv left, but it's about pushing the CI guys to look/act on it
[14:22] <alan_g> kgunn: looks like fginther is on it
[14:22] <kgunn> thanks guys....if fginther is on it...i'll rest easy :)
[14:22] <Mirv> yeah francis now hopefully found the cause
[14:42]  * alan_g wishes for a C++11 aware mocking framework
[15:09] <olli> kdub, congrats for making it onto phoronix ;)
[15:59] <rsalveti> would be nice if we could have someone from the mir team also joining http://summit.ubuntu.com/uds-1311/meeting/22107/core-1311-early-boot-animation/
[15:59] <rsalveti> as that might bring back the discussion of having some part of mir already running in the initrd itself
[16:04] <kgunn> mterry: ^ could you join that one ?
[16:04] <mterry> kgunn, I'm in the encrypted home dir one
[16:04] <kgunn> mterry: np
[16:05] <kgunn> alan_g: ^ could you ?
[16:05] <alan_g> kgunn: I could - but have no idea what's happening
[16:06] <kgunn> alan_g: no prob...i think they just want some mir representation
[16:06] <alan_g> kgunn: what do I do? Just follow that link?
[16:06] <kgunn> alan_g: http://summit.ubuntu.com/uds-1311/meeting/22107/core-1311-early-boot-animation/
[16:07] <kdub> thanks olli
[16:08]  * alan_g tries to register...
[16:10] <alan_g> ..."wait a few minutes and reload this page."
[16:40] <kgunn> alf_: thanks for merging trunk back in....was just going to do that
[16:41] <alf_> kgunn: ? I didn't do anything, but I can do it if you like :)
[16:42] <kgunn> alf_: no you did.... 4 hrs ago :)
[16:43] <kgunn> oh wait...misread it...it was duflu i think
[16:45] <alf_> kgunn: yes, although it was not exactly a merge back, it was the same commit retargeted at devel
[16:45] <kgunn> right
[16:45] <kgunn> just didn't want it to not make it back to dev branch...all good
[16:47] <DieMumiee> hm i had no audio on the hangout video, do I need to register/login to hear the voices
[20:57] <mterry> jono, how would one edit http://unity.ubuntu.com/mir/using_mir_on_pc.html ?
[20:57] <mterry> Or point me maybe at who would know  :)
[20:58] <robotfuel> mterry: I that's part of the doc's in the source code.
[20:58] <mterry> robotfuel, interesting
[20:59] <jono> mterry, yep, it is in the source, and synced to unity.u.c
[20:59] <mterry> jono, robotfuel; thanks!
[20:59] <jono> np
[21:38] <kgunn> mterry: right, you mod the doc in the src tree and then it automagically updates on the web
[21:39] <kgunn> nvmd i see jono now said that :P
[22:07] <DieMumiee> i have issues setting up the build environment for mir. cmake/FindGtest.cmake declares that gtest.a is in <builddir>/gmock/libs/gtest/libgtest.a
[22:07] <DieMumiee> but it is never created there nor do I find a clue which cmake project creates it there
[22:09] <kdub> DieMumiee, not sure why... maybe you don't have gtest or gmock installed?
[22:10] <RAOF> I presume you've run ‘apt-get build-dep mir’?
[22:12] <DieMumiee> yes
[22:13] <DieMumiee> ah thats an issue of ninja it works with makefiles
[22:15] <racarr> Submitted a first step of refactoring that I think gets across my idea with msh:: :) going to wait for some discussion on the rest
[22:34] <kgunn> mterry: so...curious...how's the greeter split going now that mir-on-mir AP test is solved? i know you were going to mp a lightdm to keep sf enabled...but outside of that, any other issues?
[22:36] <mterry> kgunn, so today the last piece of the puzzle got filed, I believe.  everything is in appropriate trunks except for the lightdm branches and the top-level config changes which will be last
[22:36] <mterry> kgunn, this is for nested mode switch
[22:36] <mterry> kgunn, not split greeter
[22:36] <mterry> kgunn, this is step 1 to split greete
[22:36] <mterry> kgunn, after this, will be actually splitting greeter out
[22:36] <mterry> kgunn, then enabling locking
[22:37] <mterry> kgunn, but for the actual splitting out, there will likely be more yaks to shave around receiving calls and such in the greeter.  I'm going to dive into some of those issues now that nested mode is mostly solved
[22:38] <mterry> also visual look of the greeter on top of session
[22:39] <kgunn> mterry: ok...this is kind of sounding daunting...do you need a hand from anyone?
[22:39] <kgunn> mterry: you can pick who you want as this is a key item we need to nail
[22:40] <mterry> kgunn, for next step of splitting greeter, I have to catalog remaining issues.  Then I'd know who to get help from.  I suspect if we want to avoid a regression in unlocking animation, I might need some help from a low-level graphical point of view...
[23:36] <kgunn> RAOF: racarr kdub ...any of you mind if i move the meeting out 30 minutes? i gotta personal commit tonight and i just know it'll run over
[23:36] <RAOF> Fine by me.
[23:36] <kgunn> oh wow...that'd be nice if i had put repeat on the invite
[23:36] <kgunn> doh
[23:48] <RAOF> Heh