[05:30]  * RAOF would like gmock to hurry up and make NiceMock the default.
[06:08] <duflu_> RAOF: That would be troublesome for finding things you missed
[06:08]  * duflu_ -> lunch
[06:09] <RAOF> duflu_: You can always explicitly make them naggy mocks if you want.
[06:11] <RAOF> duflu_: Another question is: what sort of things you missed?
[07:07] <duflu> RAOF: Naggy can be useful, yes :)
[09:16] <Saviq> hey guys, do these test failures from devel mean anything to you https://launchpadlibrarian.net/170204996/buildlog_ubuntu-trusty-armhf.mir_0.1.8%2B14.04.20140321-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[09:20] <alan_g> Saviq: it is only a guess - but is that an attempt to run the tests on a machine with no graphics hardware?
[09:21] <Saviq> alan_g, definitely, it's a launchpad builder
[09:21] <Saviq> alan_g, if those tests require graphics, they shouldn't be included in make check
[09:21] <Saviq> alan_g, OTOH it completed for i386 and amd64
[09:22] <Saviq> alan_g, it's basically a PPA build of lp:mir/devel
[09:22] <alan_g> alf__: ^^ you were looking into which tests ran where recently?
[09:22] <Saviq> alan_g, alf__ ugh, so we lost that log right now, since the build was rekicked
[09:23] <Saviq> let's see if it's consistent, then, will report back in some 37 minutes
[09:23] <alan_g> Saviq: ack
[09:27] <alan_g> alf__: FWLW there was a lot of "C++ exception with description "Could not open hardware module" thrown in the test body."
[09:29] <alf__> alan_g: hmm, that sounds like android hw, but didn't kgunn disable them for package building? Let me see..
[09:29] <alf__> alan_g: them = integration and acceptance tests
[09:30] <alan_g> alf__: "them" is what failed
[09:30] <alan_g> I thought so too
[09:31] <alf__> alan_g: ah, they were disabled only in trunk not devel
[09:31] <alan_g> Saviq: ^
[09:31] <alf__> alan_g: don't we sync back from trunk to devel after release?
[09:32] <Saviq> oh, explanations, /me likes :)
[09:32] <alf__> alan_g: well, it's clear we didn't in this case, but aren't we supposed to do so?
[09:32] <alan_g> alf__: we do. But this time there were some "trivial conflicts" maybe it got lost
[09:33] <alf__> alan_g: Saviq: ok, let me sync again
[09:33] <Saviq> alf__, looks like "nothing to do"
[09:33] <Saviq> alf__, but indeed that change is not there
[09:34] <alf__> Saviq: ok, I will propose an MP with the fix
[09:34] <Saviq> alf__, great, thanks
[09:43] <Saviq> alf__, please let me know when you get the MP, I'd like to put it in a silo
[09:43] <alf__> Saviq: ok
[09:51] <duflu> Whee, circular make_shared dependencies eat all the memories
[09:51] <alan_g> duflu: stick to a DAG
[09:52] <duflu> alan_g: I know but I didn't see the cycle coming
[09:52] <alan_g> I guessed that ;)
[09:53] <alan_g> I presume no-one else is looking into https://bugs.launchpad.net/mir/+bug/1295231?
[09:53] <alf__> RAOF: do we require libumockdev >= 0.6? Trunk says no, devel says yes, but the change in devel predates last sync of devel => trunk
[09:54] <duflu> alf__: I think that just landed for 0.1.8. It's documented in the upcoming changelog ;)
[09:54] <duflu> Oh, that part's not documented
[09:58] <alf__> duflu: you are right, it's post 0.1.7
[10:09] <alf__> Saviq: https://code.launchpad.net/~afrantzis/mir/no-display-hw-tests-on-armhf-package-builds/+merge/212122
[10:09] <Saviq> alf__, thanks!
[10:26]  * alan_g looks at TestClientInput and feels a strong urge to delete and rewrite
[11:57] <alan_g> alf__: happy for me to top-approve https://code.launchpad.net/~alan-griffiths/mir/once-Surface-interface-to-rule-them-all/+merge/212012?
[11:58] <alf__> alan_g: hmm, I thought I had review that (or something similarly named :))
[11:58] <alf__> alan_g: looking
[12:12] <alf__> alan_g: @//resolve ambiguous member function names, what's ambiguous about them?
[12:12] <alan_g> They exist in multiple base classes
[12:13] <alan_g> (Which makes code calling them ambiguous)
[12:13] <alf__> alan_g: but they are pure virtual in all of them, so shouldn't this just work?
[12:14] <alan_g> I know what you mean, but no
[12:16]  * alan_g tries to come up with code where it matters which name is resolved...
[12:19] <alan_g> auto eg1 = &Surface::name; // eg1 is Base1::*()
[12:19] <alan_g> auto eg2 = &Surface::name; // eg2 is Base2::*()
[12:19] <alan_g> eg1 & eg2 have different types
[12:20] <alan_g> Even though they call the same member function
[12:21] <alan_g> There's no rule in the standard to disambiguate Base1::name and Base2::name
[12:22] <anpok_> hm a using of either Base1::name or Base2::name?
[12:24] <alan_g> that would work too
[12:26] <alf__> alan_g: I don't get what the first two line you pasted show
[12:27] <alan_g> The two alternative resolutions of Surface::name
[12:28] <alan_g> It isn't real code - as both lines are ambiguous
[12:33] <alf__> alan_g: ok, got it, thanks
[12:34] <anpok_> mterry: hi
[12:34] <anpok_> I was reviewing and now testing the u-s-c branch..
[12:35] <anpok_> one question came up .. in which cases should the spinner show up?
[12:35] <mterry> anpok_, hi
[12:36] <mterry> anpok_, well, where you testing with other split branches or just the usc branch?
[12:42] <anpok_> oh - only usc - and I only see it on startup .. i need a unity8 branch too?
[12:49] <mterry> anpok_, so the branch is OK in isolation.  But you won't see all the scenarios unless you also install some other branches...  Let me give you links, and I can explain when you'll see others
[12:50] <mterry> anpok_, https://code.launchpad.net/~mterry/unity8/split/+merge/210664 and https://code.launchpad.net/~mterry/ubuntu-touch-session/split/+merge/211549
[12:50] <mterry> anpok_, the times you'll see it are 3-fold:
[12:52] <mterry> anpok_, boot, waiting for greeter to come up; boot, after greeter comes up but if the session behind the greeter is slow to appear and you swipe greeter away very fast, you'll see spinner until user session finishes appearing; and when you lock device, if you turn it back on very quickly before greeter has had a chance to finish appearing, you'll see it
[12:52] <mterry> anpok_, that second instance Design actually wants me to get rid of -- I'll make a small adjustment to that branch so that the greeter doesn't appear until the user session is also ready
[20:49] <mterry> racarr_, hello!
[20:50] <mterry> racarr_, we've got a testing PPA for the split greeter stuff going (which includes your remove-ensure-display-powered merge)
[20:50] <mterry> racarr_, but I'm still seeing the screen turn on after locking
[20:50] <mterry> racarr_, I was wondering if you had time to re-investigate that.  Might be easier now that there is a PPA with all the code for easier testing
[20:51] <mterry> racarr_, https://launchpad.net/~ci-train-ppa-service/+archive/landing-004
[20:53] <racarr_> mterry: Ok I will investigate
[20:54]  * mterry buys a beer for racarr_, keeps it cold in fridge for ya
[20:54] <mterry> tsk..  this beer will go bad before I see you next
[20:54]  * mterry opens beer
[20:56] <dansuf> Hi, I am porting ubuntu touch to my phone and I've got graphics-related issues. Here's a log generated by logcat when running lightdm: http://pastebin.com/ag6iSVkW . Also, in dmesg I've got "mdp4_overlay_play: pmem Error" and in unity-system-compositor.log: "terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[20:56] <dansuf>   what():  error during hwc set()
[20:56] <dansuf> "
[21:00] <dansuf> Any ideas what could be the cause of these errors?
[21:12] <racarr_> mterry: Cheers lol
[21:13] <racarr_> dansuf: Hmm I mean abstractly it looks like some of the hardware compositor usage through the android HAL...isnt working
[21:13] <racarr_> the different devices have different quirks. kdub or AlbertA would know more.
[21:15] <kdub> dansuf, yeah, something is going wrong with hwc and the drivers
[21:15] <racarr_> We used to have a fallback mode...presumably still do, that might work for you
[21:15] <racarr_> dansuf: in mir/src/platorm/graphics/android/output_buider.cpp I think you could force_backup_display(true) in the constructor
[21:15] <dansuf> so it may be something connected to device files
[21:16] <dansuf> racarr_, I will have to build mir?
[21:16] <kdub> fallback is discontinued in most up to date qcom drivers
[21:17] <kdub> which device?
[21:17] <racarr_> Oh. :( maybe we dont have a fallback
[21:17] <dansuf> aa far as i know its legacy version if this does change anything
[21:17] <dansuf> i mean legacy qcom
[21:17] <dansuf> i don't have big knowledge about all this stuff
[21:18] <dansuf> it's sony ericson live with walkman, codename coconut
[21:18] <AlbertA> it does look like dev permissions from the log
[21:19] <AlbertA> or maybe your kernel driver does not instantiate those devices
[21:19] <dansuf_> i applied udev permissions from android files
[21:19] <kdub> yeah, maybe run as root and see if that helps
[21:20] <dansuf_> i run it in root shell
[21:20] <kdub> also, those drivers have a hwc.mdpcomp.enable (or similar), maybe try turning that off
[21:45] <dansuf_> kdub, I set that to false in build.prop, it still fails but the logcat is slightly extended http://pastebin.com/Au3Paj1x
[21:48] <kdub> i'd still guess there's some permissions or chroot mix up somewhere
[21:48] <kdub> do the hybris test programs work?
[21:49] <dansuf_> kdub, I didn't run them
[21:49] <dansuf_> Where can I find them?
[21:50] <kdub> /usr/bin/test_glesv2 from libhybris-test
[21:51] <dansuf_> kdub, wow, it works
[21:51] <dansuf_> I mean, the tests
[21:51] <kdub> dansuf, good sign
[21:52] <dansuf_> Although, egl seems to crash
[21:56] <dansuf_> I'll try maybe to build mir with fallback
[22:43] <dansuf_> So, I tried to build mir for ubuntu touch and It just throws error with no reason "[  7%] Built target android-input
[22:43] <dansuf_> make: *** [all] Error 2
[22:43] <dansuf_> "
[22:57] <bregma> racarr_, just so you know, I pushed your u-s-c and the lightdm tweaks to https://launchpad.net/~unity8-desktop-session-team/+archive/custom and installed them, I now have a working mouse and trackpad in the Unity8 desktop session
[22:58] <bregma> just. like. that.
[22:58] <bregma> I look forward to those hittong the archive soon for winder consumption
[22:58] <bregma> *wider