[00:48] <RAOF> You know, I wish I could have Mir on one monitor and X on another...
[01:35] <kdub> kgunn, that palatable workaround for the n7 works on all my devices, so I posted it for review
[02:43] <kgunn> kdub thanks!
[03:38] <RAOF> Come for the feature addition, stay for the “hmm, that could really use a refactor” :/
[03:45] <duflu> RAOF: You're not selling it
[04:05] <Sarvatt> RAOF: do you work for intel now?
[04:06] <RAOF> Sarvatt: No, but I'm making sure my work-habits will be compatible if I do :)
[04:06] <Sarvatt> who needs to backport anything to a stable release? :P
[04:06] <Sarvatt> lol
[04:40] <RAOF> Oh, right. Our cross build support is broken in the presence of pkg-config. Huzzah.
[04:52] <RAOF> Ah.
[04:52] <RAOF> Which is why we reimplement it for all the libralies.
[05:14] <duflu> Speaking of Intel, keithp is in town and apparently giving a talk on zero-copy compositing this week. Pity I'm not registered, come to think of it
[05:15]  * duflu -> lunch
[05:18] <RAOF> It'll be on the intarwebs.
[05:26] <Sarvatt> havent heard about recordings, only livestreams :(
[05:29] <Sarvatt> otherwise why am i up at 12:30 watching anholts lca talk on http://timvideos.us/
[05:53] <RAOF> Sarvatt: Oh, is anholt on now?
[05:54] <Sarvatt> RAOF: http://timvideos.us/gentilli
[06:19]  * duflu wonders with so mean livestreams how much work will get done today
[06:19] <duflu> (by himself)
[06:20] <duflu> -mean +many
[06:20]  * duflu also wonders why "mean" is in muscle memory
[07:37] <duflu> Ugh, 7ms round-trip on N7 :(
[07:38] <duflu> And seemingly even longer latency between compositor schedule and composition starting
[07:38] <duflu> I blame the kernel 3.1 we have on the N7
[07:38] <RAOF> Where does the 7ms round trip come from?
[07:38] <duflu> RAOF: mirping
[07:39] <duflu> Doing the smallest, lightest, operation I know of
[07:39] <RAOF> Also, damn annoying stupid partial-armhf-mostly-working-stupid-annoynig-annoyance.
[07:42] <RAOF> 7msec seems huge.
[07:46] <duflu> RAOF: It's not terrible. Certainly better than the kernel of only a few years ago. And if we're smart about pipelining then it won't be a big issue
[07:47] <duflu> Although I suspect we can do significantly better than we do now
[07:48] <duflu> Because it takes at least 2 context switches for an input event to reach the client, and then at least 2 more for the resulting change to reach the screen
[08:02] <RAOF> Ok. What would it take to requrie an *actual* armhf chroot to cross-build Mir?
[08:28] <anpok> duflu: /o\
[08:29] <duflu> anpok: ???
[08:29] <anpok> a nothing .. just reading through and older geometry::PixelFormat-removal MP
[08:29] <anpok> s/and/an
[08:31] <duflu> anpok: Well, one type is better than N>1
[08:31] <duflu> Even if that one type is suboptimal in some use cases
[08:31] <duflu> Although I don't think that's true right now
[08:34] <anpok> ah back then those types were two separate enum..
[15:31] <didrocks> kgunn: Mir releasing as we speak FYI :)
[15:31] <kgunn> didrocks: thanks much! a nice coordinated effort once more :)
[15:31] <didrocks> kgunn: yeah! ;)
[16:05]  * ogra_ hugs didrocks 
[16:06] <ogra_> (and hopes it wont take 5 weeks anymore in the future with the new CI infra to get a commit show up in the image)
[16:07]  * didrocks hugs ogra_ back
[16:07] <didrocks> ogra_: well, as soon as we finished the pilot programm, I'm sure the Mir components will be in it
[16:07] <didrocks> (and so platform-api as well)
[16:07] <ogra_> yay
[16:08] <ogra_> bug 1258056 had its actual commit into devel on dec. 6th ... its just hilarious the process takes so long
[16:08] <ogra_> such a fix shouldnt take more than a week or two
[17:22] <mterry_> ricmm, so image 119 will have new Mir!  That means the libhybris patch should be the last thing blocking nested mode
[17:49] <ogra_> mterry_, didnt the hybris fixes land long ago ?
[17:50] <ogra_> i thought the Mir stuff was the last bit
[17:50]  * ogra_ is actually waiting with your branch in hands since monday to finally land it :)
[17:51] <ogra_> (tapping my feet)
[17:57] <mterry_> ogra_, tell me about it
[17:57] <ogra_> heh
[17:57] <mterry_> ogra_, to my knowledge, the hybris fix is still waiting to land in trusty.  Not sure why exactly
[17:57] <ogra_> hmpf
[17:57] <mterry_> ricmm, what's the blocker to landing the hybris fix?
[17:58] <ogra_> do you know who handles that ?
[17:58] <mterry_> ogra_, ricmm
[17:58] <mterry_> ogra_, he had a fix at the sprint in London
[17:58] <ogra_> ah
[18:17] <ricmm> mterry_: manpower
[18:17] <ricmm> mterry_: today by EOD
[18:18] <ricmm> I dodnt have a fix i had the idea of what was wrong, ultimately the fix is a bit different
[18:18] <ricmm> just havent had time to sit down with it, ill do that today
[18:18] <ricmm> so ogra can land it all tomorrow
[18:19]  * ogra_ hugs ricmm 
[18:19] <ricmm> can you tell him that when he returns?
[18:19] <ricmm> i need to grab some foods
[18:19] <ogra_> sure
[18:19] <ricmm> (:
[18:19] <ricmm> thanks
[18:38] <ogra_> mterry_, in case you missed it, ric said he will have the code ready for me so i can land it tomorrow
[18:38] <ogra_> (he asked me to forward that to you)
[18:38] <mterry_> ogra_, thanks!
[18:38] <mterry_> ogra_, I did miss it
[18:39] <ogra_> yeah, you seem on and off
[18:39] <mterry_> ogra_, yah  :(
[18:39] <ogra_> freezing bits in the pipe ? :)
[18:43] <mterry_> ogra_, I am trying to install a modified final image zip manually onto my mako, but my changes don't seem to be getting through once I flash.  Do you know any trick to it?  Like, is there an md5sum somewhere I need to update?
[18:44] <ogra_> hmm, no, flashing the zip should be enough
[18:44] <ogra_> how did you modify it ?
[18:46] <mterry_> ogra_, I added some debugging output to a qml file
[18:46] <mterry_> ogra_, inside the zip, there was a tar.gz, and I modified the files in that
[18:46] <ogra_> byond that its the normal rootfs ?
[18:47] <mterry_> ogra_, yeah
[18:47] <ogra_> hmm, i think that should work, though not sure, sisnce we use gpg signatures nowadays ... but i'm not sure we do on that level, stgraber should know
[18:48] <ogra_> (i would just modify the file on disk though)
[18:48] <mterry_> ogra_, problem is I'm trying to debug first boot
[18:48] <mterry_> ogra_, and I don't know a better way to get in there.  Do you?
[18:49] <ogra_> not really
[18:52] <mterry_> Well, I'll put this down for now and test my nested branch with newest Mir stack
[18:53] <ogra_> ask stgraber how to better modify the zip
[18:53] <ogra_> he surely knows
[18:53] <mterry_> ogra_, OK
[21:16] <kgunn> kdub: you gonna address alan_g's comment on arbitrary casting of ints to pointers comment on your fix for the snapshot flickers ?
[21:17] <kgunn> or should i just top approve?
[21:19] <kdub> should have been addressed
[21:20] <kdub> r1317 in that branch
[21:41] <kgunn> kdub: ack....my bad (my bad eyes missed it)
[22:21] <anpok> do we have a new ci problem? the last two mp failed for the same unit test
[22:25] <RAOF> robotfuel: What would I need to do to get an armhf schroot on the CI hardware?
[22:25] <kgunn> anpok: can you repro at all locally ? (e.g. repeat run an insane # of times)
[22:25] <robotfuel> RAOF: The builder?
[22:25] <RAOF> robotfuel: That'd do, I think.
[22:26] <robotfuel> RAOF: can you link to the failed job?
[22:26] <RAOF> robotfuel: The basic problem is that setup-partial-armhf-chroot has fundamental limitations that I'm running into.
[22:26] <anpok> kgunn: not today.. the n10 refused to charge, I put it on a different wall charger.. currently shows only the battery icon
[22:27] <robotfuel> RAOF: we are building arm natively
[22:27] <RAOF> robotfuel: Oh, I don't want access to the builder. I want the android tests to be run in a *real* armhf chroot, rather that the bailing wire and twine that we currently use.
[22:27] <robotfuel> RAOF: the android tests are being run on the phones
[22:27] <RAOF> robotfuel: So if I removed cross-compile-chroot.sh from the tree that *wouldn't* break CI?
[22:28] <kgunn> anpok: so, there was one bad mako when alf_ was looking into ci troubles before break...when that was taken out of cycle
[22:28]  * RAOF doesn't intend to remove cross-compile-chroot.sh, but boy would it be nice to thorourghly break it.
[22:28] <kgunn> it self corrected....it'd be interesting to see if its the same unit running
[22:28] <kgunn> those ci tests
[22:28] <kdub> RAOF, i wouldnt object to removing it
[22:28] <robotfuel> RAOF: we are building on Calxeda and then running the tests on the phones
[22:29] <RAOF> robotfuel: https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/565/console suggests otherwise?
[22:31] <kgunn> anpok: are you talking about failure on this jenkins run https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/226/console
[22:31] <anpok> yes
[22:31] <robotfuel> RAOF: that seems to be new, that is a pbuilder
[22:31] <anpok> one was kdubs screenshot fix, the other one was the removal of a android lib in the mir source..
[22:31] <RAOF> kdub: I wouldn't actually remove it, but I would replace it with something that uses a real armhf chroot, so we don't have to do all the munging. (And adding a udev dependency dramatically increases the amount of munging required)
[22:32] <anpok> so both on the .. android gpu test.. let me look again
[22:32] <anpok> ndroidGPUDisplay.gpu_display_ok_with_gles
[22:32] <anpok> C++ exception with description "error posting with fb device" thrown in the test body.
[22:34] <anpok> if I can trust the battery indicator... it is now fully charged..
[22:34] <anpok> and starts
[22:34] <anpok> will try
[22:34] <kgunn> anpok: just fyi...you can find the specific device name in the console output
[22:35] <kgunn> in this case it was device
[22:35] <kgunn> mako-04cb53b598546534
[22:35] <robotfuel> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/206/console shows that an arm(calxeda) server built the packages
[22:35] <robotfuel> RAOF: ^
[22:35] <kgunn> alf_:  curious if this is out special friend mako-04cb53b598546534
[22:35] <kdub> it just looks flaky to me
[22:36] <kdub> tested on my device here, seems it doesnt get to gtest_repeat=10
[22:37] <robotfuel> kdub:  it failed on mako-0090f741e3d141bc
[22:37] <robotfuel> oops kgunn^
[22:37] <RAOF> robotfuel: So, I'm trying to fix all the failures of https://code.launchpad.net/~raof/mir/mockable-udev/+merge/196824/comments/466002 . There is an actual problem there, which I can fix, but I can't fix the first failure in a sane way without requiring a real armhf chroot for that test.
[22:38] <kgunn> anpok: on your comment about "pick just one"...i'm confused...what do you mean ?
[22:39] <kgunn> anpok: ah...nvmd
[22:39] <kgunn> one currently
[22:39] <kgunn> got it
[22:40] <robotfuel> RAOF: Ah I was looking at the latest failure my bad
[22:40] <robotfuel> RAOF: I am not sure about the pbuilder, fginther can get you access
[22:41] <kdub> so it looks like something is failing, i can reproduce about 1/10 times on my device with that test case
[22:41] <RAOF> robotfuel: I don't need access (unless it's to persistently change the machine's configuration); I need a change in the build environment.
[22:41] <RAOF> robotfuel: Or, I guess, for us to drop that test run? Is it covering anything not covered by the other tests?
[22:42] <kdub> well, with gtest_repeat it fails, but thats almost expected... let me see how its running on the device...
[22:43] <robotfuel> RAOF: that has to be changed by the CI team, I don't know if they are using that pbuilder for other builds.
[22:43] <robotfuel> fginther: ping ^
[22:44] <fginther> robotfuel, RAOF, I was trying to follow, but I don't know exactly what the issue is
[22:44] <RAOF> Actually, if we've got a bunch of Caldexa nodes, why are we even doing that armhf build on i386?
[22:45] <fginther> RAOF, which build?
[22:45] <fginther> do you have a link to a job?
[22:45] <RAOF> http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/565/console
[22:45] <RAOF> (From https://code.launchpad.net/~raof/mir/mockable-udev/+merge/196824/comments/466002)
[22:46] <robotfuel> fginther: the mir-android-trusty-i386-build
[22:47] <fginther> RAOF, that's an intentional cross compile job (setup ages ago by mmrazik). If you go to the parent job, you'll see that there is a separate job to run on a calxeda node: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/344/
[22:47] <robotfuel> RAOF: it looks like vera++ needs to be added to the debian control as a build requirement for it to pass on mir-android-trusty-i386-build
[22:48] <RAOF> robotfuel: And libudev; but setup-partial-armhf-chroot.sh can't work properly with libudev.
[22:48] <robotfuel> RAOF: unless we can ignore the error "vera++ not available - disabling make target style_check"
[22:48] <RAOF> We do ignore that warning, yes. :)
[22:49] <RAOF> (Because libudev the first library we use that lives in /lib rather than /usr/lib)
[22:49] <RAOF> So, if we're already building and running the tests on android-armhf, is there any value in an explicit cross-compile test run?
[22:50] <robotfuel> RAOF: if we are telling people they can use an armhf pbuilder to build armhf builds in the documentation it is worth having. Other than that no.
[22:50] <fginther> RAOF, that would be up to the mir team. If the job is no longer needed, we can remove it.
[22:51] <anpok> kdub: how do you run the test cases on the device? mir/partial-armhf-chroot/usr/src/gmock/gtest/include/gtest/internal/gtest-port.h:1340:: pthread_mutex_lock(&mutex_)failed with error 22
[22:51] <RAOF> robotfuel: I'll fix up the cross-compile-chroot.sh to setup and use an armhf schroot, so that'll still work.
[22:52] <anpok> thats what I got with current devel.. a few weeks older binaries dont behave like that
[22:52] <kdub> anpok, i'm not seeing that with what I just built
[22:52] <anpok> thats a failure in gtest
[22:53] <anpok> i am obviously doing something horribly wrong
[22:53] <RAOF> fginther: Ok. I'll poke mir-devel@ to see if anyone is attached to that particular build.
[22:53] <kdub> anpok, if you're cross compiling, try compiling with the script
[22:54] <kdub> and if it is with the script, try regenerating the partial chroot the script makes
[22:56] <kdub> if your cross compile toolchain and the stl on the device get of sync, i've seen that cause problems before
[23:00] <anpok> ah, thank you.