| RAOF | You know, I wish I could have Mir on one monitor and X on another... | 00:48 |
|---|---|---|
| kdub | kgunn, that palatable workaround for the n7 works on all my devices, so I posted it for review | 01:35 |
| === duflu_ is now known as duflu | ||
| kgunn | kdub thanks! | 02:43 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Come for the feature addition, stay for the “hmm, that could really use a refactor” :/ | 03:38 |
| duflu | RAOF: You're not selling it | 03:45 |
| Sarvatt | RAOF: do you work for intel now? | 04:05 |
| 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:06 |
| RAOF | Oh, right. Our cross build support is broken in the presence of pkg-config. Huzzah. | 04:40 |
| RAOF | Ah. | 04:52 |
| RAOF | Which is why we reimplement it for all the libralies. | 04:52 |
| 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:14 |
| * duflu -> lunch | 05:15 | |
| RAOF | It'll be on the intarwebs. | 05:18 |
| Sarvatt | havent heard about recordings, only livestreams :( | 05:26 |
| Sarvatt | otherwise why am i up at 12:30 watching anholts lca talk on http://timvideos.us/ | 05:29 |
| RAOF | Sarvatt: Oh, is anholt on now? | 05:53 |
| Sarvatt | RAOF: http://timvideos.us/gentilli | 05:54 |
| * duflu wonders with so mean livestreams how much work will get done today | 06:19 | |
| duflu | (by himself) | 06:19 |
| duflu | -mean +many | 06:20 |
| * duflu also wonders why "mean" is in muscle memory | 06:20 | |
| duflu | Ugh, 7ms round-trip on N7 :( | 07:37 |
| 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:38 |
| duflu | Doing the smallest, lightest, operation I know of | 07:39 |
| RAOF | Also, damn annoying stupid partial-armhf-mostly-working-stupid-annoynig-annoyance. | 07:39 |
| RAOF | 7msec seems huge. | 07:42 |
| 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:46 |
| duflu | Although I suspect we can do significantly better than we do now | 07:47 |
| 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 | 07:48 |
| RAOF | Ok. What would it take to requrie an *actual* armhf chroot to cross-build Mir? | 08:02 |
| anpok | duflu: /o\ | 08:28 |
| duflu | anpok: ??? | 08:29 |
| anpok | a nothing .. just reading through and older geometry::PixelFormat-removal MP | 08:29 |
| anpok | s/and/an | 08:29 |
| 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:31 |
| anpok | ah back then those types were two separate enum.. | 08:34 |
| === 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 | ||
| 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! ;) | 15:31 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| * ogra_ hugs didrocks | 16:05 | |
| 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:06 |
| * 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:07 |
| ogra_ | bug 1258056 had its actual commit into devel on dec. 6th ... its just hilarious the process takes so long | 16:08 |
| ubot5 | bug 1258056 in Mir "nested mir on android fails on galaxy nexus" [High,Fix released] https://launchpad.net/bugs/1258056 | 16:08 |
| ogra_ | such a fix shouldnt take more than a week or two | 16:08 |
| === dandrader|lunch is now known as dandrader | ||
| mterry_ | ricmm, so image 119 will have new Mir! That means the libhybris patch should be the last thing blocking nested mode | 17:22 |
| ogra_ | mterry_, didnt the hybris fixes land long ago ? | 17:49 |
| 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:50 | |
| ogra_ | (tapping my feet) | 17:51 |
| 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:57 |
| 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 | 17:58 |
| === alan_g is now known as alan_g|EOD | ||
| ricmm | mterry_: manpower | 18:17 |
| ricmm | mterry_: today by EOD | 18:17 |
| 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:18 |
| * 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:19 |
| 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:38 |
| ogra_ | yeah, you seem on and off | 18:39 |
| mterry_ | ogra_, yah :( | 18:39 |
| ogra_ | freezing bits in the pipe ? :) | 18:39 |
| 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:43 |
| ogra_ | hmm, no, flashing the zip should be enough | 18:44 |
| ogra_ | how did you modify it ? | 18:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| ogra_ | not really | 18:49 |
| mterry_ | Well, I'll put this down for now and test my nested branch with newest Mir stack | 18:52 |
| ogra_ | ask stgraber how to better modify the zip | 18:53 |
| ogra_ | he surely knows | 18:53 |
| mterry_ | ogra_, OK | 18:53 |
| 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:16 |
| kgunn | or should i just top approve? | 21:17 |
| kdub | should have been addressed | 21:19 |
| kdub | r1317 in that branch | 21:20 |
| kgunn | kdub: ack....my bad (my bad eyes missed it) | 21:41 |
| anpok | do we have a new ci problem? the last two mp failed for the same unit test | 22:21 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| RAOF | robotfuel: https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/565/console suggests otherwise? | 22:29 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:35 |
| kdub | tested on my device here, seems it doesnt get to gtest_repeat=10 | 22:36 |
| 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:37 |
| kgunn | anpok: on your comment about "pick just one"...i'm confused...what do you mean ? | 22:38 |
| kgunn | anpok: ah...nvmd | 22:39 |
| kgunn | one currently | 22:39 |
| kgunn | got it | 22:39 |
| 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:40 |
| 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:41 |
| kdub | well, with gtest_repeat it fails, but thats almost expected... let me see how its running on the device... | 22:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| robotfuel | fginther: the mir-android-trusty-i386-build | 22:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| kdub | and if it is with the script, try regenerating the partial chroot the script makes | 22:54 |
| kdub | if your cross compile toolchain and the stl on the device get of sync, i've seen that cause problems before | 22:56 |
| anpok | ah, thank you. | 23:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!