[06:09] <didrocks> Mirv: hey, how are you?
[06:11] <duflu> smspillaz: I am calling the new dev series 0.9.10 unless you want to change the theme...
[06:16] <Mirv> didrocks: hello, fine, just "jetlagged" from the daylight saving time switch..
[06:18] <didrocks> Mirv: :) I started qtcreator this morning to follow http://developer.ubuntu.com/resources/app-developer-cookbook/mobile/currency-converter-phone-app/
[06:18] <didrocks> Mirv: rather jasoncwarner poked me about it :)
[06:18] <didrocks> Mirv: I don't have "Qt Quick UI" in the new project dialog
[06:18] <didrocks> only Qt Quick 1 UI
[06:18] <didrocks> any idea what I'm mising?
[06:19] <didrocks> missing*
[06:22] <Mirv> didrocks: possibly some Quick 2 dependencies like qtdeclarative5-dev qtdeclarative5-qtquick2-plugin. only ubuntu-sdk depends on everything needed, so as not to pull everything for qtcreator installers who want mainly Qt 4 development
[06:22] <didrocks> Mirv: I installed ubuntu-sdk though?
[06:23] <didrocks> Mirv: both of those are installed for me
[06:23] <didrocks> qtdeclarative5-dev qtdeclarative5-qtquick2-plugin
[06:23] <didrocks> Mirv: any other idea? way to debug this :)
[06:23] <Mirv> didrocks: ok if you have ubuntu-sdk, then it's not about packages. it might be about Qt Creator old configuration and/or concurrent installation of qt4-qmake - https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1135336
[06:24] <Mirv> so one needs to either configure Qt Creator to have it note the Qt5 if it didn't do that automatically, or reset the configuration
[06:25] <didrocks> Mirv: ok, I have qt4-qmake installed, how can I reset my configuration?
[06:25] <Mirv> didrocks: if you want to keep qt4-qmake installed, resetting does not help (Qt Creator will autoconfigure itself again to Qt4-only) but you need to configure Qt Creator manually
[06:26] <Mirv> didrocks: to reset, see the "Automatically fixing Qt Creator settings by resetting configuration" in bug report
[06:26] <Mirv> to keep qt4-qmake and add Qt5 configuration, see the manual route
[06:27] <didrocks> Mirv: I don't really calls this rm automatic but well :-)
[06:27] <didrocks> Mirv: indeed, I have it now, any ETA once you will get something to fix it?
[06:27] <duflu> didrocks: May I make "0.9.10" the active dev series for lp:compiz?
[06:27] <didrocks> duflu: sounds good to me
[06:28] <Mirv> didrocks: it's automatic in the sense of not going into configuration dialogs of Qt Creator. the problem seems complex, and upstream seems to lack proper reconfiguration of itself in case system changes.
[06:29] <didrocks> Mirv: any way we can workaround it?
[06:29] <Mirv> the Qt4 preference could be maybe fixed, though
[06:29] <duflu> didrocks: I don't have permission :(
[06:30] <didrocks> duflu: sam should I guess?
[06:30] <didrocks> Mirv: ok, so now I have the same issue than jason…
[06:30] <Mirv> didrocks: I've one idea of trying to find how the upstream detects /usr/bin/qmake-qt4 and make it prefer whatever is symlinked at /usr/bin/qmake. it'd only affect first runs however.
[06:30] <didrocks> Mirv: Starting /usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene /home/didrocks/CurrencyConverter/CurrencyConverter.qml
[06:30] <duflu> didrocks: No it's pspmteam
[06:30] <didrocks> QQmlComponent: Component is not ready
[06:32] <didrocks> Mirv: so my error? Following the tutorial, it's exactly what Jason is getting as well. Any idea?
[06:32] <Mirv> didrocks: I haven't heard about that problem, CurrencyConverter seems to continue starting for me
[06:32] <didrocks> Mirv: we both have only distro and not the ppa
[06:32] <Mirv> and I have only distro packages
[06:33] <duflu> mmrazik, didrocks, Mirv: Could one of you please change the "Development focus" to "0.9.10"? https://launchpad.net/compiz
[06:33] <mmrazik> duflu: ack
[06:33] <didrocks> Mirv: seems there is a package missing then, if at least 2 persons can reproduce it, do you want a bug report?
[06:33] <mmrazik> duflu: done
[06:34] <duflu> mmrazik: Thanks
[06:34] <Mirv> didrocks: yes, although I'm not sure against which project if it's now the new ubuntu-sdk that may be giving problems
[06:34] <duflu> Lots of people have permission, but I don't :)
[06:34] <Mirv> didrocks: the new ubuntu-sdk meta package is also missing the ubuntu plugin, and I should contact loic about it
[06:35] <Mirv> didrocks: if you come up with a package to file the bug against, please tell me so that I can also file bugs..
[06:35] <didrocks> Mirv: I can help debugging, but I think it's something you should track
[06:36] <Mirv> ubuntu-touch-meta I think?
[06:36] <didrocks> Mirv: just tell me what I should do to get more info for you
[06:36] <didrocks> Mirv: as basically, on relatively fresh install, following the tutorial doesn't work
[06:40] <didrocks> Mirv: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1158246
[06:44] <Mirv> I'm trying to ask some SDK people if they've an understanding of the problem. weird that I don't have even the warning showing up.
[06:46] <Mirv> it seems at least clear that David would need to update the tutorial
[06:46] <Mirv> didrocks: it's probable that there are no missing dependencies, though. I compared the new ubuntu-sdk to the old and it seems good enough.
[06:49] <didrocks> Mirv: can we ensure in the future that the sdk team is working with David to update the tutorial when they change their API?
[06:52] <Mirv> didrocks: yes, API changes are already something that needs to be carefully handled from now on. I'll mention this again to bzoltan.
[06:53] <didrocks> Mirv: thanks
[06:53] <didrocks> Mirv: you will tell dpm to make the update?
[06:53] <didrocks> Mirv: also, we need more integration tests I guess
[06:54] <Mirv> didrocks: pinging him as well
[06:54] <didrocks> Mirv: thanks a lot, keep me posted on the qt4-qmake stuff :)
[06:54] <Mirv> didrocks: ok
[07:17] <didrocks> duflu: FYI: https://code.launchpad.net/~vanvugt/compiz/back-to-raring/+merge/156459/comments/342220
[07:19] <duflu> didrocks: I kept the 0.9.9 branch as the target because all later branches need a common ancestor that can be found for merging
[07:19] <duflu> Would just adding to the changelog be enough?
[07:20] <didrocks> duflu: yeah, so dch -i (keep UNRELEASED)
[07:20] <didrocks> duflu: and add the marker line with the last common rev
[07:24] <duflu> didrocks: What is "the marker line" ?
[07:25] <didrocks> duflu: "Automatic snapshot from revision xxx"
[07:26] <duflu> Oh comment
[07:26] <didrocks> duflu: it's what you need to put in the new changelog
[07:26] <duflu> didrocks: Yep. And version still "daily" ?
[07:30] <didrocks> duflu: yeah, don't care about the version, just let what dch -i has set
[07:30] <didrocks> (check you do have UNRELEASED preferably)
[07:31] <duflu> Done
[07:32] <didrocks> duflu: no
[07:32] <didrocks> duflu: yo ureally need to write the Marker in changelog
[07:32] <didrocks> so instead of: The last common revision was r3629
[07:33] <didrocks> you need to set * Automatic snapshot from revision 3629
[07:33] <didrocks> duflu: as the workflow is screwed anyway, we'll probably get some bugs listed twice in the changelog in the end, but oh well…
[07:40] <Saviq> Cimi, come here, btw
[07:40] <Saviq> Cimi, one good thing happened - we're building for raring, too ;)
[07:40] <Cimi> Saviq, ok
[07:41] <tsdgeos> so we won against CI in the phablet-mods-cherrypick at last :D
[07:44] <Cimi> tsdgeos, Albert, did you manage to upgrade to raring with unity?
[07:44] <tsdgeos> Cimi: sure
[07:45] <Cimi> tsdgeos, do-release-upgrade -d?
[07:45] <Saviq> hey tsdgeos
[07:45] <tsdgeos> Cimi: i did a plain s/quantal/raring in my /etc/apt/
[07:45] <tsdgeos> Saviq: hi
[07:46] <Cimi> tsdgeos, I heard the world will collide on that
[07:46] <tsdgeos> maybe
[07:46] <tsdgeos> it worked for me (TM)
[07:46] <Cimi> tsdgeos, (I'm scared of out dozens of PPAs)
[07:46] <Cimi> *s/out/our/g
[07:47] <tsdgeos> Cimi: ah, well, i only have the autopilot one, the phablet-tools one and the phablet-desktop one
[07:48] <duflu> didrocks: Done. Maybe. I think....
[07:48] <Cimi> guys here will break unity
[07:48] <Cimi> I will upgrade, uninstalling maybe unity and X
[07:49] <Cimi> will be back asap!
[07:50] <didrocks> duflu: good!
[07:50] <duflu> Argh, not enough whitespace
[07:50] <duflu> Do we care?
[07:51] <didrocks> duflu: no, that's fine
[07:51] <didrocks> you will maybe get a double [ Daniel…]
[07:51] <didrocks> that's all
[07:51] <didrocks> in the changelog automated generation
[07:51] <didrocks> (you didn't need to add it btw)
[07:51] <didrocks> just as I told:
[07:51] <didrocks> dch -i
[07:51] <didrocks> -> edit to add the marker line
[07:51] <didrocks> was enough
[07:51] <didrocks> no need to bump the changelog or anything ;)
[07:52] <duflu> It was confusing. Because you were asking me to create incorrect information (wrong date)
[07:53] <mmrazik> didrocks: should we have libindicate in head/indicators.cfg? And what about the daily release? (I'm just doing some cleanup of jobs that were not yet migrated to cupstream2distro-config)
[07:54] <didrocks> mmrazik: libindicate is deprecated
[07:54] <didrocks> mmrazik: so better to leave it die
[07:54] <didrocks> duflu: ?
[07:54] <didrocks> duflu: you don't care about the date
[07:54] <didrocks> duflu: it's bumped when doing a daily release
[07:54] <mmrazik> didrocks: do you mind if I create a "deprecated" release then?
[07:54] <duflu> didrocks: I always care about accuracy. And I don't yet understand how/what is automated...
[07:54] <mmrazik> i.e. it would live in stacks/deprecated/indicators.cfg
[07:54] <duflu> If anything else needs fixing, let me know
[07:55] <didrocks> duflu: well, if you were accurate, then /raring would become 0.9.9 as we shipped it as it
[07:55] <didrocks> mmrazik: I don't really like it as there is no commit since 2012-09-07, what would that be used for?
[07:56] <didrocks> mmrazik: I prefer we avoid too many "releases" view
[07:56] <mmrazik> didrocks: to generate the "new-style" autolanding jobs instead of maintaining the "old style" (aka non based on cupstream2distro-config)
[07:56] <didrocks> mmrazik: don't autoland it anymore
[07:56] <mmrazik> didrocks: ok
[07:56] <didrocks> mmrazik: if something is committed to it, it's an error, so better to detect it that way :)
[07:56] <mmrazik> ack
[07:59] <mmrazik> didrocks: regarding too many release views -- you probably won't like this then: https://code.launchpad.net/~mrazik/cupstream2distro-config/community/+merge/156479
[08:00] <mmrazik> the issue is that we already accidentally deployed the jobs on the wrong jenkins
[08:00] <didrocks> mmrazik: urgh, yeah, let's keep all that in head
[08:00] <mmrazik> didrocks: its in phablet/ right now
[08:00] <mmrazik> didrocks: in that case I'll just move it to a different branch TBH
[08:00] <didrocks> mmrazik: we are going to remove phablet in the end
[08:00] <didrocks> mmrazik: everything in head
[08:00] <didrocks> once bootstrap
[08:01] <didrocks> with stack names
[08:01] <didrocks> mmrazik: so if it's only transitory, fine by me, we should just coordinate when moving one project after another
[08:01] <mmrazik> didrocks: its not really transitory. the config as such is most likely here to stay. But the autolanding/ci jobs are running on different jenkins
[08:02] <mmrazik> http://91.189.93.125:8080/
[08:02] <mmrazik> so they are a bit different
[08:02] <didrocks> mmrazik: will we be able to move them to a head/<stack>?
[08:02] <mmrazik> didrocks: we can add something to the yaml file so the deployment tool is a bit more intelligent and knows where to deploy
[08:02] <didrocks> (stack will probably not be a one to one mapping as waiting for sergio on giving feedback here)
[08:02] <didrocks> mmrazik: yeah, I think this will be needed
[08:02] <mmrazik> didrocks: ok. then let me reject that MP
[08:03] <didrocks> thanks mmrazik :)
[08:03] <didrocks> mmrazik: oh, btw, today I'm working with francis to just have one autopilot jenkins job
[08:03] <didrocks> I've done the prepatory job on my side to pass everything in a parameter
[08:03] <mmrazik> didrocks: yup. I've seen the MP yesterday
[08:04] <mmrazik> didrocks: thanks for doing it. It was on my TODO but not too high :-/
[08:04] <didrocks> mmrazik: no worry, it's kind of needed for me now that we have release/ and head/ anyway ;)
[08:04] <didrocks> so that we don't double the number of jobs
[08:11] <tsdgeos> Saviq: do you specially want boiko's review in https://code.launchpad.net/~saviq/unity/phablet.rename-phone-icon/+merge/155944 ? Or can i just go ahead and approve it
[08:11] <tsdgeos> ?
[08:11] <Saviq> tsdgeos, go on
[08:15] <tsdgeos> Saviq: so what's the plan in the lisview serach crash, are we reporting a Qt bug upstream?
[08:15] <Saviq> tsdgeos, yeah, we need to dig in, unless we can find a simple way to reproduce
[08:15] <tsdgeos> oka
[08:16] <Saviq> would be best to fix, of course ;)
[08:16] <Saviq> tsdgeos, do you remember if that crash was similar to what we had before the Carousel?
[08:17] <Saviq> tsdgeos, IIRC it was
[08:17] <tsdgeos> similar in nature yes, don't really remember the backtrace to be honest
[08:28] <tsdgeos> do you guy know how to get "x86_64-linux-gnu"? i.e. the part that gets appended to /usr/lib/ when installing [some] libs?
[08:29] <tsdgeos> get from a bash script that is
[08:34] <Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity/phablet.fix-hud-build/+merge/156486
[08:34] <tsdgeos> ah that :D
[08:35] <tsdgeos> Saviq: i just approved https://code.launchpad.net/~dandrader/unity/phablet_hud_build/+merge/156402 you'll probably have to "rebase" into it
[08:35] <tsdgeos> i think it's too late to stop autolanding
[08:35]  * tsdgeos checks
[08:35] <didrocks> tvoss: did you see that?  http://kentonv.github.com/capnproto/
[08:36] <tvoss> didrocks, nope, reading into it, thanks for pointint out
[08:36] <Saviq> tsdgeos, let's supersede dandrader's
[08:38] <Saviq> tsdgeos, I've stopped autolanding for it
[08:38] <tsdgeos> oka
[08:40] <tsdgeos> Saviq: fwiw this still won't make ./run work
[08:40] <Saviq> tsdgeos, huh?
[08:40] <Saviq> tsdgeos, does, here
[08:40] <tsdgeos> need to find out how to make this better
[08:40] <tsdgeos> Saviq: http://paste.ubuntu.com/5669827/ i need this
[08:41] <tsdgeos> let me try again
[08:41] <Saviq> actually let me try
[08:41] <tsdgeos> Saviq: make sure you kill your uity_build stuff
[08:41] <tsdgeos> hud is installing into "new paths"
[08:41] <Saviq> tsdgeos, yeah, need to drop the  prefix
[08:41] <tsdgeos> so you may be using the old one
[08:42] <Saviq> tsdgeos, some of it might be not needed post https://code.launchpad.net/~pete-woods/hud/cmake-cleanup/+merge/156488
[08:42] <tsdgeos> Saviq: you mean my lib-paths or some of your changes?
[08:42] <Saviq> tsdgeos, mine
[08:43] <Saviq> tsdgeos, yours shouldn't be needed
[08:43] <duflu> didrocks: Hmm, no autolanding since it's not lp:compiz any more? :)
[08:43] <tsdgeos> Saviq: but i need them :D
[08:43] <Saviq> tsdgeos, sure, but they should not be needed ;)
[08:43] <tsdgeos> Saviq: why you say they shouldn't?
[08:43] <didrocks> duflu: oh, right, as we changed the branch, we need to change the stack configuration file
[08:43] <Saviq> tsdgeos, local install shouldn't install in multiarch
[08:43] <didrocks> duflu: normally, you should coordinate that with mterry though, let me do it for this time…
[08:44] <Saviq> tsdgeos, I _think_
[08:45] <tsdgeos> Saviq: the only thing the local_install thing does in hud does afaik is install some gconf files to the local dir instead of always trying to put them in /usr
[08:45] <tsdgeos> don't see why local_install should disable multiarch
[08:46] <tsdgeos> i mean you could still have two archs in your local path, no?
[08:48] <didrocks> mmrazik: rev 135, (for the raring release)
[08:48] <didrocks> duflu: ^
[08:49] <duflu> didrocks: OK, thanks
[08:51] <Saviq> tsdgeos, pushed a fix
[08:51] <Saviq> tsdgeos, should be fine now
[08:51] <tsdgeos> goodie :-)
[08:52] <mmrazik> didrocks, duflu: can the autolanding jobs wait for couple of hours (for fginther)?
[08:52] <mmrazik> didrocks: the unity stack is (I believe) not yet on cupstream2distro-config
[08:52] <mmrazik> but it looks like fginther already did some work there
[08:52] <didrocks> mmrazik: fine with me
[08:52] <duflu> mmrazik: Yep
[08:53] <mmrazik> ok. I'll drop an e-mail to fginther so its not forgotten
[08:53] <didrocks> duflu: the 0.9.9 branch is safe for raring, right?
[08:53] <didrocks> duflu: we can land that without any fear
[08:53] <duflu> didrocks: After my proposal it is identical to lp:compiz/raring (plus changelog additions)
[08:53] <duflu> Not sure about before
[08:54] <didrocks> duflu: hum, so you mean, we shouldn't use it for raring?
[08:54] <didrocks> duflu: I understood you wanted us to use it
[08:54] <duflu> didrocks: Sorry, yes. Both are raring-friendly
[08:54] <didrocks> and that you tested it
[08:54] <didrocks> duflu: ah ok, so we are switching on that one
[08:54] <duflu> didrocks: I only diff'd it to make sure there's no diff
[08:54] <didrocks> ok :)
[08:54] <didrocks> thanks duflu
[08:55] <didrocks> Trevinho: hey, did you fix the FTBFS due to the bamf tests vs new glib?
[08:55] <didrocks> Trevinho: I don't see it in the vcs
[08:56] <didrocks> Trevinho: also, I guess cyphermox asked you to add an entry to the vcs for rev 525
[08:57] <Saviq> tsdgeos, pushed another tweak to take https://code.launchpad.net/~pete-woods/hud/cmake-cleanup/+merge/156488 into account (will review that hud change, unless you want to take over?)
[09:00] <tsdgeos> Saviq: i can take it and approve both at the same time if you want
[09:00] <Saviq> tsdgeos, sure, works for me
[09:00] <tsdgeos> oki
[09:06] <Saviq> tsdgeos, pushed a change to rm -Rf $BUILD_DIR if --clean is passed to unity_buld
[09:06] <Saviq> +i
[09:07] <tsdgeos> ok
[09:10] <Saviq> tsdgeos, aaand... two more commits (init CLEAN to false and add -c/--clean to ./build, too)
[09:10] <tsdgeos> :D
[09:11] <Saviq> tsdgeos, sorry :)
[09:11] <Saviq> tsdgeos, that should be the last of it
[09:12] <tsdgeos> Saviq: "initialize CLEAN to false in clean_unity" is a typo and you meant build_unity, no?
[09:12] <Saviq> tsdgeos, yes
[09:16] <tsdgeos> Saviq: do we really need two different bzr clean-tree calls?
[09:16] <Saviq> tsdgeos, unfortunately, yes
[09:16] <tsdgeos> weird
[09:16] <Saviq> tsdgeos, let me verify
[09:16] <Saviq> tsdgeos, yes
[09:16] <Saviq> tsdgeos, --ignored deletes _only_ ignored
[09:16] <tsdgeos> ah
[09:16] <tsdgeos> i see
[09:17] <Saviq> ah wahy
[09:17] <Saviq> --unknown --ignored
[09:17] <Saviq> tsdgeos, will fix
[09:17] <tsdgeos> ok
[09:19] <tsdgeos> mzanetti: you there?
[09:20] <Saviq> tsdgeos, he's off until the 4th
[09:20] <tsdgeos> oki
[09:20] <Saviq> tsdgeos, fixed
[09:50] <tsdgeos> Saviq: i'm approving https://code.launchpad.net/~saviq/unity/phablet.add-coding-import-path/+merge/155259 i guess kgunn forgot to top approve?
[09:50] <Saviq> tsdgeos, or didn't feel powerful enough ;)
[09:52] <tsdgeos> :D
[09:52] <tsdgeos> ok
[10:00] <kgunn> tsdgeos: Saviq ...you mean i can approve stuff ...watch out ;)
[10:01] <Saviq> kgunn, jeez man, don't you sleep?
[10:01] <kgunn> Saviq: like an old man...early :)
[10:05] <tsdgeos> Saviq: where do i get Unity.Notifications for https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests/+merge/155914 ?
[10:05] <tsdgeos> or is this just a "mockup" MR?
[10:06] <Saviq> tsdgeos, isn't the description... descriptive... enough?
[10:06] <Saviq> tsdgeos, generally we want to try this approach where we (shell UI) write tests like that
[10:07] <Saviq> tsdgeos, that fail initially, that will drive the shell-facing Unity APIs
[10:07] <Saviq> tsdgeos, i.e. a merge of Unity APIs for Notifications needs to make those tests pass
[10:08] <tsdgeos> Saviq: who reads descriptions nowadays....
[10:08] <tsdgeos> :D
[10:08] <tsdgeos> Saviq: then i think we should be running them
[10:08] <Saviq> tsdgeos, ;)
[10:08] <tsdgeos> but using the fail keyword
[10:08] <tsdgeos> so that when they actually pass they fail and we have to turn the test on
[10:09] <tsdgeos> not sure if that last sentence made any sense
[10:09] <tsdgeos> it made inside my head
[10:09] <Saviq> tsdgeos, kind of did
[10:09] <Saviq> tsdgeos, we can do that under qmltestrunner?
[10:10] <tsdgeos> i'm hoping
[10:10] <tsdgeos> let me check
[10:11] <tsdgeos> Saviq: yep
[10:11] <tsdgeos> expectFail as in the QtTest C++ side
[10:11] <tsdgeos> expectFailContinue is probably what we want
[10:13] <Saviq> tsdgeos, yeah, but we can't even load that QML yet
[10:13] <tsdgeos> ah right
[10:13] <Saviq> tsdgeos, 'cause of missing imports
[10:13] <tsdgeos> ok
[10:14] <tsdgeos> let's just not forget to turn the tests on later :D
[10:14] <Saviq> tsdgeos, yeah, part of the actual implementation MP :)
[10:43] <Saviq> paulliu1, you around?
[11:38] <paulliu1> Saviq: yeah.
[12:12] <didrocks> fginther: hey, once you are around! :)
[13:08] <MacSlow> Is it possible to only select a sub-range of a model to be passed to a ListView/Repeater etc?
[13:22] <didrocks> hey davidcalle!
[13:23] <davidcalle> didrocks, hey :)
[13:25] <didrocks> davidcalle: small question: what is blocking the publishing to the certified ppa is that we don't have one project for each scope
[13:25] <didrocks> davidcalle: do you know when you will create them?
[13:27] <davidcalle> didrocks, hmm. I should have time for that between tonight and tomorrow (catching up on my other job backlog this week)
[13:27] <didrocks> davidcalle: tracking list: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/experimental/100scopes.cfg
[13:27] <didrocks> davidcalle: thanks!
[13:27] <davidcalle> didrocks, np ;)
[13:28] <didrocks> davidcalle: not sure if we can screenscrap with the 2 factors auth to batch the creation easily
[13:29] <davidcalle> didrocks, the client side list is still quite small, I'll do it manually.
[13:29] <didrocks> davidcalle: ok ;)
[13:32] <Saviq> dandrader, standup?
[13:33] <dandrader> Saviq, ah yeah sorry!
[13:33] <Saviq> dandrader, that's fine
[13:34] <dandrader> Saviq, damn. resinstalled  my machine yesterday (now on 13.04). I still have still mumble though :(
[13:34] <dandrader> s/still/install
[13:34] <Saviq> dandrader, sure, we're going, join when ready
[13:42] <didrocks> fginther: still not around? ;)
[13:43] <fginther> didrocks, good afternoon. just finishing up something
[13:44] <didrocks> fginther: ok, tell me once you are ready ;) (I'll be away for an hour in 15 minutes, would be nice to sync before)
[13:44] <fginther> didrocks, in that case, let's start
[13:44] <didrocks> fginther: so, basically my changes worked with the daily release
[13:44] <didrocks> so oif/indicators are passing the right parameters
[13:45] <fginther> good
[13:45] <didrocks> fginther: I think merging both are quite easily, they should be exactly the same now
[13:45] <didrocks> easy*
[13:45] <didrocks> fginther: I guess, the question is unity and the 100scopes unity one
[13:45] <didrocks> and how they can use the same job with indicator/oif
[13:46] <didrocks> fginther: the 100scope is unity with another ppa instead, so already covered as we'll pass the ppa parameter
[13:46] <fginther> didrocks, the autopilot-release jobs are all created from the template with no manual changes, correct?
[13:47] <didrocks> mmrazik: ^
[13:47] <didrocks> fginther: but the unity ones are different than the oif/indicators one
[13:47] <didrocks> fginther: for me the unity one should have:
[13:47] <didrocks> - a ppa parameter
[13:47] <didrocks> - no package set (so empty parameter)
[13:48] <didrocks> - the tests can be provided as "unity" for autopilot
[13:48] <didrocks> so basically a "check with whole ppa" with ont test: unity, which is launchpad all autopilot unity tests?
[13:48] <mmrazik> didrocks: fginther: can you rephrase the question for me? I don't understand what is being asked
[13:49] <fginther> didrocks, yes 'unity' == all autopilot tests
[13:52] <didrocks> fginther: so, how can I help you? We should maybe create a new generic autopilot job from scratch
[13:52] <didrocks> for all cases
[13:52] <didrocks> and plugging in the different cases?
[13:53] <fginther> didrocks, I think building up from the oif and indicators test shouldn't be too hard
[13:53]  * fginther starts to see the differences
[13:54] <didrocks> fginther: ok, do you want to hang out, or having a first pass and we continues from there?
[13:54] <didrocks> fginther: would be nice to do it today so that we can move on then
[13:55] <didrocks> jibel: small question, the distribution of tests results per <release>/<stack>/<config> is done by the -check job, right? nothing linked to autopilot jobs (if we are going to only use one for all releases/stacks, it's fine?)
[13:55] <fginther> didrocks, I think I can do a first pass, let me discuss some with marting
[13:56] <didrocks> fginther: great!
[13:58] <jibel> didrocks, correct. Precisely it is done by cu2d-autopilot-report which is called in the last build step of -check jobs.
[13:59] <didrocks> jibel: excellent, that's what I read, but I was double checking (I change a little bit the -check job yesterday)
[13:59] <didrocks> jibel: thanks!
[13:59] <jibel> yw
[14:03] <MacSlow> Saviq, that was an easy fix... works now
[14:03] <Saviq> MacSlow, cool :)
[14:12] <Saviq> dandrader, you wrote the Stage tests, can you please have a look at the test I've added in https://code.launchpad.net/~saviq/unity/phablet.apps-lens-real-installed/+merge/156571
[14:12] <Saviq> dandrader, I'm out of ideas why it fails
[14:13] <dandrader> Saviq, sure. doing it now
[14:16] <Cimi> build -s doesn't work in raring
[14:16] <Cimi> I mean, immediately
[14:16] <Cimi> probably requires extra deps
[14:19] <tsdgeos> Cimi: what error do you get?
[14:19] <MacSlow> Is there a way to obtain the default value of an item-property, say Button.color in QML?
[14:20] <Cimi> tsdgeos, I'm rerunning it now
[14:20] <tsdgeos> MacSlow: you mean the original property before you changed it? as far as i know no
[14:20] <MacSlow> tsdgeos, yes
[14:21] <Marlinc> https://docs.google.com/a/mms-projects.net/spreadsheet/viewform?formkey=dHdFV2Fyd0xnRU52a2o0TWg1Z1VRZVE6MQ
[14:21] <MacSlow> tsdgeos, hm... then how can I conditionally assign a value instead?
[14:24] <tsdgeos> MacSlow: unless the Button.color provides you a way to get the original color the only easy way i can think of is a Component.onCompleted JS to get the original color and store it yourself
[14:24] <tsdgeos> and then just color: boolean ? myColor : originalColor
[14:24] <tsdgeos> seems a bit lame to be honest :D
[14:24] <MacSlow> tsdgeos, ok... wanted to avoid that... but if that's the only way... so be it :) thx
[14:24] <Cimi> tsdgeos, hud doesn't have autogen.sh
[14:25] <gusch> paulliu: ping
[14:26] <dandrader> Saviq, the screenshot components are being replaced by tst_Stage.qml. That's why changes made to their real implementations won't affect the test
[14:26] <dandrader> Saviq, see tst_Stage.qml lines 164 - 173
[14:26] <Saviq> dandrader, ah, /me faile
[14:26] <Saviq> -e
[14:27] <Saviq> dandrader, right
[14:27] <Saviq> dandrader, thanks, makes perfect sense
[14:27] <paulliu> gusch: hi
[14:27] <Saviq> dandrader, I will talk to the internal Fake ones, then :)
[14:27] <gusch> paulliu: what is "X-Ubuntu-Touch=true" in the desktop file doing?
[14:28] <paulliu> gusch: We will use that field to filter out the apps that is for phone only.
[14:28] <gusch> paulliu: ok - thx - approving
[14:28] <paulliu> gusch: So the app lens on phone will only provide those apps with -true.
[14:28] <paulliu> gusch: wait.
[14:28] <paulliu> gusch: I'm adding debian/changelog.
[14:28] <paulliu> gusch: for image.
[14:28] <gusch> paulliu: ah - ok
[14:28] <gusch> paulliu: but then there is one file you could remove
[14:29] <gusch> paulliu: debian/gallery-app.links
[14:29] <gusch> paulliu: as that adds links (was introduced for the renaming)
[14:30] <gusch> paulliu: but these links will cause the gallery to appear twice (as there are 2 .desktop files then)
[14:30] <gusch> paulliu: so please remove that old compatibility file as well
[14:30] <dandrader> Saviq, and no need to use findChild to get the screenshots as they're properties
[14:30] <paulliu> gusch: ok
[14:30] <Saviq> dandrader, yeah see that now
[14:30] <gusch> paulliu: thx
[14:36] <paulliu> gusch: https://code.launchpad.net/~paulliu/gallery-app/desktop_file_tweak/+merge/156548
[14:37] <paulliu> gusch: thanks.
[14:37] <tsdgeos> Cimi: right it doesn't
[14:38] <tsdgeos> Cimi: are you up to date in unity/phablet?
[14:38] <gusch> paulliu: why do you bumt the version number twice?
[14:39] <paulliu> gusch: dch -> debcommit -> bzr rm -> dch -> debcommit. So it is twice.
[14:40] <didrocks> fginther: ok, I couldn't take any break :( I'll take it after the team meeting, any progress/things we can test?
[14:40] <gusch> paulliu: can you merge them (even manually)?
[14:40] <paulliu> gusch: yeah. sure. wait.
[14:41] <fginther> didrocks, not yet. I'm still trying to finish up another task.
[14:41] <mterry> didrocks, kenvandine just asked me to update the unity recommends on the gwibber lens to the friends one.  But unity doesn't recommend it, gwibber does.  If I update this recommends, will there be a mismatch between gwibber's data source and the lens's data source (friends)?
[14:41] <mterry> didrocks, I'm asking you because kenvandine is on holiday  :)
[14:42] <didrocks> mterry: in the next release, with 100scopes, unity will recommends everything
[14:42] <mterry> didrocks, yeah, but that's not for raring, right?
[14:42] <didrocks> yeah, not anymore
[14:42] <didrocks> so you can either adds the recommends and remove from gwibber
[14:42] <didrocks> to prepare the future
[14:42] <mterry> didrocks, I believe this request was for raring
[14:42] <kenvandine> oh...
[14:42] <didrocks> (which is fine IMHO)
[14:42] <kenvandine> please add it then :)
[14:42] <didrocks> or do only the gwibber side to change :)
[14:43] <mterry> kenvandine, add a recommends to unity?  But gwibber already recommends lens-gwibber
[14:43] <kenvandine> gwibber is getting demoted
[14:43] <mterry> kenvandine, if I replace that with lens-friends, will everything work fine?
[14:43] <mterry> kenvandine, oh
[14:43] <kenvandine> yeah, just add the recommends so we make sure the lens is there still
[14:43] <mterry> kenvandine, I see, OK.  So just add a recommends in unity and gwibber will take care of itself
[14:43] <kenvandine> right
[14:43] <mterry> kenvandine, thanks
[14:43] <kenvandine> thanks!
[14:43] <mterry> kenvandine, get back to holiday
[14:45] <didrocks> see you kenvandine :)
[14:46] <kenvandine> thanks guys!
[14:46] <seb128> mterry, new gwibber requires qt5 which is not likely going to main for raring so we decided demoting gwibber
[14:46] <paulliu> gusch: https://code.launchpad.net/~paulliu/gallery-app/desktop_file_tweak/+merge/156548
[14:46] <mterry> seb128, sure
[14:47] <seb128> mterry, security team just hate us it seems :p
[14:47] <kenvandine> i spent a bunch of time on polishing up the new gwibber over the weekend... i think it looks really slick now :)
[14:47] <kenvandine> i love qml :)
[14:47] <gusch> paulliu: approved
[14:47] <gusch> paulliu: thx
[14:47] <paulliu> gusch: thanks.
[14:47] <didrocks> mterry: FYI, it's already listed for raring+1: http://bazaar.launchpad.net/~unity-team/libunity/libunity-7.0/view/head:/data/client-scopes.json
[14:48] <didrocks> kenvandine: btw, you need to check their integration testing before doing the next sdk upload :)
[14:48] <kenvandine> ok :)
[14:48] <Cimi> tsdgeos, yes I am
[14:48] <didrocks> kenvandine: you uploaded a version which broke the tutorial
[14:48] <kenvandine> ugh!
[14:48] <didrocks> they broke the API and no word on it :)
[14:48] <didrocks> kenvandine: so it shows:
[14:48] <didrocks> - their test in the package is insufficient
[14:48] <didrocks> - they need integration tests ;)
[14:49] <kenvandine> indeed
[14:49] <didrocks> kenvandine: but let's see once you're back :)
[14:49] <tsdgeos> Cimi: oh right, autolanding just being lazy you need https://code.launchpad.net/~saviq/unity/phablet.fix-hud-build/+merge/156486
[14:49] <kenvandine> their tests use the demos
[14:49] <kenvandine> i better disconnect before i find myself doing more work
[14:49] <didrocks> :)
[14:49]  * kenvandine waves
[14:49] <didrocks> see you kenvandine!
[14:51] <mterry> didrocks, seb128: https://code.launchpad.net/~mterry/unity/lens-friends/+merge/156584
[14:53] <didrocks> mterry: ah no, it doesn't work like that :)
[14:53] <seb128> mterry, wfm, "the gwibber rewrite isn't ready in time" is slightly incorrect (rewrite is ok, qt5 isn't security team friendly)
[14:53] <seb128> but who cares :p
[14:53] <didrocks> mterry: you should use http://bazaar.launchpad.net/~unity-team/libunity/trunk/view/head:/data/client-scopes.json
[14:53] <mterry> seb128, I would argue that falls under not being ready
[14:53] <seb128> mterry, fair enough
[14:53] <didrocks> and bump the libunity build-dep for next daily on unity to pick it up
[14:54] <mterry> didrocks, hrm.  I thought that json stuff was just for 100scopes, didn't know it was ready for raring too
[14:54] <seb128> mterry, oh, what didrocks said, forgot about the generated recommends
[14:54] <didrocks> mterry: I prepared it before the 100scopes in fact
[14:54] <didrocks> when I write perl, I want to ship it immediately :)
[14:54] <didrocks> (on Friday evening)
[14:54] <mterry> didrocks, heh
[14:54]  * mterry goes back
[15:01] <mterry> didrocks, I shouldn't need to bump the build-dep for unity because of this lens change though, right?
[15:02] <didrocks> mterry: well, you will need as you want unity to build against latest libunity to pick the right file
[15:02] <didrocks> or you can do 2 manuals rebuilds
[15:02] <didrocks> one after another
[15:03] <didrocks> otherwise nothing will make unity wait until libunity finished
[15:03] <mterry> didrocks, :-/  why is this file in libunity instead of unity?
[15:04] <didrocks> mterry: because all lenses needs it and libunity is loading it
[15:06] <davidcalle> didrocks, success! https://launchpad.net/projects/+new?field.displayname=Unity%20Launchpad%20Scope&field.name=unity-scope-launchpad&field.title=Unity%20Launchpad%20Scope&field.summary=Launchpad%20search%20for%20Unity
[15:07] <didrocks> davidcalle: hum, that doesn't change that you need your daemon to log in, right? :)
[15:07] <didrocks> davidcalle: or you want to have something xdg-open this url? and then click on "continue continue continue"? :)
[15:07] <MacSlow> Saviq, if you could have another look... https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512
[15:07] <davidcalle> didrocks, a bash loop and many "click" sounds :)
[15:08] <Saviq> MacSlow, will do first thing tomorrow
[15:08] <didrocks> davidcalle: a nice first step, I'll maybe one day create a chromium extension :)
[15:08] <didrocks> davidcalle: "batch launchpad creator"!
[15:08] <davidcalle> didrocks, what could go wrong ? :p
[15:08] <didrocks> isn't it? ;)
[15:09] <MacSlow> Saviq, I'll continue working on extending that with support for the remaining types then (based on my branch)
[15:09] <Saviq> MacSlow, yup
[15:11] <mterry> didrocks, OK.  How about https://code.launchpad.net/~mterry/libunity/lens-friends/+merge/156599 and https://code.launchpad.net/~mterry/unity/lens-friends/+merge/156584 ?
[15:11] <fginther> didrocks, generic autopilot job: http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/
[15:12] <didrocks> mterry: approved and approved!
[15:12] <mterry> didrocks, thanks!
[15:13] <didrocks> fginther: why do you want a "stack" and "series" parameter?
[15:13] <didrocks> mterry: thanks to you!
[15:13] <fginther> didrocks, stack is used for the skip files, series is used for the ISO selection
[15:13] <didrocks> fginther: ah, so I need to pass both to you :)
[15:14] <fginther> didrocks, yes, I think that's all, but still reviewing my changes
[15:14] <didrocks> fginther: SKIPFILE="/tmp/autopilot.${stack}.skip"
[15:14] <didrocks> fginther: that should be:
[15:14] <didrocks> /tmp/autopilot.${release}.${stack}.skip
[15:15] <fginther> didrocks, good catch
[15:15] <didrocks> fginther: hum, so we need to pass release?
[15:15] <didrocks> fginther: shouldn't we change stack by release-stack?
[15:15] <didrocks> rather?
[15:16] <fginther> release-stack is alwasys unique, right? then yes
[15:16] <didrocks> fginther: yeah, that's what identifies something unique
[15:16] <didrocks> ok, let's go for this :)
[15:17] <didrocks> fginther: will this work for unity too?
[15:17] <fginther> didrocks, I'm reviewing that right now
[15:18] <didrocks> ok, I'm doing the change in cupstream2distro-config for the new parameters meanwhile
[15:18] <Saviq> dandrader, I fixed https://code.launchpad.net/~saviq/unity/phablet.apps-lens-real-installed/+merge/156571 - there's one thing I'd like you to take a look at, though, if test_*_background is ran first (rename to test_0_background), the other ones fail
[15:18] <Saviq> dandrader, you might be able to jump at a solution quicker than me again
[15:18] <fginther> didrocks, are you going to pass both release and stack?
[15:18] <didrocks> fginther: yeah, do you want one or 2 parameters?
[15:18] <fginther> didrocks, 2
[15:18] <didrocks> ok
[15:19] <didrocks> fginther: so /tmp/autopilot.{{ release }}.{{ stack }}.skip
[15:19] <fginther> didrocks, yes
[15:19] <dandrader> Saviq, ok. let me check...
[15:26] <fginther> didrocks, the utah branch needs a few updates to base-preseed.cfg to work with the unity tests, but other than that the job should work
[15:26] <fginther> didrocks, updating that now
[15:26] <didrocks> fginther: https://code.launchpad.net/~didrocks/cupstream2distro-config/use-generic-job/+merge/156615
[15:27] <didrocks> fginther: excellent!
[15:27] <didrocks> tell me what you think about that ^
[15:33] <fginther> didrocks, one moment
[15:45] <tsdgeos> Saviq: why did you kill https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 ?
[15:45] <Saviq> tsdgeos, bad click
[15:45] <Saviq> tsdgeos, but it's failed in CI - you need to update debian/control
[15:49] <fginther> didrocks, so triaging test failures is a concern when all of the daily release jobs use a single generic autopilot job. It might be better to make the job a template.
[15:49] <tsdgeos> Saviq: no, no need to update debian/control
[15:49] <fginther> didrocks, we can try it as one job and see how it goes
[15:49] <tsdgeos> i just need tedg ro release the package that contains hud-client-2
[15:49] <didrocks> fginther: we are getting the test result per stack/releases
[15:49] <Saviq> tsdgeos, is hud-client-2.pc provided by libhud-client1?
[15:49] <tsdgeos> doh
[15:50] <tsdgeos> silly me
[15:50] <tsdgeos> i need to update the file
[15:50] <didrocks> fginther: however, can you ensure you cat the release/stack at the top of the job?
[15:50] <tsdgeos> can't read
[15:50] <didrocks> fginther: so that we get it on the console
[15:50] <fginther> didrocks, true, the concern is when a human manually comparing results for example.
[15:50] <fginther> didrocks, and I'll make that change
[15:51] <didrocks> fginther: I think we'll need a dashboard at some point TBH :)
[15:51] <dandrader> Saviq, found the problem. would you prefer if I fixed it our would you like to do it yourself?
[15:51] <fginther> didrocks, WIP
[15:51] <Saviq> dandrader, I can do
[15:51] <tedg> tsdgeos, We're moving to the didrocks magic daily release, so not using the old OEM infrastructure anymore.
[15:51] <didrocks> fginther: I'll handle the daily release part :-)
[15:51] <tedg> tsdgeos, So I'm not sure how we'd even do a release...
[15:51] <didrocks> fginther: I have a fair clear idea about we can show it
[15:52] <fginther> didrocks, In that case, lets continue this path
[15:52] <didrocks> fginther: yeah ;)
[15:52] <tsdgeos> tedg: really?
[15:52] <tsdgeos> tedg: that sucks, it's going to make the shell unbuildable
[15:52] <Saviq> tedg, shouldn't libhud-client1-dev _not_ have SONAME in it? i.e. libhud-client-dev ?
[15:53] <tedg> Saviq, Uhm, yes, it should.  That way the different versions of the API can be parallel installable.
[15:53] <hyperair> Saviq: that's not the SONAME.
[15:53] <tedg> Saviq, So if, at some point, we could support multiple versions.  Things like LTS support, etc.
[15:53] <Saviq> hyperair, ok, SOVERSION ;)
[15:53] <hyperair> Saviq: not that either.
[15:53] <hyperair> Saviq: that's the API version
[15:53] <hyperair> Saviq: the version appears in the .pc file name.
[15:53] <tedg> Saviq, It's not the SOVERSION, it's a different version.
[15:53] <Saviq> hyperair, right
[15:54] <hyperair> Saviq: so basically for packages that have api versions, you would have something like libfooX-Y where X is the api version, and Y is the SONAME version
[15:54] <dandrader> Saviq, there are two problems: 1 - you're not waiting for the animation to finish before pressing the mouse. (it disrupts the animations) 2 - you're releasing the mouse straight away (likely in the same event loop). that causes the logic to fail. the best way would be to release the mouse only after the screenshot has stopped moving (the hint animation has finished)
[15:54] <hyperair> Saviq: SONAME is for ABI, whereas the API version is for API.
[15:55] <tedg> So, more topical, Saviq, what PPAs are you guys building into now?
[15:55] <Saviq> hyperair, yeah, sorry for the misnomers
[15:55] <Saviq> tedg, ppa:phablet-team
[15:56] <tedg> Saviq, And are you guys still using the old OEM release stuff, or are you moving to the distro stuff?
[15:56] <Saviq> tedg, moving to distro, but not there yet
[15:59] <Saviq> dandrader, fixed, can you review that whole MR, then?
[15:59] <dandrader> Saviq, ok
[16:00] <fginther> didrocks, approved
[16:00] <Marlinc> Would anyone mind completing this survey? Some friends and I are working on a project and would like to know how people use their clipboard: https://docs.google.com/a/mms-projects.net/spreadsheet/viewform?formkey=dHdFV2Fyd0xnRU52a2o0TWg1Z1VRZVE6MQ
[16:01] <didrocks> fginther: thanks!
[16:14] <didrocks> fginther: FYI, deployed indicators and oif raring with the new parameters and generic job as a target. Will do unity once I get your thumb up (even by email if I'm not around)
[16:15] <fginther> didrocks, go for it!
[16:16] <didrocks> fginther: oh? ready? excellent, let me make the unity change then and deploy it
[16:16] <fginther> didrocks, the utah changes are pushed
[16:16] <didrocks> great :)
[16:16] <didrocks> fginther: so I gues we'll see once the daily releases will start :)
[16:16] <didrocks> guess*
[16:16] <fginther> didrocks, :-)
[16:17] <didrocks> fginther: let's try just oif
[16:17] <didrocks> fginther: the one with "skipping"
[16:18] <didrocks> fginther: urgh, it had something to prepare :)
[16:18] <didrocks> forgot about the geis changes in
[16:18] <Saviq> kgunn, ah, more bug spam, just what I needed ;P
[16:18] <didrocks> fginther: ok, well, we'll see tomorrow I guess, unity deployed
[16:19] <didrocks> fginther: if you have time, can you have a look at the oif run? it should start in ~30 minutes
[16:19] <fginther> fginther, excellent! Will watch it tonight.
[16:19] <didrocks> fginther: that will give us a good idea :)
[16:19] <didrocks> thanks ;)
[16:19] <didrocks> (and stop speaking to yourself, it's only Tuesday) :p
[16:19] <Saviq> kgunn, but seriously, good to get all the MR updates
[16:20] <kgunn> Saviq: oh the new team in lp? sorry....needed for our slow & eventual use of status
[16:21] <Saviq> kgunn, just kidding, it's fine, at least we get "our" MP updates
[16:21] <Saviq> kgunn, but suddenly I got compiz-team bugs, too ;)
[16:22]  * dandrader still sorting out filters to deal with the deluge of launchpad e-mails caused by "unity-ui-team joined unity-team"
[16:24] <kgunn> so sorry guys!
[16:31] <Saviq> dednick, you saw your MP has conflicts?
[16:31] <Saviq> -s
[16:40] <dednick> Saviq: yeah. just now. thanks
[17:15] <dednick> Saviq: just did a device build and getting this error when running qml-phone-shell. Cannot mix incompatible Qt library (version 0x50000) with this library (version 0x50001)
[17:16] <Saviq> dednick, hmm, I'd flash the device
[17:16] <Saviq> dednick, or at least add ppa:phablet-team and ppa:canonical-qt5-edgers/qt5-proper
[17:16] <Saviq> dednick, and update/upgrade
[17:18] <kgunn> dednick: phablet-flash -l worked for me
[17:20] <dednick> Saviq, kgunn: ta. will give it a try
[17:20] <dednick> dist-upgrade just causes segfault :S
[17:20] <Saviq> dednick, yeah, phablet-flash -l - android parts got out of sync
[17:20] <davmor2> Hey guys on the apps lens type in xchat-indicator or xchat indicator and it doesn't show up.  If you do the same thing in software-center it does is there a reason for this do you know?
[18:33] <Siekacz> hello
[18:35] <Siekacz> I want to build UnityNext, following these instructions (http://unity.ubuntu.com/getinvolved/development/unitynext/) and when I'm trying to execute ./build I get this: http://pastebin.com/7PJpiws2
[18:35] <Siekacz> of course it's raring
[19:25] <kgunn> Siekacz: did anyone answer you?
[19:26] <kgunn> Siekacz: basically late last week hud changed its build procedure....
[19:26] <kgunn> Siekacz: long story short, we have a meta- build to  build hud locally and it got out of sync
[19:27] <kgunn> Siekacz: the change that fixes it is merged...happened this morning...so just bzr pull --overwrite
[19:28] <Siekacz> thanks
[19:28] <kgunn> and start fresh, e.g. ./build -s
[19:28] <kgunn> which in turn calls unity_build
[19:30] <Akiva-Mobile> has the rewrite of unity to qt started yet? I am thinking of developing a terminal lens/scope
[19:33] <Siekacz> Akiva-Mobile: AFAIK it is the same unity as phone/tablet
[19:33] <Siekacz> so basically... yes
[19:34] <Akiva-Mobile> Siekacz: so it will be used on the desktop as well.... now I just need to figure out where to find the code...
[19:35] <Siekacz> http://unity.ubuntu.com/getinvolved/development/unitynext/
[19:35] <Akiva-Mobile> do you know if it can be used on the desktop yet?
[19:35] <Akiva-Mobile> that helps; thanks
[19:35] <Siekacz> currently I'm trying to buld this thing
[19:35] <Siekacz> kgunn: still the same
[19:36] <Akiva-Mobile> good luck ~
[19:36] <Akiva-Mobile> seeing raring is around the corner, it couldnt hurt to muck around with my install
[19:36] <Siekacz> btw.
[19:37] <Siekacz> raring is going to be a SP for quantal :>
[19:37] <Siekacz> but I'm glad
[19:38] <Siekacz> all serious development (new features) should go to UnityNext and Mir
[19:39] <kgunn> Siekacz: i was going to test myself...let me take a crack now
[19:39] <Akiva-Mobile> Siekacz: sp?
[19:39] <Akiva-Mobile> I looked at it, seemed like a stable alpha/beta
[19:39] <Akiva-Mobile> ie, not much difference
[19:40] <Siekacz> Service Pack - fixes, minor updates :)
[19:40] <Akiva-Mobile> yah figured
[19:40] <Siekacz> no braking-new features
[19:40] <Siekacz> *breaking
[19:43] <Siekacz> And I am waiting for Ubuntu Phones also (currently I'm a WP8 user :P)
[19:50] <Siekacz> Does anyone know if 13.10 will be based on Unity + Compiz or UnityNext+Mir?
[19:52] <bregma> Siekacz, at this point, nobody really knows what's planned for 13.10, because 13.10 has not been planned for yet
[19:53] <bregma> see also: rolling release plans
[19:54] <Siekacz> I see...
[20:03] <bregma> as far as I know the discussion on whether to go with a 13.10 or a rolling release is still to be had
[20:07] <kgunn> Siekacz: seeing what you're seeing....:-/
[20:09] <Siekacz> doesn't build for you too?
[20:28] <kgunn> Siekacz: right...but seems to be failing on the actual local build of hud...looks like a dep on some voice recog enginer
[20:29] <kgunn> oops/enginer/engine
[20:29] <Siekacz> btw. What do you use for voice recognition?
[20:29] <kgunn> tedg: ^ still struggling
[20:29] <Saviq> right... another change in HUD...
[20:29] <Siekacz> Google?
[20:29] <Saviq> Siekacz, julius
[20:29] <tedg> We shouldn't need julius anymore
[20:30] <mhall119> Saviq: http://paste.ubuntu.com/5671634/
[20:30] <Saviq> tedg, Siekacz, just sphinx, then?
[20:30] <mhall119> running Raring, I have the SDK PPAs installed
[20:30] <tedg> kgunn, You should probably need libpocketsphinx-dev and libsphinxbase-dev
[20:30] <tedg> kgunn, Most of the other build-deps are for the test suite.
[20:31] <tedg> mhall119, We're not building that anymore if you're grabbing trunk.
[20:31] <mhall119> Saviq: what's the different between ./build and ./build_unity?
[20:31] <mhall119> tedg: I grabbed lp:unity/phablet
[20:31] <Saviq> mhall119, ./build_unity builds libunity, UnityCore, HUD and people_lens (and nux on Quantal, as a dependency of UnityCore)
[20:31] <tedg> mhall119, Yeah, that's on hudclient-2 now
[20:31] <Siekacz> mhall119: i have the same issue
[20:32] <Siekacz> raring?
[20:32] <Saviq> mhall119, ./build builds UnityNext alone
[20:32] <Saviq> Siekacz, kgunn, mhall119, HUD bumped API version, will try and sort it out soon
[20:32] <mhall119> Siekacz: yes, I'm on raring
[20:32] <Saviq> raring vs. quantal is unrelated
[20:32] <Saviq> tedg, do we have the new hud built somewhere?
[20:32] <mhall119> dammit tedg, stop imporving it
[20:32] <mhall119> :P
[20:33] <tedg> Saviq, No, :-(  Apparently dput wasn't sending tarballs so LP was rejecting.  Working on that in another window.
[20:34] <tedg> mhall119, You can grab -r 365 and you should be fine
[20:34] <tedg> mhall119, Wait, sorry 364
[20:34] <tedg> mhall119, Anything earlier to 365 :-)
[20:34] <Saviq> mhall119, Siekacz, kgunn, or better use that branch lp:~aacid/unity/new_hud_client_api
[20:35] <Saviq> instead of lp:unity/phablet
[20:38] <mhall119> Saviq: then ./build -s; ./build; ./run ?
[20:39] <Saviq> mhall119, ./build; ./run should be enough
[20:39] <mhall119> even if I deleted ../unity_build?
[20:40] <Saviq> mhall119, well, if you did delete it, then no ;)
[20:41] <kgunn> mhall119: favorite quote of the day "dammit ted..."
[20:42] <mhall119> :)
[20:46] <mhall119> Saviq: tried lp:~aacid/unity/new_hud_client_api
[20:46] <mhall119> Saviq: http://ubuntuone.com/1iNn5Xgmxdl9fRTol7K7Me are the outputs from build -s and build
[20:47] <Saviq> mhall119, you're just like the most unlucky person ever
[20:48] <mhall119> that'd be me, yup
[20:48] <mhall119> actually, second most unlucky person
[20:48] <kgunn> mhall119: i thot i had that title....
[20:48] <mhall119> balloons is even workse
[20:48] <mhall119> ok, maybe third
[20:48] <mhall119> but I am the most annoying of the unlucky persons
[20:52] <Saviq> mhall119, ah damn, that branch does not have trunk in it...
[20:52] <Saviq> mhall119, let me hack up a branch together
[20:54] <Saviq> and actually test it, too
[20:54] <mhall119> Saviq: that's crazy talk
[20:54] <Saviq> Siekacz, kgunn, mhall119, correction - it's going to be lp:~unity-team/unity/phablet.temporary-hud-build-fix
[20:54] <Saviq> as soon as it pushes
[20:55] <mhall119> Saviq: is that on top of lp:unity/phablet or lp:~aacid/unity/new_hud_client_api ?
[20:56] <Saviq> mhall119, on top of lp:unity/phablet
[21:02] <mhall119> Saviq: do I need to rm ../unity_build and re build -s ?
[21:03] <Saviq> mhall119, should be enough to ./build_unity; ./build; ./run
[21:03] <Saviq> mhall119, as all the branches are pulled already
[21:04] <mhall119> what version of hud's branch should it have?
[21:06] <Saviq> daaammit
[21:06] <mhall119> told you I was the most annoying
[21:07] <Saviq> mhall119, no, it's just me
[21:07] <Saviq> got lost in the branches, it's fine
[21:07] <Saviq> mhall119, hud trunk
[21:07] <Saviq> mhall119, so 369 as of no
[21:07] <Saviq> w
[21:08] <mhall119> ok, I ran ./build_unity --clean, now I'm running ./build --clean
[21:08] <mhall119> seemed happy, trying ./run
[21:08] <mhall119> OMG! it runs!
[21:09] <mhall119> kinda
[21:11] <mhall119> no apps lens
[21:11] <Saviq> mhall119, icon or content?
[21:12] <Saviq> mhall119, icons are there, but in a different theme :/, lens and indicators content might not be there due to them actually talking to real backends, which might not be in place on your desktop
[21:12] <mhall119> neither
[21:13] <Saviq> mhall119, console output please?
[21:13] <mhall119> http://ubuntuone.com/7S0qSudYpAzQr7d58iN5fC
[21:14] <mhall119> has .out and .err
[21:14] <Saviq> mhall119, looks like you got a script for that, eh? ;)
[21:15] <mhall119> nope
[21:15] <mhall119> manually taring from the command line
[21:15] <Saviq> mhall119, `ls ../unity_build/build/share/unity/lenses/` ?
[21:16] <mhall119> lrwxrwxrwx 1 mhall mhall   36 Apr  2 17:07 applications -> /usr/share/unity/lenses/applications
[21:16] <mhall119> interestingly......I don't have /usr/share/unity/lenses/applications
[21:17] <Saviq> mhall119, ;)
[21:17] <Saviq> mhall119, do you maybe have smart scopes installed?
[21:17] <mhall119> ah, I do
[21:17] <Saviq> mhall119, yeah, we're incompatible with smarts atm
[21:17] <mhall119> so is everything
[21:17] <mhall119> :)
[21:17] <mhall119> but maybe I ran ./run_on_device now
[21:26] <mhall119> /o/
[21:26] <mhall119> thanks for all your help Saviq
[21:27] <mhall119> Saviq: should the fixes be landing in lp:unity/phablet today?
[21:27] <Saviq> mhall119, not until HUD is built in ppa:phablet-team
[21:29] <mhall119> are we going to be pulling it from a PPA instead of building it locally?
[21:31] <nik90> Saviq: can we expect all the unity-next stuff in a PPA instead of building it locally? That would make it much easier for users to test and report bugs
[21:32] <Saviq> nik90, installing all that on your desktop would break it
[21:32] <Saviq> nik90, you can go with ppa:phablet-team in a VM, though
[21:32] <nik90> Saviq: ah ok..
[21:32] <Saviq> nik90, but to test it for real a device is really so much better
[21:33] <Saviq> nik90, as there's a lot of things that are still only available in the phablet builds (exposed from Android, for example)
[21:34] <nik90> Saviq: I have an S3 (powerful enough) but no touch images for it yet :(
[21:43] <mhall119> Saviq: how can I get output from the shell when I use ./run_on_device
[21:43] <Saviq> mhall119, console output? on your console...
[21:43] <mhall119> hmmm....
[21:43] <mhall119> oh, I need to ./run_on_device -s first?
[21:44]  * mhall119 actually follows the instructions this time
[21:46] <Saviq> mhall119, ;)
[21:46] <Saviq> mhall119, yeah, -s will install the deps to build
[21:46] <Saviq> mhall119, just read what you put on the page ;)
[21:46] <mhall119> Saviq: you ask so much of me :)
[21:50] <mhall119> Saviq: you like me right?
[21:50] <Saviq> mhall119, sure, wassup?
[21:50] <mhall119> hud errors on the device
[21:51] <mhall119> http://paste.ubuntu.com/5671893/
[21:52] <Saviq> mhall119, yeah, use lp:unity/phablet for the device ;)
[21:52] <Saviq> mhall119, as hud hasn't built yet
[21:52] <Saviq> mhall119, subsequent `./run_on_device` will be fine, no need for -s
[22:04] <mhall119> Saviq: you rock!
[22:05] <Saviq> mhall119, glad it worked
[22:05] <Saviq> mhall119, sorry about the mess
[22:05] <mhall119> messes are okay, as long as they're identified and cleaned :)
[22:06] <kgunn> Saviq: when you used bp's in the past...if you had a work item for a milestone...but missed...
[22:06] <Saviq> kgunn, I haven't really used them
[22:06] <Saviq> kgunn, I came into a kanban-ruled world
[22:06] <kgunn> did you move it wholesale to the next milestone ? or mark as postponed in place, then duplicate it marked as todo/inprogress in the next milestone
[22:06] <Saviq> mhall119, can you comment on that ^?
[22:07] <kgunn> Saviq: out of what i just decribed which do you prefer...talking to cjohnston....seems canonical has no convention either is acceptable
[22:07] <kgunn> however duplicating keeps increasing your total count obviously
[22:08] <kgunn> robert_ancell: ^ opinion ?
[22:08] <Saviq> kgunn, maybe POSTPONED until the milestone deadline, then move to the new deadline?
[22:08]  * robert_ancell reads
[22:08] <Saviq> as TODO?
[22:09] <kgunn> i was thinking...if we move wholesale...postponed == a todo, from some previous milestone
[22:09] <robert_ancell> kgunn, if you miss a milestone you either reschedule or postpone
[22:10] <kgunn> robert_ancell: right..but do you move it or duplicate it
[22:10] <robert_ancell> kgunn, move it
[22:10] <kgunn> moving potentially screws up historical metrics (e.g. i planned more crap than i could do in milestoneX)
[22:11] <kgunn> i think i prefer moving too btw....since i don't like the "feeling" of growing overall # of tasks trying to track postponed
[22:12] <kgunn> but gives a false sense of feeling awesome...each milestone historically will only have "DONE"
[22:15] <Saviq> kgunn, here's one for you https://code.launchpad.net/~saviq/unity/phablet.release-1.67/+merge/156707 :)
[22:16] <robert_ancell> kgunn, if you use the burndown chart tracker then it keeps the historical data (it polls the blueprints). But yes, the blueprint implementation in Launchpad is annoying in that it does lose the data
[22:17] <kgunn> robert_ancell: Saviq ok....going to use the move method, which basically means...no use of postpone
[22:17] <Saviq> kgunn, robert_ancell if the burndown chart keeps them, then I vote "set POSTPONED as soon as you know, move in bulk on milestone switch (deadline)"
[22:18] <robert_ancell> Saviq, yeah, that sounds right. In desktop we did that essentially by reviewing postponed items at the next UDS then retargetting the blueprint or opening a new one
[22:19] <kgunn> ok...but we missed the milestone switch :) guess i shouldve done that as part of the Rick review
[22:19] <Saviq> kgunn, it doesn't have to be _on_ the day
[22:20] <mhall119> Saviq: kgunn: I haven't used milestones within a BP before
[22:20] <mhall119> if you duplicate it, your total WI count on the graph will go up
[22:21] <mhall119> if you move it, your per-milestone WIs still drop for the previous, and increase for the next, which I think is the desired result
[22:23] <kgunn> ug...i'm starting to see bp per milestone approach as useful (i need a beer)
[22:27] <Saviq> kgunn, remember to top-approve MPs when you deem them ready :)
[22:27] <Saviq> kgunn, btw, https://launchpad.net/~kgunn is not you? ;)
[22:28] <Saviq> and it's EOD for me
[22:28] <Saviq> and then some
[22:29] <kgunn> Saviq: ...i'm kgunn72...leftover.....and how does one top-approve ?
[22:30] <kgunn> just merge it?
[22:30] <kgunn> e.g. bzr merge lp:~saviq/unity/phablet.release-1.67 ?
[22:32] <Saviq> kgunn, no
[22:32] <Saviq> kgunn, just change the status at the top to "approved"
[22:33] <Saviq> kgunn, apart from just voting "Approve" as a comment
[22:33] <Saviq> kgunn, one more thing in that branch is that there is a prerequisite ("Prerequisite: 	lp:~saviq/unity/phablet.apps-lens-real-installed")
[22:33] <Saviq> kgunn, that means that the branch in question will only autoland after the other one does
[22:34] <kgunn> Saviq: got it...thanks for the hard work...see you tomorrow
[22:34] <Saviq> cheers
[22:39]  * Siekacz got Unity Next running
[22:39] <Siekacz> well done
[22:40] <Siekacz> First true responsive-design UI :)
[23:27] <mhall119> Saviq: you are my hero today :)