[01:18] <kenvandine> RAOF, thanks
[01:24]  * bschaefer goes to eat dinner
[02:05]  * RAOF would quite like to be able to build mir :/
[02:13] <bschaefer> RAOF, it would help :(
[02:14] <bschaefer> RAOF, looks like the branch if failing on some protobuf stuff
[02:14] <RAOF> Yeah, things built wrong.
[02:14] <bschaefer> RAOF, hmm my error?
[02:14]  * bschaefer compiles fine on his machine
[02:15] <RAOF> Is your machine running wily? :)
[02:15] <RAOF> Slash wily-proposed?
[02:16] <bschaefer> RAOF, yes :)
[02:16]  * bschaefer wishes he wasnt
[02:16] <duflu> bschaefer: Workaround on mir-devel
[02:16] <bschaefer> duflu, for the proto issue?
[02:17] <duflu> Yep
[02:17] <bschaefer> duflu, do i just need to wait for it to merge into lp:mir?
[02:17] <duflu> bschaefer: I think we're waiting for protobuf to get rebuilt and re-released against the new C++ ABI of GCC5
=== chihchun_afk is now known as chihchun
[02:17] <bschaefer> duflu, cool i can just wait a little
[02:18] <bschaefer> people can still look at the code :)
[02:18] <duflu> bschaefer: You can still build it too. Just cmake .. -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_C_COMPILER=gcc-4.9
[02:18] <bschaefer> duflu, im building fine locally
[02:18]  * bschaefer is on proposed
[02:19] <bschaefer> duflu, just want to make jenkins happy :)
[02:19] <RAOF> Yeah, that needs to wait for the archive to work :)
[02:19] <duflu> Jenkins will be grumpy for some time yet. That's why I landed as much as possible by hand yesterday
[02:19] <bschaefer> haha, well that attestable cookie branch isnt a MUST LAND ASAP
[02:19] <bschaefer> soo i think it can wait
[02:20] <bschaefer> plus its ~3.9k in changes
[02:28] <duflu> bschaefer: Seems the list of unfinished ongoing transitions is now shorter, but still includes protobuf: http://people.canonical.com/~ubuntu-archive/transitions/
[02:29]  * bschaefer has never seen that site
[02:29] <duflu> New to me too
[02:29] <bschaefer> duflu, hopefully that means soon :)
[03:06] <duflu> RAOF: What's your regular deb build command (that conveniently avoided the test failure I was getting for so long)?
[04:37] <RAOF> duflu: Probably DEB_BUILD_OPTIONS="notest nocheck" sbuild -d wily --arch=armhf -j9
[05:11] <duflu> RAOF: notest nocheck sounds like a reasonable explanation. So I wasn't the only one seeing the failure, just the only one looking :)
[05:12] <RAOF> If it's what I'm thinking, the test fails because of a qemu deficiency, so it's not very useful to run.
[05:12] <RAOF> That's what the mako/arale is for.
[05:21] <duflu> RAOF: No, different (desktop) issue
[05:21] <RAOF> Oh, I think just debuild works for me, theer.
[05:22] <duflu> RAOF: Yes, it works, now. Didn't for quite a while; https://bugs.launchpad.net/mir/+bug/1483097
[05:22] <ubot5> Ubuntu bug 1483097 in Mir "Acceptance test fails under debuild: ClientCredsTestFixture.session_authorizer_receives_pid_of_connecting_clients" [Medium,Fix committed]
[05:23] <RAOF> Ah, it's possible that I've only ever built it with real root (in a sbuild chroot)
[05:53] <duflu> alf: Hello
[05:53] <alf> duflu: Hi!
[05:54] <duflu> alf: No exciting news to report other than wily doesn't build Mir right now :)
[05:57] <alf> duflu: Thanks. Has 0.14 landed for vivid+overlay? :P
[05:58] <duflu> alf: Not sure actually
[05:58] <duflu> I think it did. It was on arale. But mine might have been hacked
[06:00] <duflu> alf: Umm, yes seems to be on arale (which is running vivid)
[08:36] <alan_g> alf: welcome back. Hope you had a good break.
[08:43] <alf> alan_g: Thanks. I didn't manage to forget keyboard shortcuts, but it was good nonetheless :)
[08:56] <alan_g> You have to try harder (or longer) next time. ;)
[09:54] <alf> alan_g: @hack-mir_input-Thread-run-implementation, doesn't the proposed code only enable run() for benchmarks and unit-tests? Is that what we want?
[09:56] <alan_g> alf: Mmm. I guess that's everywhere we use it. (Which suggests there may be a more elegant solution.)
[09:59] <alan_g> Can you accept this version this while I look into that as a follow-up (to the series)?
[10:28] <alf> alan_g: Sure. It actually seems CommonInputThread is not used any more.
[10:28] <alan_g> alf: thanks for that observation - it lead me to a much better solution.
[10:29] <alf> alan_g: yw
[10:37] <greyback_> alf: hey, welcome back. When you get a chance, could you have a look over this doc and see if you agree with the premise: https://docs.google.com/document/d/10_Y04_TrmA_UV9BrObVGLm71jPlFKifBCt6v7YyMU7Q/edit
[10:37] <alf> greyback_: will do
[10:39] <alan_g> alf: @hack-mir_input-Thread-run-implementation - I've pushed the "better solution"
=== marcusto_ is now known as marcustomlinson
[11:23] <kdub> welcome back alf
[11:23] <alf> kdub: Thanks!
[11:32] <alf> greyback_: Is "scale" something that can be calculated from resolution and real display dimensions (which are already present in what Mir publishes), or something different?
[11:32] <greyback_> alf: different. It's user-configurable UI scaling
[11:34] <alf> greyback_: how does it affect Mir?
[11:34] <greyback_> alf: not at all
[11:34] <greyback_> well, it's probably a per-display setting
[11:35] <greyback_> so would be /nice/ if it was set & stored with the other per-display configurations
[11:35] <greyback_> but far from required
[11:35] <greyback_> it can be saved in gsettings too
[11:35] <alf> greyback_: so the idea is that whoever sets the display resolution will set it and then clients can access it from there
[11:35] <greyback_> right
[11:38] <alf> greyback_: do you see this as a unity8 specific setting or something more generally useful?
[11:39] <greyback_> alf: I think it's unity8 that would be the main consumer
[11:40] <greyback_> while most shells have to deal with HiDPI screen issues
[11:40] <greyback_> I think most have their own way
[11:40] <greyback_> but one thing I that might go hand-in-hand with this is: unity8 needs to know what scale each client is drawing at.
[11:41] <greyback_> as example, say I've a retina screen, and so gave set scale to "x2"
[11:42] <greyback_> I launch 2 apps, one is clever and reads the scale setting and scales its UI. Other app is old, unaware of scale, so draws at x1
[11:42] <greyback_> then it is the compositor's job to do (ugly) scale up of the old unscaled app
[11:42] <greyback_> so it's consistently sized
[11:42] <kdub> and input stack's job to map the input?
[11:43] <greyback_> kdub: yeah (Qt will manage it easily enough)
[11:43] <greyback_> with multimonitor, things get more complex
[11:44] <kdub> things always get more complex with multimonitor :)
[11:44] <greyback_> if I need mir clients to tell the server the scale they're drawing at, then it makes sense to add mir api for clients to read scale of the display
[11:45] <greyback_> that's my motivation, but I'm unity8 :)
[11:49]  * alan_g wonders if he can delete 10KLOC this week
[11:54] <greyback_> alf: do client API's need to be extended, or does unity8/qtmir need to extra code so that if the display configuration is changed by SystemSettings, that unity8 sets it's own base config to be the same?
[11:54] <greyback_> -'
=== alan_g is now known as alan_g|lunch
[12:19] <alf> greyback_: both could work, since unity8/qtmir have the pid from Mir's auth mechanism, but changing the API is the cleanest approach. Otherwise, you have a Mir client API call that acts differently depending on Unity8 internals.
[12:20] <greyback_> alf: well my concern is for non-system-settings apps using that api
[12:20] <greyback_> but you have a point
[12:21] <alf> greyback_: Well, the auth mechanism can deny all "change base config" requests that are not coming from system-settings
[12:22] <greyback_> yep
[12:25] <alf> alan_g|lunch: @deleting 10KLOC, a worthy goal :)
=== alan_g|lunch is now known as alan_g
[14:09] <kgunn> greyback_: silo 0 still hanging, expected ?
[14:10] <greyback_> kgunn: it just finished building, I've not checked yet
[14:13] <kgunn> greyback_: hmmm....apt cache policy showing older libmir*s
[14:13] <kgunn> will tinker a little
[14:13] <kgunn> oh wait, wrong term
[14:14] <kgunn> but yes...still unexpected libmircommon's installed
[14:15] <kgunn> and wrong u-s-c
[14:15] <kgunn> i used citrain
[14:15] <greyback_> did it actually do anything? Because it didn't for me, ubuntu-touch-session in the way
[14:16] <kgunn> greyback_: well, it downloaded them....
[14:16] <kgunn> is that what this means "E: There are problems and -y was used without --force-yes"
[14:16] <kgunn> it did say u-t-s would be downgraded
[14:16] <kgunn> at any rate, gonna use a hammer
[14:17] <greyback_> http://pastebin.ubuntu.com/12071338/ is my output, which results in no updates actualy installing
[14:18] <kgunn> same
[14:19] <greyback_> sigh
[14:19] <greyback_> damn thing crashing still
[14:24] <alan_g> alf: @10KLOC - I have MPs the deletes, now they just have to land.
[14:49] <greyback_> kdub: hey, I'm still having no luck with the external display being rotated on my N7 in silo0. Can you help?
[14:50] <greyback_> USC is resizing the surfaces to suit
[14:51] <greyback_> nothing is locking up (but unity8 is crashing for some reason)
[14:52] <kdub> wasn't n7's rotation strange somehow?
[14:56] <kgunn> greyback_: and do we need to rebuild u-t-s ?
[14:56] <greyback_> kgunn: probably
[14:56] <greyback_> kdub: nope
[14:57] <greyback_> same code used to work in n4 & n7 - unity8 did the rest just fine
=== chihchun is now known as chihchun_afk
[14:58] <kdub> i have a hazy memory that we had to rotate the n7 by 90deg or something
[14:58] <greyback_> kdub: yep, unity8 is looking after that
[14:59] <greyback_> kdub: if you can test silo0, I recommend you stop unity8, and see how USC looks on other display
[15:02] <greyback_> dumbass, no wonder qtmir was crashing, I forgot to merge the multimonitor handling code
[15:26] <kdub> greyback_, so wait for that to merge in then?
[15:27] <greyback_> kdub: if you stop unity8, you can still repro the issue just by looking at the spinner graphic
[15:27] <kdub> okay
[15:29] <greyback_> thanks. Sorry to have to pester you, but I've dug a bit and was unable to see why it's not happening
[15:36] <kdub> greyback_, sure, will look this afternoon
=== alan_g is now known as alan_g|EOD
[19:06] <popey> kgunn: is it possible to use a nexus 7 with a slimport and latest mir/unity etc, like the nexus 4?
[19:06] <kgunn> popey: in theory, if silo 0 wasn't still busted :)
[19:07] <popey> oh, its busted?
[19:07] <popey> that'll be why I have a black screen on my nexus 7 then
[19:07] <popey> is it fixable? I mean, downgrade something?
[19:07] <kgunn> popey: "fixable" ? like don't install it in the first place
[19:08] <kgunn> popey: black screen only when you plug it into slimport right ?
[19:08] <popey> heh
[19:08] <popey> no, it's black on internal display
[19:09] <popey> i had a devel image on it from ages ago (because we don't have newer ones on flo), added silo 0 and the overlay ppa
[19:09] <popey> dist-upgrade, reboot, black screen
[19:10] <kgunn> popey: huh....no hadn't seen  that
[19:10] <kgunn> popey: but i hand't tried n7 and i think kdub was gonna poke around on n7 today
[19:10] <popey> okay
[19:10] <popey> no worries, just wanted to play before the n4 arrived.
[19:12] <kdub> afaik, u8 needs to pull in a branch to stop that crash, and I sent a mir-fix to greyback__ that hopefully fixes the rotation issue
[19:15] <kgunn> kdub: what's the branch, just in case i can merge with lp:~mir-team/mir/silo0
[19:15] <kgunn> gerry might be off for the evening
[19:16] <greyback__> kgunn: I am, I can push current state which prevents the crash, but apps aren't drawing currently
[19:16] <greyback__> so it's not really worth rebuilding until I fugure that out tomorrow
[19:16] <kgunn> k