[02:22] fginther, so we have a good ppa? === racarr|lunch is now known as racarr [06:34] This makes me sad :( https://bugs.launchpad.net/ubuntu-power-consumption/+bug/1161212 [06:34] Launchpad bug 1161212 in unity (Ubuntu) "[regression] unityshell makes compiz wake up 190 times per second on an idle desktop" [High,New] [07:24] duflu: have you looked into it ? [07:24] duflu: this stuff is easy to regress when you don't have constant metrics [07:24] smspillaz: I don't look at such code any more [07:25] And so far have succeeded in not looking since releasing 0.9.9.0 [07:25] duflu: I'm only get 5.9 w/s [07:25] *getting [07:25] where is my english today [07:25] duflu: its still higher than it should be (should be around 0.3) [07:26] smspillaz: I didn't spend long looking at the default idle rate but it went at least as low as 13 [07:27] I was comparing it with Mir's new on-demand scheduling (which seems to work) [07:29] duflu: did you check the very first result from powertop ? [07:29] or after the first refresh [07:30] its around 190w/s on the first check, but I suspect that's because of all the repaint-flurry caused by loading powertop [07:30] after that it returns to a stable number [07:34] smspillaz: No it sits at 190 for several refreshes at least [07:35] Maybe I needed to give it a few minutes to come back down? Doesn't sound right [09:32] hey everyone, after yesterday's updates we need to update the unity tree in ../build_unity/unity [09:32] this can usually be done by ./build_unity -u [09:33] but this time: `bzr pull --overwrite -d ../build_unity/unity; ./build_unity` [09:33] that's because we rebased unity on lp:unity [09:57] dednick: hey, do you mind getting all your branches merged to trunk? [09:57] Saviq, is that perhaps the reason I'm getting "Error on creating style rule:..." for my test and the shell? [09:58] MacSlow, nope, that sounds like theming issues [09:59] didrocks: sure [10:00] thanks :) [10:04] dandrader, can you https://code.launchpad.net/~saviq/unity/phablet.revert-carousel/+merge/155919 [10:05] Saviq, ok. Will check it now [10:05] dandrader, cheers [10:14] Saviq, this crash, is it easy to reproduce? [10:14] dandrader, yeah, just search in the dash [10:14] dandrader, click on search in top panel [10:14] dandrader, type anything [10:14] dandrader, in people / music / video, not home / apss [10:14] apps [10:52] greyback, around? [10:52] Saviq: yep [10:52] greyback, can you mumble? [10:52] sure [10:52] 1 sec === dandrader is now known as dandrader|afk [11:17] didrocks, (not sure if you have answered - network issue) [11:23] davidcalle: not sure your ping even reached me ;) [11:23] but it seems not === dandrader|afk is now known as dandrader [11:24] didrocks: did you want me to merge with trunk (3255). there seems to be a daily release at 3254, but it's not mentioned in the changelog [11:25] dednick: where do you see a daily release shipped to distro? the last one I'm seeing is rev 3252 [11:25] Saviq, which dependency should I update to get rid of this? http://paste.ubuntu.com/5654895/ [11:26] dandrader, did you update unity? [11:26] dandrader, see above - `bzr pull --overwrite -d ../unity_build/unity; ./build_unity` [11:27] didrocks: ah. my bad. dont know how all this shipping things work. So what did you want me to merge at? 3255? [11:28] dednick: 3252, but I guess this was already done :) [11:28] dednick: the changelog is the authorative answer :) [11:28] didrocks: yeah. it was done a few days ago. ok [11:28] dednick: the merge back is done when we ship to distro [11:31] (meaning, tests are running) [11:31] dednick: like today, we have 40 failures on nvidia [11:31] dednick: I think it's due to a service failing, (the hud most of the time) and not respawning [11:31] so the tests are taking ages [11:31] and all timeouts [11:32] Saviq, ah, unity comes from lp:unity/phablet-mods now [11:32] dandrader, it always did, only we rebased on lp:unity [11:33] Saviq, hmm, it seems I was using bzr+ssh://bazaar.launchpad.net/~anjali-team/anjali/unity.trunk/ [11:33] dandrader, ah, that was before [11:33] didrocks: hm. ok. looks like the latest exp ppa ones are pretty good though. [11:33] dandrader, drop the whole of ../unity then [11:33] dandrader, to be sure, and ./build_unity -s [11:33] dednick: yeah, I'm talking about unity trunk ones [11:33] didrocks: sure [11:34] dednick: it's really "random crash of hud (especially on nvidia) -> everything fails" === tvoss is now known as tvoss|lunch [11:38] Saviq, any idea... although I did "bzr pull --overwrite -d ../unity_build/unity; ./build_unity" I'm still getting this with current lp:unity/phablet http://pastebin.ubuntu.com/5654917 [11:38] MacSlow, ./build, not straight cmake [11:38] MacSlow, and make sure you ./unity_build [11:39] MacSlow, that error means your UnityCore build failed [11:39] MacSlow, just drop ../unity_build [11:39] Saviq, ok... trying again [11:39] MacSlow, and go `./build_unity -s; ./build_unity` from a clean slate [11:42] Saviq, also took a first look at the notification-interface test... only found one minor thing [11:46] MacSlow, why do we need to test for that hint? [11:48] Saviq, just a suggestion... it is implicitly covered by the Type.Confirmation... still it has to be passed by clients, which intend to trigger a confirmation/synchronous notification [11:48] MacSlow, yes, an implementation detail that the shell does not need to know about [11:48] Saviq, ok [11:48] MacSlow, imagine we move away from libnotify at some point [11:49] MacSlow, we'd have to artificially set that hing [11:49] hint [11:49] Saviq, true... safer to hide it then [11:50] MacSlow, about that, what does the tint hint do? [11:51] Saviq, a way to indicate that the positive answer for a snap-decision is colored (Design wants this) [11:51] MacSlow, yeah, that's fine, just wanted to know what it does [11:51] Saviq, is meant to be reserved for "system-level" snap-decision... regular apps should not use that hint [11:52] MacSlow, k === MacSlow is now known as MacSlow|lunch === _salem is now known as salem_ === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:29] cyphermox, hey, do you think you could trigger a raring landing of the indicators stack? there is an indicator-sync fix in there I would like to see in raring before the freeze tonight [13:29] (that's the 3rd most reported issue on e.u.c/raring) [13:48] paulliu: just checking in, saw you had a feature branch based on unity/phablet, you able to build ok now? [13:49] kgunn: no..that doesn't builld [13:49] mhr3: \o/ [13:49] kgunn: I'm still checking. [13:51] paulliu: pastebin your build probs if you need to...lots of folks can help [13:51] kgunn: http://paste.ubuntu.com/5654866/ [13:52] kgunn: I've tried bzr pull --overwrite -d ../unity_build/unity; ./build_unity [13:52] kgunn: still not working. [13:52] paulliu: yeah...i had the same problem [13:52] paulliu: Saviq told me the same :) but the bzr pull didn't work for me either [13:52] kgunn: how did you solve your problem? [13:53] paulliu: i ended up rm -rf my unity-build dir [13:53] paulliu: then re-run ./build -s [13:53] paulliu: and that seemed to work [13:54] kgunn: ok, let me try it again. I thought I remove unity_build few hours ago. [13:54] didrocks, slangasek was asking yesterday why we don't plan to just publish the touch stack directly to raring. Apparently we have a standing FFe [13:55] mterry: [13:55] mterry: I'll talk to him, but reasons are: [13:55] - we depend on hud 2.0 which will break existing desktop infra [13:55] paulliu: yeah, try again...let me know how you get on [13:55] - I was busy with 100 scopes/in dash payment as I told him [13:55] kgunn: ok [13:55] - libhybris and such needs to build on all arch [13:57] didrocks, don't get your last comment, but OK. I do understand hud2 issue [13:57] didrocks, (Good EST morning btw! :) [13:58] hey mterry ;) [13:58] didrocks, regarding the touch stack, any issues with starting to enable some apps? gallery app should be good to go === alan_g|lunch is now known as alan_g [13:58] mterry: you are adding it to head/, right? [13:59] didrocks, no, let me add it to configs [14:00] didrocks, so raring is fully split off by now? [14:00] didrocks, should I add a new stack? touch-apps? [14:00] mterry: not fully split yet [14:00] I recall, we were considering "touch-platform", "touch-apps", and one more? [14:00] mterry: jibel is fixing a bug [14:01] mterry: we didn't decide on the stack, I was waiting for sergio to get a list before his holidays [14:01] what I didn't get btw [14:01] seb128: yeah, let's just make sure it's ok with didrocks [14:02] didrocks: indicator-sync landing ^ ?? [14:02] didrocks, I remember in the hangout, they said they split the packages along team lines. They had a team for platform, one for apps, and one for something else. That's where I got my idea I guess [14:02] cyphermox: good for me [14:02] mterry: yeah, there is an existing platform one, let's use that one [14:03] ok, I was just making sure with the branch changes and all [14:03] mterry: and add an apps one [14:03] sure [14:03] mterry: we'll figure out later moving stuff [14:11] didrocks, OK, pushed a bare new apps.cfg. I have it disabled via to_transition right now, but if you like it, we could try enabling it [14:11] didrocks, ? [14:12] mterry: you think it would build? [14:12] mhr3: on the "let's have the scope shutting down" :) [14:12] oh [14:12] i don't like it much though :P [14:13] :) [14:13] i'd rather have all python scopes in a single process and see how that works [14:13] something to try over the weekend i guess :) [14:13] paulliu, let me know if you have any issues [14:14] Saviq: ok. [14:14] Saviq: BTW, just pushed a new commit to the merge request. [14:14] paulliu, cheers [14:15] didrocks, is there any way to make bzr bd use parallel build? [14:16] didrocks, gallery-app? it should. It needs stuff not in the PPA to run... But it should build fine === tvoss|lunch is now known as tvoss [14:17] kgunn, ping [14:18] mhr3: --parallel in debian/rules (the dh line) [14:18] mterry: ok [14:18] didrocks, any envvar for that? not sure i'd want it permanent [14:19] mhr3, if the package can handle parallel build, why not always? [14:19] hmm [14:19] good point [14:19] :) [14:21] didrocks, and since we have time to clean up now, how can i remove/hide all unity_internal_* symbols from the so? [14:22] i remember there being a ldflag for it [14:23] or was that a libtool thing? [14:23] mhr3: it was a libtool [14:23] thing [14:23] that we used in dee IIRC [14:23] oh? /me checks [14:33] MacSlow: hey, could you rebase your notification branch to latest trunk?....the build is giving me fits since unity update is needed [14:33] didrocks, https://code.launchpad.net/~jibel/cupstream2distro-config/skip_downstream_task_if_no_project/+merge/155975 [14:33] jibel: thanks! [14:34] kgunn, I did that already and pushed 2 hours ago... rev 531 did you get that? [14:34] MacSlow: :) my bad....i was trying last night...will pull [14:46] Is the script run_on_device still meant to be the way to get the qml-phone-shell from the dev-machine cross-compiled, put on the phone and executed? [14:46] of course running "./run_on_device -s" first to get it all setup === tvoss is now known as tvoss|otp [14:50] MacSlow: yes [14:51] MacSlow: where are things going wrong on you? Does the setup succeed? [14:52] greyback, wait... jsut reflashed the phone... so it's missing rsync again [14:53] MacSlow: my usual procedure after a reflash is "phablet-network-setup -i, run_on_device -s" [14:53] MacSlow: phablet-network-setup [14:54] paulliu, come here btw [14:54] paulliu, http://pastebin.ubuntu.com/5655340/ [14:55] paulliu, we need a fix ApplicationManager.startProcess, though, to take the stage hint into account [14:55] Saviq: but now we don't have stage hint in daemon? [14:56] paulliu, yes, the ApplicationManager needs to read it and launch the app correctly [14:56] Saviq: ok.. Yes, since we have desktop file path in daemon, Qt should be able to parse the .desktop files. [14:57] paulliu, yeah, we just pass the desktop file name to the ApplicationManager and it should do its thing [14:57] ok. [15:01] mterry: did you look at why unity can't publish btw? [15:02] didrocks, guh, just more nvidia test failures. Went up by 30 [15:02] mterry: yeah, I think it's the hud failing again [15:02] mterry: so maybe try to restart it and get integration tests running? [15:02] mterry: I'm blocked on knowing if I should redeploy head or not yet for unity :) [15:02] k [15:03] I can restart no problem [15:03] didrocks, done; I wish these builds were more reliable [15:04] mterry: I wish as well :) [15:07] greyback, kgunn: working now again... mock notifications show up on the phone [15:07] cool [15:07] MacSlow: cool!...now break it :) [15:07] by adding more code that is :) [15:07] kgunn, nooooo :) [15:07] kgunn, sure [15:08] MacSlow: reminds me of my favorite bug ever....working on audio for a phone, a real user submitted a bug [15:08] MacSlow: saying after they submerged their phone in water [15:08] MacSlow: it didn't make any sound :) [15:09] kgunn, btw... I'm off tomorrow and Monday... forgot to mention that in standup [15:09] MacSlow: enjoy [15:09] kgunn, you honestly got that filed in your bug-db? [15:09] MacSlow: it was a classic :) [15:10] kgunn, as long as the phone wasn't meant to be water-proof, how can people expect that to work [15:10] MacSlow: i told them i fixed in sw & to please retest :) [15:10] kgunn, these days phone-hw is cheap anyway ;) [15:13] Saviq: been talking to kalikiana about dash blueprint work item "merge DeeVariantText into dee-qt" [15:14] but looks like it out of date in lp, branch superceded [15:14] is there something to be done? ....wonder if someone on strehl's team would need to own this? [15:15] kgunn, yeah, the superseding branch needs review/fixing/merging https://code.launchpad.net/~unity-team/dee-qt/deevarianttext-and-tests/+merge/153530 [15:17] kgunn, the tests there are most useful [15:17] kgunn, DeeVariantText... it depends whether GVariant string representation will be used anywhere passed to the shell [15:17] kgunn, but all in all, yeah, it's the API team that needs to own it [15:18] Saviq: thanks, i'll ping tstrehl [15:19] kgunn, the DeeVariantText does not even belong with dee either [15:19] kgunn, we just slapped it on because we needed it, and quick [15:19] Saviq: where's the best "conceptual" home? [15:20] kgunn, I don't think there is, yet, it would have to be some kind of qt<>gio compatibility layer === alan_g is now known as alan_g|tea [15:33] didrocks: you joining ? https://plus.google.com/hangouts/_/47a4dfa53a9b99896e07a788f1bdf66c07bafd01 [15:38] kgunn: sorry, 3 more minutes? [15:39] didrocks: :) sure...we'll just talk about you until you're here [15:40] paulliu, if you're still around (go to sleep) [15:41] Saviq: hmm.. [15:41] paulliu, we're in testing mode, so just look in tests/{unittests,qmluitests} [15:41] Saviq: ok === alan_g|tea is now known as alan_g [15:44] paulliu, so just find a component (start with the Components dir) [15:45] paulliu, that doesn't have tests [15:47] Saviq: Yeah. I can take that one. [15:48] Saviq: got it. [15:50] didrocks: you want to do tomorrow? i have something in 10 min [15:50] kgunn: just joining now [16:12] Trevinho: my obfsucated perl code!!! how dare you? :) [16:13] Trevinho: well, it's still in perl, so still obfuscated I guess :p [16:13] didrocks: eheh [16:13] didrocks: I wrote it in-line, for what it worth... Then I thought it could be easier to maintain it in that form, don't you think? :) [16:14] Trevinho: but but… I felt like a powa-user :-) [16:14] Trevinho: more seriously, yeah, way much better, thanks! [16:14] didrocks: you are [16:14] Trevinho: I hope you did the change on a Friday [16:14] Trevinho: that's my rule: always touching perl on a Friday :) [16:15] (evening for bonus points) [16:15] didrocks: ops, I was one day ahead :) [16:15] :p [16:15] Trevinho: more seriouly, the perl part looks good, I'll let someone else testing the rest :) [16:16] didrocks: ok, thanks [16:17] * Trevinho hates the change in DesktopAppInfo that needs a valid exec to return a valid GAppINfo.. [16:17] it makes testing so bad :/ [16:17] cyphermox: in case you didn't see: http://10.97.0.1:8080/view/cu2d/view/Raring/view/Indicators/ failure on the -check [16:17] dah [16:17] Trevinho: are we impacted a lot? [16:18] Trevinho: I had to fix some tests in libunity for that [16:18] didrocks: well, also in BAMF [16:18] Trevinho: it's in the 100scopes [16:18] branch [16:18] didrocks: yes, I've seen it [16:18] Trevinho: I'm using /bin/true as you saw then [16:18] didrocks: however in bamf changing the exec to /bin/true changes the world [16:18] don't think about a better way… [16:18] yeah [16:18] seb128 was proposing to eventually revert it ^ [16:18] if we have too many issues [16:19] for real world it's a good thing, but I don't like the fact that the app-info should be null... they could have been added just a getter [16:20] yep [16:20] Trevinho: do you think we'll get badly impacted, like what's your feeling? [16:20] should we revert this glib change [16:21] or just fix whatever we need to fix [16:21] didrocks: well, I was trying to fix the tests... And I can, but the actual result is different [16:22] didrocks: I mean, in BAMF we have that a .desktop file has less or more priority based on the fact that its name matches the exec basename, and this is broken by that on tests [16:22] Trevinho: ok, do you think it won't take too much of your time to fix that this release? [16:23] didrocks: I'm not sure how I can fix it :) [16:23] didrocks: let me check something [16:29] didrocks: ok, I've faked it adding a local program and changing the PATH during the test [16:30] Trevinho: sounds good to me === alan_g is now known as alan_g|afk [16:49] kenvandine: robru: mterry: cyphermox: so, FYI, apart from Unity, I redeployed everything. The "raring" view is now the one with daily releases. [16:50] didrocks, cool [16:50] cyphermox: the indicator has the new branches for the 13.04 branch enabled, I just disabled daily as I want for head to run a full time one first === alan_g|afk is now known as alan_g [16:50] kenvandine: robru: cyphermox: so, think about looking at the "raring" view now [16:51] and when upstream want to diverge trunk from a feature branch [16:51] hhttps://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Diverging_.22trunk.22_and_a_.22maintenance.22_branch [16:52] didrocks: cool [16:52] * cyphermox finishing up review of sil2100's branches [16:53] didrocks: symbols file for C++ ? [16:54] cyphermox: no, we can't have those :( [16:54] cyphermox: the symbols are different between archs [16:54] right, that's what I thought [16:54] just drop them [16:57] yep [17:04] sil2100: did you see my comments? [17:04] I'd like to see this land like, real soon [17:04] esp. given that we only have 4 more hours [17:14] didrocks, anything I can help with for 100scopes? You know, I can create that MIR bug for ya, take some paperwork off your back [17:14] mterry: ok, need to get you up to date with latest news [17:14] didrocks, oh boy news [17:22] sil2100: what PPA were you using to test the -qt stuff? [17:39] didrocks: seb128: I remember last physical UDS there was discussion around automated performance testing of Ubuntu core [17:39] do you have a system for that now? [17:40] no [17:40] I don't think much work went into that (yet) [17:40] :/ [17:40] ok [17:40] mhall119, try talking the the qa team maybe? [17:41] ok, thanks [17:48] cyphermox: ppa:sil2100/qt mostly === alan_g is now known as alan_g|wine === salem_ is now known as _salem [22:02] andy__ == andyrock?