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