[00:30] <robotfuel> racarr: ping
[00:32] <robotfuel> kdub: ping are you still around?
[00:32] <kdub> indeed
[00:39] <robotfuel> kdub: I have failing tests are arm due to memory leaks, do you know who I should ping about it? https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/139/console
[00:39] <robotfuel> er I have failing tests on arm due to...
[00:40] <kdub> ooo, are we running tests on arm? :)
[00:40] <kdub> robotfuel, i'll take a quick look
[00:41] <robotfuel> kdub: the tests pass when I don't use valgrind.
[00:44] <kdub> robotfuel, right
[00:49] <kdub> robotfuel, i see it too, could you file a bug against mir?
[00:49] <robotfuel> kdub: will do
[00:51] <kdub> robotfuel, thanks
[00:52] <cpatrick08> i am trying to build mir from source on trusty and I get following error http://pastebin.com/zeRYuQiB
[00:53] <cpatrick08> cmake-gui options for builf http://tinypic.com/r/11b1bsz/5
[00:53] <robotfuel> kdub: https://bugs.launchpad.net/mir/+bug/1253486
[00:53] <ubot5> Ubuntu bug 1253486 in Mir "memory leaks in unit tests on android" [Undecided,New]
[00:54] <kdub> cpatrick08, you could just disable building the unit tests, if thats the only thing failing
[00:55] <kdub> although, it is strange it can't find eglCreateImageKHR, as nothing should link to that directly anyways
[00:55] <RAOF> cpatrick08: Hm, difference with my successful builds might be “use debflags’
[00:55] <cpatrick08> will take that away and try to build again will let you know if that works
[00:56] <kdub> i retract my statement about 'nothing should link to that'... :) long day
[00:57] <kdub> sigh, i retract my retraction :)
[00:57] <robotfuel> cpatrick08: did you try dpkg-buildpackage?
[00:59] <cpatrick08> no i have not will try it if this does not work
[01:07] <kdub> morning duflu
[01:08] <kdub> i made a comment on the bug, but I don't see input problems on my n7
[01:13] <duflu> kdub: Hi. OK, thanks
[01:20] <kdub> oh, and resizing was okay too :)
[01:24] <duflu> kdub: Yeah, that's what confused me. I had demo-shell getting input a week or two ago, but not clients. Now nothing
[01:24] <duflu> It's only the N7 that's an issue
[01:44] <cpatrick08> kdub, i removed the unit tests and the make worked but when i ran ctest i got error only on test 23 	 23 - integration-tests.GBMBufferIntegration.* (SEGFAULT)
[01:45] <cpatrick08> i kept the debflags on btw
[01:48] <cpatrick08> i am trying it again with the debflags off
=== chihchun_afk is now known as chihchun
[03:37] <duflu_> RAOF: What am I missing?... https://bugs.launchpad.net/mir/+bug/1253507
[03:37] <ubot5> Ubuntu bug 1253507 in Mir "The following tests FAILED: 134 - unit-tests.UdevWrapperTest.* (OTHER_FAULT)" [High,Triaged]
=== duflu_ is now known as duflu
[03:37] <RAOF> duflu: We should really spit out the actual test output when it fails :)
[03:38] <duflu> RAOF: It's way too long :/
[03:38] <RAOF> Not for the bit that fails.
[03:38] <RAOF> Anyway, what *is* the output?
[03:39] <duflu> RAOF: Yes, the bit that fails is massive...
[03:39] <duflu> But mostly they say C++ exception with description "Udev device does not exist" thrown in the test body.
[03:39] <RAOF> Iinteresting.
[03:39] <RAOF> Pastebin?
[03:40] <duflu> RAOF: Attached to the bug
[03:41] <duflu> RAOF: Weird cos my saucy and trusty machines seem to have identical udev packages
[03:41] <RAOF> Ah, but probably have different umockdev packages?
[03:41] <duflu> Oh, wait, no. The Ubuntu revisions differ
[03:42] <duflu> RAOF: Yeah fails on umockdev 0.4.6-2, works on 0.4.7-1
[03:44] <RAOF> umockdev is just being totally screwy there; it's not providing a mock udev environment at all.
[03:45] <duflu> RAOF: But it worked a few days ago(?)
[03:45] <RAOF> Not on those tests it didn't?
[03:45] <duflu> RAOF: Well, everything we had worked a few days ago
[03:45] <RAOF> Because those tests are shiny and new!
[03:46] <duflu> I assume we used umockdev to some extent even before, when it worked
[03:59] <RAOF> Yeah, we did.
[05:42] <RAOF> Is there some good reason why lp:mir doesn't resolve to lp:~mir-team/mir/development-branch?
[05:50] <duflu> RAOF: Not by our own choice. I tried pointing lp:mir to development-branch at the start of the cycle. But distro have a *requirement* that lp:mir be more stable than they perceive development-branch to be
[05:50] <duflu> So now lp:mir is the Ubuntu branch
[05:50] <RAOF> I am going to *keep* hitting that, aren't I ☹
[05:51] <duflu> RAOF: Mainly it's about ABI stability and how any break in Mir affects a string of other projects. So it's good we can batch and control the timing of ABI breaks into lp:mir
[05:52] <duflu> tvoss_: Morgen
[05:53] <duflu> RAOF: Apparently the "ubuntu" project branches for Mir can't be used for Ubuntu packaging work. So they need to own lp:mir
=== tvoss_ is now known as tvoss|test
=== tvoss|test is now known as tvoss
[06:28] <tvoss> duflu, hey there :)
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[08:10] <mlankhorst> morning
[09:26] <duflu> Ping alan_g
[09:26] <alan_g> duflu: morning
[09:27] <duflu> alan_g: Hello. I have spiked that event queue idea. I think it's looking very attractive now, but needs some serious testing yet. So just FYI... please don't duplicate effort for now. I'll get it up for review by Friday in the latest
[09:27] <alan_g> duflu: that's great. Thanks.
[10:11] <alf_> duflu: alan_g: Do unit-tests.UdevWrapperTest.* tests fail for you locally with the latest development-branch?
[10:11] <duflu> alf_: Yes. But only on saucy
[10:12] <alan_g> no
[10:12] <alf_> duflu: I am on trusty...
[10:12] <duflu> alf_: Me too, half the time
[10:12] <alf_> duflu: I mean they fail for me on trusty
[10:13] <duflu> alf_: That's odd, but means it's more serious than first thought
[10:30] <duflu> alf_: There's a bug already BTW: 1253507
[10:30] <duflu> bug 1253507
[10:30] <ubot5> bug 1253507 in Mir "The following tests FAILED: 134 - unit-tests.UdevWrapperTest.* (OTHER_FAULT)" [High,Triaged] https://launchpad.net/bugs/1253507
[10:31] <alf_> duflu: thanks, assigning to myself
[10:36] <duflu> alf_: If you get that bug on trusty then it's probably Critical :/
[10:36]  * duflu goes to make dinner
[10:56] <alan_g> alf_: update - running without ctest I too see the problem
[10:57] <alan_g> alf_: and something similar in GBMDisplayTest.drm_device_change_event_triggers_handler
[10:59] <alf_> alan_g: right, the umockdev framework needs an LD_PRELOAD to work properly
[11:00]  * alan_g leaves it to alf_ who's already on it
[11:02] <alf_> alan_g: I don't think there is a solution to it. When running manually we need to use the preload (or the related umockdev-wrapper script)
[11:03] <alan_g> That sucks
[11:06]  * alan_g wonders if any tests needing this preload should be put in a separate executable
=== alan_g is now known as alan_g|lunch
=== dandrader is now known as dandrader|afk
=== chihchun is now known as chihchun_afk
=== dandrader|afk is now known as dandrader
[13:40] <alf_> tvoss: Please take a look at https://code.launchpad.net/~afrantzis/mir/mir-client-ensure-global-symbol-resolution/+merge/196110 , especially the discussion about the options, since it involves multiple components in our stack
[13:40] <tvoss> alf_, yup, put it on my list
=== alan_g|lunch is now known as alan_g
[14:19] <alan_g> Any experts on booting with USC about? I tried following the instructions - http://unity.ubuntu.com/mir/using_mir_on_pc.html - although I had to create the .conf file after installing USC. But when I restart I see "/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xmir_get_drm_fd" in /var/log/lightdm/x-0.log.old. Does anyone know how to fix?
[14:28] <alf_> alan_g: I haven't seen that before (but it has been a while since I tried USC)
[14:30] <alan_g> alf_: thanks. (This is my first time with USC.)
[14:52] <kgunn> alan_g: i can try in a moment...
[14:52] <kgunn> alan_g: are you on trusty or saucy ?
[14:52]  * kgunn knows alan_g :)
[15:00] <alan_g> kgunn: that laptop is on trusty
[15:00]  * kgunn does _not_ know alan_g  :)
[15:01] <kgunn> alan_g: ok...i'm on trusty...just looking at your output...sure looks like packaging shenanigans
[15:01] <alan_g> kgunn: ack
[15:02] <alan_g> kgunn: What I was really trying to do was test this: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/dont-use-ApplicationSession/+merge/193070
[15:03] <alan_g> kgunn: If this problem will go away by itself then I don't want to waste too much time
[15:06] <kgunn> alan_g: so, i already had u-s-c installed, so just had to comment back in type=unity, rebooted...u-s-c/xmir came up fine for me
[15:06] <kgunn> alan_g: would you like me to rebuild u-s-c from that branch to test?
[15:08] <alan_g> kgunn: please. I'm going to wait and see if the packages come into alignment over the next few days
[15:08] <kgunn> alan_g: yeah...something doesn't seem quite right wrt packaging in trusty
[15:09] <kgunn> based on some previous stuff i've seen
[15:12] <alan_g> hmm, my netbook just refused to upgrade to trusty as it can't find some of the repos.
=== dandrader is now known as dandrader|lunch
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[21:06] <mterry> Did y'all remove the mir::surfaces namespace?  Compiling unity-mir against mir devel-branch gives an error to that effect
[21:22] <kdub>   mterry it is now mir::scene
[21:35] <mterry> kdub, thanks, btw
[21:36] <racarr> mterry: I guess you aren't cool enough to keep up with the hip new scene.
[21:36] <racarr> *drum crash*
[21:37] <mterry> racarr, whatever, I'll just hang out with libmirserver7 at my house.  I don't need this mir scene
[21:38] <racarr> lol
[21:38] <racarr> welcome
[21:38] <racarr> to my life
[21:38] <mterry> :)
[22:36] <ricmm> kdub_: ping
[22:39] <ricmm> kdub: ping
[22:43] <kdub> pong