[00:34] <RAOF> AAaargh.
[00:35] <RAOF> Stupid partial-armhf-chroot stupid bastard of a thing.
[01:36] <RAOF> Um, why doesn't find_path actually stat the file it's looking for?
[01:42] <duflu_> RAOF: maybe because stat will give you the real answer, whereas it may be useful to retain a relative path like that passed in?
[01:43] <RAOF> duflu_: But then how does it find the file?
[01:43] <duflu> Magic!
[01:44] <RAOF> Specifically - I can see that find_library stats for the library it's looking for, and indeed, find_library(GLIB_LIBRARY ...) is finding the glib library.
[01:45] <RAOF> However, find_path(GLIB_INCLUDE_DIR glibconfig.h ...) isn't statting glibconfig.h, and isn't finding GLIB_INCLUDE_DIR.
[02:04] <RAOF> Ok, that's super annoying.
[02:58] <duflu> RAOF: I missed that, and hope it's not my lack of IRC stability that's annoying
[02:58] <duflu> It's annoying me though
[03:22] <RAOF> duflu: Ah, no. I was just getting annoyed at cmake and our convoluted build system.
[03:53]  * RAOF wins the buildsystem wranger award!
[04:09] <duflu> gcc wins the award for compiler most confused and lost by a missing parenthesis
[04:10] <duflu> I shouldn't have to switch to clang just to figure out what's wrong.
[04:11] <RAOF> duflu: Correct! Have export CC=clang; export CXX=clang++ in your .profile! :)
[05:15] <RAOF> Ooh, we've gained a .clang-format directive.
[06:32] <RAOF> Arse.
[06:33] <RAOF> Where is the configuration of the mako testrunner?
[06:33] <RAOF> Also, how do we change it?
[06:33] <RAOF> (cf: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/259/console , which is a failure because of a shiny new libumockdev0 dependency that's not getting resolved)
[07:03] <sgx1> hi, i haven't followed mir  for several months. did your developement focus change from lp:mir to lp:mir/devel ?
[07:03] <duflu> sgx1: Yes
[07:03] <duflu> :)
[07:15] <sgx1> I've a local lp:mir repository. is it possible to  create a a local lp:mir/devel from this and pull updates instead of 'bzr branch lp:mir/devel" ? i'm not familiar bazaar.
[07:20] <duflu> sgx1: You should "bzr branch lp:~mir-team/mir/development-branch mydevbranch" so you can pull regular updates. But if you're not happy doing that then just download the source tarball: https://launchpad.net/mir/+milestone/0.1.4
[07:22] <sgx1> what's the difference between  lp:~mir-team/mir/development-branch and lp:mir/devel?
[07:28] <sgx1> thanks anyway.
[09:44] <alan_g> alf__: just checking - you're happy with updates to expose-rpc-infrastructure?
[09:47] <alf__> alan_g: yes
[09:47] <alan_g> thanks
[09:49] <duflu> alan_g: I think we should usually try to wait for a minimum of 2 (human) reviews. Sorry I didn't get to it...
[09:50] <duflu> Oh, perhaps it did almost get 2
[09:50] <alan_g> duflu: Yeah. And it is low risk of breaking things
[09:51] <duflu> alan_g: Well, start of a new mini-cycle too. So lower risk
[09:52] <alan_g> ;)
[10:01] <alan_g> alf__: can you land build-options-for-tests? (or abandon it)
[10:03] <alf__> alan_g: I will try to sync with CI today, to change the jenkins scripts. If I don't manage to do it today I will mark it as WIP, so it doesn't clutter the MP list.
[14:05] <greyback> hey folks, what does the error message: what():  error during hwc set()
[14:13] <alan_g> greyback: I don't recognise it, but sounds like something kdub might know. Do you have any more details?
[14:13] <greyback> alan_g: not really no, it pops up during random autopilot tests.
[14:14] <greyback> https://bugs.launchpad.net/mir/+bug/1262982 is best I could log about it
[14:15] <alan_g> greyback: Hmm. The reporting code should be better - one of the points of boost exceptions is that they give file & line number.
[14:16] <greyback> alan_g: here's one instance: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4625/artifact/results/log/unity8.log
[14:20] <alan_g> greyback: there's nothing there that points me to the right place. Can you wait for kdub to wake up?
[14:21] <alan_g> alf__: ^^ any idea?
[14:22] <anpok> since when did this start to pop up?
[14:25] <alf__> alan_g: greyback: it's from mga::HWC11Device::post() (or less likely mga::HWC10Device::post(), depending on the device). I am guessing it has to do with screen blanking, but not certain.
[14:25] <greyback> anpok: not really sure, possible it's been around for a while
[14:25] <anpok> but not started to happen, like mid of last week?
[14:26] <greyback> alf__: that would be a possibility anyway
[14:26] <greyback> anpok: think longer
[15:32] <anpok> hm i have issues building for android
[15:34] <anpok> the hwcomposer_defs.h defines a set of HWC_DEVICE_API_VERSION_X_X macors that map to HARDWRE_DEVICE_API_VERSION_2 .. which should be defined hardware.h
[15:35] <anpok> but hardware.h only has HARDWARE_DEVICE_API_VERSION
[16:15] <anpok> ah ok cleaning up the var/apt/cache/ helps
[16:18] <kdub> anpok, old versions of android-headers needed a patch for that, which went in mid-december
[16:26] <anpok> kdub: I had two versions of them downloaded, and both of them installed - for some reason the older one won
[16:48] <kdub> alf__, alan_g so with the db-optimize branch, the proposed design is set to keep the gl rendering in the compositor class
[16:49] <kdub> with the sequence being DisplayBuffer::optimize(), Renderer::render(), DisplayBuffer::post()
[16:50] <kdub> we could also just have DisplayBuffer::post(gl_rendering_functor), which I didn't go with because I wanted to keep the responsibility to GL-render out of DisplayBufferr
[16:51] <rsalveti> kdub: hey, got one issue with mir when porting to 4.4
[16:51] <kdub> rsalveti, i'd be surprised if there wasn't one or two issues :)
[16:51] <kdub> what is seen?
[16:51] <rsalveti> kdub: seems the qcom devices dropped the rendering support on fb devices
[16:51] <rsalveti> kdub: so fb->post doesn't work anymore
[16:51] <rsalveti> seems that this is not an issue with sf as it uses the hwcomposer for post
[16:52] <kdub> well, we should be able to use hwcomposer for that one too...
[16:52] <rsalveti> kdub: yeah, seems that's the only issue
[16:52] <rsalveti> kdub: we should probably use hwcomposer by default for that unless it's not available
[16:53] <rsalveti> which might be what sf is doing already
[16:53] <kdub> rsalveti, we use hwcomposer as default, and fall-back to the fb module
[16:53] <rsalveti> oh, cool then
[16:53] <kdub> so something isn't loading in hwcomposer, then we try fb, and that doesn't work either
[16:53] <kdub> i'd guess that...
[16:53] <kdub> hwcomposer is now like version 1.2 or something
[16:53] <rsalveti> yeah
[16:54] <kdub> not a lot of code change for us, but we currently fail if we detect version 1.2
[16:54] <rsalveti> kdub: oh, ok
[16:54] <kdub> rsalveti, i could try the image and see if i can bump it to work
[16:54] <rsalveti> let me check, but I think mako is using 1.2
[16:54] <rsalveti> kdub: yup, will publish one image in a few
[16:54] <kdub> rsalveti, cool, thanks
[16:55] <alf__> kdub: it could be DisplayBuffer::post(unoptimized_rendering_functor) with unoptimized_rendering_functor(list of surfaces). DisplayBuffer doesn't need to know anything about GL in particular
[16:55] <rsalveti> I/SurfaceFlinger(  652): Using composer version 1.2
[16:55] <rsalveti> kdub: ^
[16:56] <rsalveti> in theory android 4.4 already supports even 1.3
[16:56] <kdub> yeah, so my hope is that i can just bump the versioning checks in mir, and it should work
[16:57] <kdub> the api is not much different between 1.1, 1.2, and 1.3
[16:57] <kdub> (there were bigger jumps in api between fb module, 1.0, and 1.1)
[16:58] <rsalveti> right, cool
[17:07] <anpok> kdub: is it possible that the hwc cherry picks a few buffers in the middle of the array?
[17:08] <anpok> bbl
[17:09] <kdub> anpok, sure, if its possible
[17:09] <kdub> like, if you had 4 tiled windows, it could pick the lower-left one, although in the array its between two gl composited ones
[18:54] <anpok> kdub: who is using setScreenPowerMode?
[18:56] <kdub> anpok, where do you see that symbol?
[18:57] <anpok> dbusscreen.cpp
[18:57] <anpok> so somebody wires it with powerd?
[18:57] <anpok> or is it maybe used from a qml script?
[18:58] <kdub> yes, that signal comes from dbus
[18:58] <kdub> right now, that's powerd, but it could come from anywhere i suppose
[23:56] <RAOF> robotfuel: How are the mako test images set up? Specifically, can I get another package installed on it (or, better, get the test script to run ‘apt-get -f install’ after its dpkg run so that added dependencies get resolved automatically)?
[23:58] <robotfuel> RAOF: It's been a while let me look
[23:59] <RAOF> robotfuel: cf: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/259/console