[01:09] <RAOF> *Man* I'd love a signal/slot interface here...
[07:58] <RAOF> Woo!
[07:59] <RAOF> Acceptance test that not only runs, but it also both fails to crash *and* passes!
[09:04]  * alan_g wonders how to get the screen "on" after stopping lightdm. "sudo powerd-cli display on bright&" gives a dbus error.
[09:08] <alan_g> alf_: has something changed in the power management? I'm trying to run mir tests on the phone but can't get anything on the screen unless I've also got U8 running (and fighting over the display).
[09:15] <alf_> alan_g: I've had this problem too, not sure what changed. I think the behavior depends on the device
[09:16] <alan_g> greyback: do you know what's changed? ^^
[09:16] <greyback> alan_g: that's been the case for many months now, afaik
[09:16] <greyback> stopping usc turns off hte backlight
[09:17] <alf_> alan_g: powerd-cli wants to communicate with Unity.Screen dbus interface which is implemented by USC
[09:17] <greyback> alan_g: I'm told there's a backlight util in mir-utils
[09:17] <greyback> I tend to hunt for a "brightness" file in /sys/devices and write 255 to it :)
[09:19] <alf_> greyback: alan_g: right, mirbackligh is a shell script that does more or less what you described
[09:20]  * alan_g goes to update his notes
[09:23] <alf_> anpok: @extended-mock-of-libinput, Could you elaborate on "InputDeviceInfo of the device is no longer initialized on demand, this lead to adding umockdev those tests."
[09:33] <anpok> alf_: getting that device info means accessing evdev
[09:34] <alf_> anpok: isn't access to evdev mocked though?
[09:34] <anpok> hm
[09:34] <anpok> not yet..
[09:34] <anpok> I could actually use libevdev
[09:36] <anpok> in some sense that code which still accesses evdev should probably move to libinput some day
[09:37] <alf_> anpok: ok, so looking at the code, we seem to monitor all devices, shouldn't we filter somewhere only for input related devices?
[09:42] <anpok> you are right
[09:50] <alf_> vogons: I top approved lp:~cemil-azizoglu/mir/merge-post-mir-16-changelog and it got merged without running an autolanding job. Has anyone seen this?
[09:51] <anpok> that was the first landing since .. some time friday
[09:51] <alan_g> alf_: yes, not sure what the logic is but I've seen it before
[10:11] <anpok> alf_: oh it seems I had no test for it.. but there is filtering happening
[10:12] <anpok> and the new test passes..
[10:14] <alf_> anpok: filtering in the sense that we get events only for interesting devices, or in the sense that we get events for all but then only succeed in creating mir objects for real input devices?
[10:15] <alf_> anpok: ah, never mind, I see it now "this->monitor->filter_by_subsystem("input");"
[10:16] <anpok> yes .. I was to tired to see it when skimming through the file
[10:16] <anpok> brb
[11:42] <greyback_> alan_g: hey, would you please merge trunk into https://code.launchpad.net/~alan-griffiths/qtmir/small-refactoring-of-MirWindowManager/+merge/266698
[11:42] <greyback_> I'd like to see why CI wasn't happy the last time
[11:42] <alan_g> greyback_: on my list
[11:42] <greyback_> thanks
[19:34]  * pixel_ ping facebook o_O
[19:34]  * pixel_ he dead?
[20:50] <robert_ancell> kgunn, are there any existing Jenkins jobs that rebuild dependencies for checking?
[20:50] <robert_ancell> I know Jenkins can do practically anything, wondering if this is new ground or not
[20:51] <kgunn> robert_ancell: i think we rely on the autopackage testing to actually do the building/running of rdep tests
[20:53] <kgunn> robert_ancell: but i suppose, if you wanted to create jenkins jobs for xorg and mesa, you could...and as part of any update (via MP) you could do that same
[20:54] <robert_ancell> kgunn, being a traditional package, we don't do MPs for xorg / mesa. If we can now use Launchpad for git and link up to the MPs there we could link into this infrastructure.
[20:55] <kgunn> robert_ancell: i hear about lp for git working, but not real sure how that all works... i don't mind that approach
[20:56] <kgunn> but is there something limiting wrt trying to use autopackage testing ?
[20:56] <robert_ancell> kgunn, I don't know how that works - is that just adding something into debian/ ?
[20:56] <robert_ancell> And the tests are run on upload?
[20:56] <kgunn> robert_ancell: that's my understanding
[20:56] <kgunn> right
[20:56] <robert_ancell> kgunn, do you know an existing packge to look at?
[20:57] <robert_ancell> So, we can add something that essentially says "rebuild Mir for this upload and check it still builds"?
[20:58] <kgunn> robert_ancell: afaik, this is the wiki for that
[20:58] <kgunn> http://packaging.ubuntu.com/html/auto-pkg-test.html
[20:58] <robert_ancell> kgunn, ta
[20:59] <kgunn> robert_ancell: ....kind wonder if there's a newer wiki than that
[20:59] <robert_ancell> kgunn, that's suggesting to me that the tests can only run things, not rebuild anything (which is what I expected).
[21:00] <robert_ancell> The particular case you were concerned about was Mir failed to rebuild (i.e. creating a FTBFS) or it failed on runtime?
[21:00] <kgunn> robert_ancell: both actually...
[21:01] <robert_ancell> ok, so we can solve the latter with this. The former will probably require manual testing to catch (as is the case for all packages AFAIK)
[21:01] <kgunn> robert_ancell: but yes, aiui, there is a way to force the rebuild of rdeps to check for ftbfs
[21:01] <kgunn> automatically
[21:01] <robert_ancell> ok, we need to find that
[21:01] <kgunn> and i think it is in the debian/ files
[21:02] <kgunn> robert_ancell: this is how stuff gets stuck in proposed migration in excuses sometimes
[21:02] <robert_ancell> kgunn, do you know of a particular package that has got stuck like this?
[21:04] <kgunn> robert_ancell: yeah, i'm trying to rack my brain
[21:04] <kgunn> gimme a bit of digging and i'll try to find an example
[21:04] <robert_ancell> Mir doesn't trigger a rebuild of u-s-c does it? (it probably should)
[21:04] <robert_ancell> Seems Mir doesn't have any autopkg tests
[21:17] <kgunn> robert_ancell: you are right...
[21:17] <kgunn> well
[21:18] <kgunn> robert_ancell: i think we are basically always rebuilding u-s-c/qtmir anyhoo b/c we break abi like we change our socks
[21:18] <robert_ancell> :)
[21:19] <kgunn> robert_ancell: right, actually...now that my fog has cleared a little...it's the other way round
[21:20] <kgunn> so u-s-c should have a dep on mir that would trigger a rebuild for any new upload of mir
[21:20] <kgunn> ...so
[21:20] <kgunn> likewise, i think we have to add the dep statement to mir for xorg
[21:20] <kgunn> that would then trigger a rebuild any time a new xorg is uploaded
[21:24] <robert_ancell> you mean trigger a rebuild of xorg each time Mir is uploaded?
[21:25] <kgunn> robert_ancell: nope the other way around...which is why i forgot for a moment, it's kind of backward feeling
[21:25] <robert_ancell> kgunn, I think we need a trigger on mesa to rebuild Mir on an upload, but xorg is the other way around
[21:26] <kgunn> robert_ancell: actually...can be both ways...we have mir on x and xmir now
[21:26] <robert_ancell> oh right
[21:26] <robert_ancell> that makes it more complicated...
[21:27] <kgunn> robert_ancell: but i think mir has tests for x on mir probably
[21:27] <kgunn> so you're right xmir would be the thing we'd want to add
[21:44] <kgunn> robert_ancell: so are you going to add a mir dep to xorg-xmir ?
[21:46] <robert_ancell> kgunn, If we can
[21:48] <kgunn> robert_ancell: and do you look after mesa, or is that only timo ?
[22:18] <robert_ancell> kgunn, it's basically just timo at the moment
[22:20] <robert_ancell> kgunn, bug 1500634
[22:20] <ubot5`> bug 1500634 in xorg-server (Ubuntu) "Rebuild Mir on upload" [Medium,Triaged] https://launchpad.net/bugs/1500634