| kenvandine | RAOF, thanks | 01:18 |
|---|---|---|
| * bschaefer goes to eat dinner | 01:24 | |
| * RAOF would quite like to be able to build mir :/ | 02:05 | |
| bschaefer | RAOF, it would help :( | 02:13 |
| 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:14 | |
| RAOF | Is your machine running wily? :) | 02:15 |
| RAOF | Slash wily-proposed? | 02:15 |
| 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:16 |
| 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 | 02:17 |
| === chihchun_afk is now known as chihchun | ||
| bschaefer | duflu, cool i can just wait a little | 02:17 |
| 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:18 | |
| 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:19 |
| bschaefer | plus its ~3.9k in changes | 02:20 |
| duflu | bschaefer: Seems the list of unfinished ongoing transitions is now shorter, but still includes protobuf: http://people.canonical.com/~ubuntu-archive/transitions/ | 02:28 |
| * bschaefer has never seen that site | 02:29 | |
| duflu | New to me too | 02:29 |
| bschaefer | duflu, hopefully that means soon :) | 02:29 |
| duflu | RAOF: What's your regular deb build command (that conveniently avoided the test failure I was getting for so long)? | 03:06 |
| RAOF | duflu: Probably DEB_BUILD_OPTIONS="notest nocheck" sbuild -d wily --arch=armhf -j9 | 04:37 |
| 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:11 |
| 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:12 |
| duflu | RAOF: No, different (desktop) issue | 05:21 |
| RAOF | Oh, I think just debuild works for me, theer. | 05:21 |
| 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:22 |
| RAOF | Ah, it's possible that I've only ever built it with real root (in a sbuild chroot) | 05:23 |
| duflu | alf: Hello | 05:53 |
| alf | duflu: Hi! | 05:53 |
| duflu | alf: No exciting news to report other than wily doesn't build Mir right now :) | 05:54 |
| alf | duflu: Thanks. Has 0.14 landed for vivid+overlay? :P | 05:57 |
| duflu | alf: Not sure actually | 05:58 |
| duflu | I think it did. It was on arale. But mine might have been hacked | 05:58 |
| duflu | alf: Umm, yes seems to be on arale (which is running vivid) | 06:00 |
| alan_g | alf: welcome back. Hope you had a good break. | 08:36 |
| alf | alan_g: Thanks. I didn't manage to forget keyboard shortcuts, but it was good nonetheless :) | 08:43 |
| alan_g | You have to try harder (or longer) next time. ;) | 08:56 |
| 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:54 |
| alan_g | alf: Mmm. I guess that's everywhere we use it. (Which suggests there may be a more elegant solution.) | 09:56 |
| alan_g | Can you accept this version this while I look into that as a follow-up (to the series)? | 09:59 |
| 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:28 |
| alf | alan_g: yw | 10:29 |
| 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:37 |
| alan_g | alf: @hack-mir_input-Thread-run-implementation - I've pushed the "better solution" | 10:39 |
| === marcusto_ is now known as marcustomlinson | ||
| kdub | welcome back alf | 11:23 |
| alf | kdub: Thanks! | 11:23 |
| 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:32 |
| 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:34 |
| 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:35 |
| alf | greyback_: do you see this as a unity8 specific setting or something more generally useful? | 11:38 |
| greyback_ | alf: I think it's unity8 that would be the main consumer | 11:39 |
| 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:40 |
| greyback_ | as example, say I've a retina screen, and so gave set scale to "x2" | 11:41 |
| 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:42 |
| greyback_ | kdub: yeah (Qt will manage it easily enough) | 11:43 |
| greyback_ | with multimonitor, things get more complex | 11:43 |
| 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:44 |
| greyback_ | that's my motivation, but I'm unity8 :) | 11:45 |
| * alan_g wonders if he can delete 10KLOC this week | 11:49 | |
| 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_ | -' | 11:54 |
| === alan_g is now known as alan_g|lunch | ||
| 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:19 |
| greyback_ | alf: well my concern is for non-system-settings apps using that api | 12:20 |
| greyback_ | but you have a point | 12:20 |
| alf | greyback_: Well, the auth mechanism can deny all "change base config" requests that are not coming from system-settings | 12:21 |
| greyback_ | yep | 12:22 |
| alf | alan_g|lunch: @deleting 10KLOC, a worthy goal :) | 12:25 |
| === alan_g|lunch is now known as alan_g | ||
| kgunn | greyback_: silo 0 still hanging, expected ? | 14:09 |
| greyback_ | kgunn: it just finished building, I've not checked yet | 14:10 |
| 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:13 |
| kgunn | but yes...still unexpected libmircommon's installed | 14:14 |
| 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:15 |
| 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:16 |
| greyback_ | http://pastebin.ubuntu.com/12071338/ is my output, which results in no updates actualy installing | 14:17 |
| kgunn | same | 14:18 |
| greyback_ | sigh | 14:19 |
| greyback_ | damn thing crashing still | 14:19 |
| alan_g | alf: @10KLOC - I have MPs the deletes, now they just have to land. | 14:24 |
| greyback_ | kdub: hey, I'm still having no luck with the external display being rotated on my N7 in silo0. Can you help? | 14:49 |
| greyback_ | USC is resizing the surfaces to suit | 14:50 |
| greyback_ | nothing is locking up (but unity8 is crashing for some reason) | 14:51 |
| kdub | wasn't n7's rotation strange somehow? | 14:52 |
| kgunn | greyback_: and do we need to rebuild u-t-s ? | 14:56 |
| greyback_ | kgunn: probably | 14:56 |
| greyback_ | kdub: nope | 14:56 |
| greyback_ | same code used to work in n4 & n7 - unity8 did the rest just fine | 14:57 |
| === chihchun is now known as chihchun_afk | ||
| 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:58 |
| greyback_ | kdub: if you can test silo0, I recommend you stop unity8, and see how USC looks on other display | 14:59 |
| greyback_ | dumbass, no wonder qtmir was crashing, I forgot to merge the multimonitor handling code | 15:02 |
| kdub | greyback_, so wait for that to merge in then? | 15:26 |
| greyback_ | kdub: if you stop unity8, you can still repro the issue just by looking at the spinner graphic | 15:27 |
| kdub | okay | 15:27 |
| 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:29 |
| kdub | greyback_, sure, will look this afternoon | 15:36 |
| === alan_g is now known as alan_g|EOD | ||
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:15 |
| 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 | 19:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!