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