[01:14] <kgunn> kdub: thanks for that update
[01:14] <kdub> kgunn, sure, will send at least one a day
[01:15] <rsalveti> ricmm: kgunn: I can easily give that a try tomorrow
[01:15] <rsalveti> I remember I did this once already when we had the black screen issue (using the kernel from 10.2 and such)
[01:15] <kgunn> kdub: ^
[01:16] <rsalveti> will do this first thing tomorrow :-)
[01:16] <rsalveti> just got back after driving for quite a few hours, food and bed :-)
[01:18] <kdub> ah great :) thanks rsalveti
[13:11] <racarr> MORNING
[13:12] <kgunn_> racarr, mornin'
[13:13] <alan_g> racarr: afternoon
[14:05] <didrocks> RAOF: around?
[14:05] <didrocks> RAOF: you only send me the xserver pacakge
[14:05] <didrocks> not the list of other package
[14:06] <didrocks> does it mean we only need to rebuild xserver?
[14:06] <didrocks> not the rest?
[14:06] <RAOF> didrocks: Oh. That's the only package that *I* need rebuilt.
[14:06] <didrocks> RAOF: the other doesn't dep on libmirclient2?
[14:06] <RAOF> No ABI changes for the drivers
[14:06] <RAOF> didrocks: No. The drivers depend only on the xmir module, which shelters them from mirclient ABI breaks.
[14:06] <didrocks> ah nice ;)
[14:06] <didrocks> excellent
[14:06] <didrocks> ok, I need to upload it in the ppa first
[14:07] <didrocks> RAOF: thanks
[14:28] <didrocks> kgunn_: do you know if RAOF will be back?
[14:28] <didrocks> kgunn_: xserver failed to build: https://launchpadlibrarian.net/151345408/buildlog_ubuntu-saucy-armhf.xorg-server_2%3A1.14.2.901-2ubuntu5_FAILEDTOBUILD.txt.gz
[14:28] <didrocks> (so everything's blocked in the ppa, unity8 and all dependencies)
[14:29] <didrocks> (it passed on amd64 and i386)
[14:30] <kgunn_> didrocks, he is at XDC which is portland OR i believe
[14:30] <didrocks> kgunn_: anyone else to help debugging what's wrong?
[14:31] <kgunn_> didrocks, in theory x should work on arm, can we make an exception to expidite mir update for touch....
[14:31] <didrocks> kgunn_: what do you mean by exception?
[14:31] <kgunn_> mlankhorst, ^ could you possibly help with building x for arm ?
[14:32] <didrocks> kgunn_: putting Mir in the release pocket isn't possible, it won't migrate because we can't keep libmirclient2 and libmirclient3 coinstallable
[14:32] <didrocks> (due to the common dependency)
[14:32] <didrocks> and we can't release libmirclient3 because of this issue
[14:33] <mlankhorst> kgunn_: seems like a libunwind bug or a compiler bug
[14:33] <mlankhorst> oh it's in the compiler :P
[14:34] <didrocks> nice ;)
[14:34] <didrocks> mlankhorst: why the compiler? because the "__aeabi_unwind_cpp_pr0" is there?
[14:35] <mlankhorst> might be it needs to link with g++, not gcc
[14:35] <mlankhorst> oh lets see
[14:37] <lool> it could be a link script issue
[14:38] <mlankhorst> libunwind should not have undefined references by itself, though...
[14:38] <RAOF> Yay armhf craziness!
[14:38] <didrocks> yeah, it's weird
[14:38] <didrocks> oh, a RAOF ;)
[14:38] <didrocks> RAOF: https://launchpadlibrarian.net/151345408/buildlog_ubuntu-saucy-armhf.xorg-server_2%3A1.14.2.901-2ubuntu5_FAILEDTOBUILD.txt.gz for context
[14:39] <RAOF> didrocks: Yeah, just saw my email.
[14:39] <mlankhorst> any recent libunwind upload I can blame that one on? :P
[14:39] <RAOF> Yeah, what have we changed?
[14:39] <RAOF> Because that bit's *not* changed since 0ubuntu4, which built.
[14:39] <mlankhorst> actually there is..
[14:39] <didrocks> https://launchpad.net/ubuntu/saucy/+source/libunwind/1.1-2ubuntu3
[14:39] <mlankhorst>   * d/patches/fix-lzma-linking.patch: Include lzma when linking arm, arm64
[14:39] <mlankhorst>     and ppc32 libunwind, fixing FTBFS.
[14:40] <didrocks> https://launchpad.net/ubuntu/saucy/+source/libunwind/1.1-2ubuntu2
[14:40] <didrocks> yeah
[14:40] <didrocks> those 2
[14:40] <RAOF> And by “fixup pkg-config configuration” we might mean “break X” :)
[14:40] <kgunn_> :)
[14:42] <mlankhorst> https://launchpad.net/ubuntu/+source/libunwind/+publishinghistory
[14:43] <didrocks> - libunwind_la_LIBADD += -llzma
[14:43] <didrocks> and then +Libs.private: @LIBLZMA@
[14:43] <didrocks> I don't see how this interferes with what we are seeing?
[14:43] <mlankhorst> no it doesn't, but there has been another pload
[14:43] <mlankhorst> upload*
[14:44] <RAOF> Also added --enable-minidebuginfo to the configure flags.
[14:44] <mlankhorst> worst case I guess the act of rebuilding triggered it :P
[14:49] <lool> --enable-minidebuginfo is pretty suspicious indeed
[14:50] <lool> came in latest merge from Debian in 1.1-2ubuntu1
[14:56] <didrocks> mlankhorst: RAOF: kgunn_: do you have any idea on this? quite lost TBH
[14:56] <RAOF> Is anyone trying a rebuild with a previous libunwind?
[14:57] <mlankhorst> didrocks: I wouldn't be surprised if it simply happened because of toolchain changes. :P meh I have no builder atm
[14:57] <didrocks> RAOF: I don't think anyone is trying that
[14:58] <kgunn> RAOF: are you thinking rollback on toolchain is required ?
[14:59] <RAOF> kgunn: I'm just wondering if that's the problem. If it is then either rollback or fix is the way forward.
[14:59] <kgunn> ah...just a test
[15:07]  * RAOF sees whether xorg-server will build under qemu
[15:18] <RAOF> Someone should write a parallel automake, so I could at least get 4 slow armhf-emulated processes rather than one. :)
[15:22] <didrocks> :)
[15:35] <lool> so I've rebuilt xorg-server on my nexus4
[15:35] <lool> reproduced the failure
[15:35] <lool> then I downgraded libunwind and tried to continue the build, and it seems to have past the point where it was failing
[15:36] <lool> I downgraded to libunwind8 + -dev in version 1.1-1ubuntu2
[15:36] <lool> RAOF: ^
[15:36] <lool> did someone ping doko / James?
[15:38] <RAOF> lool: My build against 1.1-1ubuntu2 looks to be completing in sbuild, too. I don't think anyone's pung doko or James.
[15:40] <RAOF> Yup, X seems to have got all the way through to the test suite.
[15:40] <lool> it's not done here, but it keeps going
[15:40] <lool> RAOF: let's move this to ubuntu-devel@
[15:41] <lool> err #ubuntu-devel
[15:45] <davmor2> RAOF: if you have all this speed up through parallel builds when do you get time to practise you sword fighting http://xkcd.com/303/
[16:04] <roman2861> Hello. Anybody here?
[16:06] <alan_g> Only us
[16:07] <RAOF> And the fish god.
[16:07] <roman2861> :D
[16:08] <roman2861> So, i have a problem - Mir doesn't works on manta (Nexus 10). Will somebody fix it? And may I dream about Mir on Nexus 10 in near future? Or only after 1.0 release?
[16:09] <kgunn> roman2861: so i know there's a branch up for it...https://code.launchpad.net/~kdub/mir/mali-client-render-support/+merge/185603
[16:10] <kgunn> not sure it works completely...but...works-ish
[16:10] <alan_g> kgunn: should that be linked to bug 1203268?
[16:12] <roman2861> ubot5: Yes, I'm am Zonov Roman, who created this bug. But bug is 2 month old. And i really want to see Mir on my Nexus 10 :)
[16:29] <kdub> roman2861, give it... 3 or so weeks, i'm close to getting it working
[16:29] <kdub> give or take ;-)
[16:30] <roman2861> Thank you! Your info is great!
[17:12] <dholbach> hiya
[17:13] <dholbach> on a galaxy nexus, the power button to lock the screen does not work with mir any more... is that a known issue?
[17:13] <RAOF> Yeah.
[17:13] <dholbach> do we have a bug open for it?
[17:13] <dholbach> is that the same on all devices?
[17:14] <RAOF> Works on N4, although maybe not on the images.
[17:14] <RAOF> That's DPMS support.
[17:14] <dholbach> gotcha
[17:15] <RAOF> Someone was working on it, but I don't think it's being considered a blocker.
[17:16] <racarr> Yep. I hear kdub is working on it in the process of updating our HWC bits
[17:16] <racarr> hopefully once that is finished it should work with no more mir changes.
[17:16] <kdub> racarr, yeah... hwc might need some more patches though
[17:17] <kdub> for the galaxynexus
[17:17] <racarr> Mm.
[17:18] <dholbach> 1193222 I think
[17:20] <racarr> Yes. The bug status is a little out of date I guess
[17:21] <racarr> it's fixed on N4, but the API we use from the drivers isn't working on gnexus
[17:21] <ogra_> did someone tell ricmm ? i think he is still working on a powerd fix for this
[17:22] <racarr> ogra_: Yeah we are in sync, the deal is
[17:22] <ogra_> awesome
[17:22] <racarr> mir has to be the one to actually turn the screen off due to some...intricacies of the android APIs. so unity will publish a dbus api
[17:22] <racarr> for powerd
[17:22] <racarr> Which is just about to land here: https://code.launchpad.net/~gerboland/unity-mir/add-screen-blank/+merge/187028
[17:22] <ogra_> yeah
[17:25] <racarr> afk, 20 minutes or so
[17:41] <RAOF> didrocks: Ba baw!
[18:11] <davmor2> kgunn: Next app that is playing up.  http://paste.ubuntu.com/6151221
[18:11] <davmor2> kgunn: again is this just general changes or an xmir issue?
[18:12] <RAOF> *Probably* not an xmir issue.
[18:13] <RAOF> Although it's particularly easy to tell from that.
[18:13] <davmor2> RAOF: ah so is it best to point these at you?  It'll just be little snippets like this that I can gleam from the terminal start of the app
[18:15] <RAOF> davmor2: You're welcome to filter them through kgunn, but it'll probably filter down to me anyway :)
[18:15] <RAOF> davmor2: Does that work without xmir?
[18:18] <davmor2> RAOF: I'm going to go back over any that didn't work due to gfx issues latter on without xmir and then again on nvidia ruling out the intel driver and xmir but that won't be till I've hit the other 880+ apps
[18:19] <RAOF> davmor2: Ok.
[18:21] <davmor2> RAOF: too much time taken with all the reboots,  I don't think I'm going to get everything done as it is and I started a fortnight earlier :/
[18:21] <RAOF> !!!
[18:23] <davmor2> RAOF: Migration testing of the 960 commercial applications from raring to Saucy.  Quantal to raring took nearly 4 weeks for 600 apps and I didn't have to stay on top of the current queue at that time, this time I have it's not going to plan :D
[18:43] <kgunn> kdub: you gotta branch for me to try ? n4 flicker
[18:45] <kdub> kgunn, just getting the tests in order atm
[18:46] <racarr> 20 minutes...wasn't true :p
[18:46] <racarr> back now though
[18:49] <racarr>  ill get my n4 ready for testing too :)
[21:20] <robert_ancell> kgunn, I'm completely confused by what https://code.launchpad.net/~kgunn72/mir/changlog-update-0.0.11-for-mirserver/+merge/187070 is trying to do...
[21:22] <rsalveti> kdub: were you able to solve the flicker issue?
[21:23] <rsalveti> was just waiting the kernel + cm build with the other display stack here
[21:24] <kgunn> robert_ancell: well, basically it was to bump the so name & in turn the build deps from
[21:24] <kgunn> u-s-c, unity-mir, & platform-apu
[21:24] <kgunn> or api even
[21:24] <robert_ancell> kgunn the packaging has gone from 0.0.10 to 0.0.11 and Mir is still on 0.0.10 (see CMakeLists.txt)
[21:24] <robert_ancell> and no sonames were changed
[21:25] <kgunn> robert_ancell: so much for didrocks guiding me through it :)
[21:25] <kgunn> robert_ancell: so, they landed mir today with no issue...but i guess that's cause they forced a build
[21:25] <robert_ancell> kgunn, yeah, I'm mostly confused by all the people approving it who should know what this change means!
[21:28] <kgunn> robert_ancell: so for future reference...i would need to make a corresponding change to cmake....anything else?
[21:29] <kdub> rsalveti, was able to solve! have a mir branch, and patches for cm-10.1 n4 hwcomposer
[21:30] <kgunn> robert_ancell: hmmm, so interesting question...if unity-mir, usc, plat-api are all expecting .11...is it because they use >=
[21:30] <kgunn> kdub: what!?!?
[21:30] <robert_ancell> kgunn, I think the idea is so a dependent package can depend on mir (>= 0.0.11) right?
[21:30] <ChickenCutlass> kdub, that is great news
[21:30] <rsalveti> kdub: what was the issue then?
[21:30] <kgunn> did you and rsalveti end up with simultaneous soln's
[21:30] <robert_ancell> kgunn in that case, update "set(MIR_VERSION_PATCH 10)" in CMakeLists.txt and the debian/changelog
[21:31] <kgunn> robert_ancell: right...but i am saying they (usc, unity-mir) expect version 11 from their control file...
[21:32] <kgunn> robert_ancell: therefore they are using a >= scheme
[21:32] <kgunn> robert_ancell: and this is why 0.0.10 actualy works for them ??
[21:32] <robert_ancell> kgunn, right, but if you asked any code inside Mir what version it was, it would say 0.0.10 (in this case I don't think there's anything that would break)
[21:32] <kgunn> (its really a question not a statement :)
[21:32] <kdub> rsalveti, 1) we were relying on the vsync 'heartbeat signal' instead of having hwc's set arrange the sync
[21:33] <kdub> so that's what the hwc patch is for
[21:33] <kgunn> robert_ancell: ok...so, question is, do we need to correct the cmake file and can we do so without issue ?
[21:33] <robert_ancell> kgunn, this is a side effect of having the version number defined in two places - once in the build system and once in the debian packaging
[21:33] <kdub> and the 2) the shell is an 'internal client' and takes a bit of a different path than the ipc based clients. we were missing waiting on a fence for the internal clients only
[21:33] <kgunn> robert_ancell: or...do we just wait for the next bump
[21:33] <robert_ancell> kgunn, we *should*, but in practise we can probably just live with it for now
[21:34] <kdub> and thats what the mir branch is for
[21:34] <rsalveti> kdub: right, cool, let me know once you have the cm related patches in hands
[21:34] <rsalveti> so I can upload a new android package
[21:35] <kdub> rsalveti, i'll send them after i double check they work okay with surfaceflinger... no reason they shouldn't but safer to double check
[21:36] <rsalveti> kdub: if you send me know I can do a local build and test
[21:36] <rsalveti> with sf
[21:36] <rsalveti> *now
[21:38] <kdub> rsalveti, sure
[21:40] <kdub> rsalveti, sent an email with the patch
[21:40] <rsalveti> thanks, let me try that
[21:49] <olli_> this is exciting news gentlemen!
[21:57] <rsalveti> kdub: working just fine
[21:59] <kdub> rsalveti, great!
[22:00] <kdub> i kinda want to coordinate that patch going into the phablet build at about the same time as https://code.launchpad.net/~kdub/mir/fix-1215979/+merge/187346
[22:00] <kdub> would minimize disruption to the mir devs working on the n4
[22:01] <kdub> not aware of a way to check against a phablet build version when packaging mir
[22:03] <rsalveti> well, you can dep/build-dep against the android version
[22:03] <rsalveti> there's a package for it now
[22:03] <rsalveti> kdub: there's a conflict in https://code.launchpad.net/~kdub/mir/fix-1215979/+merge/187346
[22:04] <kdub> fixing... a minute or two
[23:00] <kgunn> hey racarr ...in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone, there are like 3 stage items...are those all just enabling side stage
[23:25] <rsalveti> kdub: seems your mr works fine in here
[23:25] <rsalveti> just got a unity8 crash, but that is not related
[23:25] <rsalveti> not with this change at least
[23:25] <kdub> yeah, the unity8 crash is something else... racarr, know anything about that?
[23:27] <kdub> (i know some races were fixed last week, might be what we're seeing)
[23:44] <kdub> just noticed there's a 'review type' field now in lp... handy