[00:07] <george_e> I think I've figured out what's happening: http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/launcher/XdndStartStopNotifierImp.cpp#L28
[00:07] <george_e> Every time a window is mapped/unmapped, a timer is started that causes a signal to be emitted when the state of any of the mouse buttons changes.
[06:19] <veebers> didrocks: ping
[06:19] <didrocks> hey veebers
[06:19] <veebers> Hi didrocks how's everything?
[06:20] <veebers> didrocks: who can I annoy about this bug? https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1163358
[06:20] <didrocks> veebers: I'm good, thanks! yourself?
[06:20] <didrocks> veebers: it's fixed, isn't it?
[06:20]  * didrocks looks
[06:20] <veebers> didrocks: can't complain, days are getting colder and darker; but at least still some sun
[06:20] <veebers> didrocks: I'm experiencing the same issue even with that version (have commented on that bug)
[06:21] <didrocks> veebers: the new soname is liblttng-ust-ctl.so.1
[06:22] <veebers> didrocks: hmm, but running the command lttng gives the error re: liblttng-ust-ctl.so.0: cannot open shared object file: No such file or directory
[06:22] <veebers> does that mean something is incorrect with lttng-tools?
[06:22] <didrocks> veebers: right, I think lttng-tools wasn't rebuilt against latest liblttng-ust
[06:23] <didrocks> veebers: I'm trying that, in a chroot
[06:23] <veebers> didrocks: cool, thanks
[06:25] <veebers> didrocks: Dinner is ready, I'll be back a little later on
[06:26] <didrocks> veebers: enjoy!
[06:26] <didrocks> veebers: hum, the -tools FTBFS
[06:26] <didrocks> /usr/bin/ld: tp.o: undefined reference to symbol 'rcu_dereference_sym'
[06:26] <didrocks> /usr/bin/ld: note: 'rcu_dereference_sym' is defined in DSO /usr/lib/liburcu-bp.so.1 so try adding it to the linker command line
[06:26] <didrocks> /usr/lib/liburcu-bp.so.1: could not read symbols: Invalid operation
[06:26] <didrocks> so I guess we can't just rebuild the old version
[07:20] <mzanetti> good morning
[07:25] <tsdgeos> hiz
[07:27] <veebers> didrocks: d'oh that sucks, how do we/I proceed from here?
[07:27] <didrocks> veebers: we are going to merge with debian, suck to do that that late though :/
[07:28] <didrocks> veebers: before PS is using any tool, it would be cool to ensure we can maintain it (or PS to maintain them themselves ;))
[07:28] <veebers> didrocks: ah ok, thank you for taking care of that
[07:28] <didrocks> no worry!
[07:29] <veebers> didrocks: what's a good way to ensure that we can maintain something? (i.e. from my point of view)
[07:30] <didrocks> veebers: ensure that we have a good "ack" from distro people, bringing that to ubuntu-devel ML
[07:30] <didrocks> veebers: as all the tools you are using, they should be maintained, so in main
[07:30] <veebers> didrocks: mostly I just check is there a ubuntu package? yes awesome I'll use it (for personal projects etc.)
[07:30] <didrocks> and we need to figure out who will maintain them, and so on…
[07:30] <didrocks> veebers: check the package is in main
[07:31] <veebers> didrocks: ack, thanks for the info. I'll share this sentiment with those involved too
[07:31] <didrocks> excellent, thanks veebers ;)
[07:31] <didrocks> oh something else
[07:32] <didrocks> do not relaunch the generic job alone
[07:32] <didrocks> this won't fix the -check jobs that are monitoring it
[07:32] <veebers> didrocks: ah ok
[07:32] <didrocks> so, only do it if you want to check that a UTAH fix fixes something
[07:32] <veebers> what's the prefered way of doing that (instead of just building and c&p-ing the parameters)
[07:32] <didrocks> veebers: do you know a little bit of daily release?
[07:33] <veebers> didrocks: a little bit, not a massive amount
[07:33] <didrocks> veebers: maybe we should plan to have a hangout sometimes if you wish, I don't want to take too much of your time today :)
[07:33] <veebers> didrocks: yeah sure sounds good, or failing that at the sprint
[07:33] <didrocks> veebers: yep, good as well :)
[07:34] <didrocks> veebers: just remind me about it please!
[07:34] <veebers> didrocks: will do :-)
[07:34] <didrocks> thanks ;)
[07:53] <seb128> hey
[07:53] <seb128> what happened to the hud in the indicators raring tests?
[07:53] <seb128> ups indicator->unity
[07:55] <didrocks> seb128: what job are you talking about?
[07:55] <seb128> didrocks, http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-ati/41/testReport/
[07:55] <didrocks> this isn't the unity raring tests
[07:55] <didrocks> this is the unity head tests
[07:56] <seb128> didrocks, shrug, I came from http://10.97.0.1:8080/view/cu2d/view/Raring/view/Unity/job/cu2d-unity-raring-2.2check/
[07:56] <didrocks> you don't see it complicated there
[07:56] <didrocks> so you don't have the run number
[07:56] <didrocks> it will be either 42 or 43 I guess
[07:56] <seb128> clicked on the blinking "ps-generic-autopilot-release-testing" line
[07:56] <seb128> ok
[07:57] <seb128> I guess from the url I gave, I need to click on the #16
[07:57] <seb128> the console output
[07:57] <seb128> and use the links in there when they will be in it?
[07:57] <didrocks> right
[07:58] <didrocks> but this only appears once the job finishes
[07:58] <seb128> one day I will manage browsing jenkins and find me way ;-)
[07:58] <didrocks> not sure if jibel knows if there is a way to know about this before ^
[07:58] <didrocks> seb128: heh :)
[07:58] <didrocks> but I agree, it's a PITA
[07:58] <didrocks> and we need a dashboard to agregate that
[07:58] <didrocks> (but I don't know if we have enough "running now" infos)
[07:59] <seb128> right
[07:59] <seb128> ok, I guess unity is red because the previous run fail on a broken ati round?
[08:00] <seb128> intel/nvidia numbers seem fine
[08:00] <didrocks> seb128: yeah, yesterday's one
[08:00] <didrocks> seb128: it was published
[08:00] <didrocks> I asked mterry to do so
[08:00] <seb128> cool
[08:01] <didrocks> hey sil2100! how are you?
[08:01] <sil2100> didrocks: hello! Fine fine, fighting GIR a bit right now - what's up?
[08:01] <seb128> didrocks, sorry for the questions btw, trying to keep an eye on things daily and to get an hang of the details ;-)
[08:01] <seb128> sil2100, hey
[08:01] <didrocks> seb128: no worry ;)
[08:01] <sil2100> seb128: hello ;)
[08:01] <didrocks> seb128: TBH, I had a look myself before ;)
[08:01] <didrocks> hence the quick answer :p
[08:02] <tsdgeos> sil2100: that bug about the qt popups, should it be fixed in raring already?
[08:02] <didrocks> sil2100: just wanted to know where you are at with indicator-messages, do you think we can have parallely installable by today or it will be need later on?
[08:03] <sil2100> didrocks: it should be ready today
[08:03] <didrocks> sil2100: sweet! btw, can you update the spreadsheet once it's done with the criterias we have?
[08:03] <sil2100> didrocks: it's basically ready, just don't want to modify too much code to make GIR work parallely
[08:03] <sil2100> didrocks: ACK!
[08:04] <didrocks> sil2100: thanks! :)
[08:04] <sil2100> tsdgeos: let me see - I think it got merged into trunk right now, but need to check if the raring branch got in
[08:04] <jibel> didrocks, you cannot because the build and the workspace are created when the job starts, and since there is a single AP job for everything you'll have to wait.
[08:04] <didrocks> jibel: so, no way to know which run will have "this and this and this" parameters before it actually runs?
[08:05] <didrocks> or that the -check job will trigger run #42 of this job?
[08:05] <didrocks> (when it's waiting for job #41 to finish)
[08:06] <sil2100> tsdgeos: shit, it didn't have a commit message, so it didn't get merged
[08:06] <tsdgeos> sil2100: ouch
[08:06] <sil2100> tsdgeos: re-approving
[08:07] <jibel> didrocks, not before they start.
[08:09] <didrocks> jibel: so, jenkins just track that into memory for the jobs to run and no xmlrpc mechanism to query that?
[08:13] <Saviq> mzanetti, hyum, so the whitespace test already made that happen (the 100% coverage), right?
[08:17] <seb128> didrocks, what's the vcs for unity-lens-video ?
[08:17] <seb128> didrocks, control says lp:~unity-team/unity-lens-video/trunk but that doesn't exist
[08:18] <didrocks> Vcs-Bzr should be set to the right one?
[08:18] <didrocks> oh
[08:18]  * didrocks tries with a s
[08:18] <didrocks> interesting…
[08:18] <seb128> didrocks, I can't find it on https://code.launchpad.net/~unity-team
[08:19] <didrocks> unity-lens-video: from cupstream2distro-config
[08:19] <didrocks> let's see the latest build
[08:19] <seb128> didrocks, lp:unity-lens-video then?
[08:19] <seb128> that works
[08:20] <didrocks> ~unity-lens-videos/unity-lens-video/trunk
[08:20] <seb128> didrocks, if I MR against that, it will land in raring?
[08:20] <mzanetti> Saviq: dunno which ones exactly
[08:20]  * didrocks blames again ken to have done something totally different for his scopes :/
[08:20] <didrocks> seb128: yep
[08:21] <didrocks> seb128: do you mind changing Vcs-Bzr as well?
[08:21] <seb128> didrocks, thanks, should I update the control Vcs-Bzr
[08:21] <seb128> lol
[08:21] <seb128> will do ;-)
[08:21] <didrocks> ;)
[08:21] <didrocks> Thanks!
[08:21] <seb128> yw!
[08:21] <didrocks> seb128: I think something with bzr+ssh://bazaar.launchpad.net/+branch/unity-lens-video/ should work
[08:21] <didrocks> seb128: maybe trying with lp:unity-lens-video?
[08:21] <didrocks> so that we really target trunk
[08:21] <didrocks> whatever the name is
[08:21] <seb128> lp:unity-lens-video works
[08:21] <mzanetti> Saviq: but if a test opens every file, yes, that will cause that
[08:21] <Saviq> mzanetti, http://bazaar.launchpad.net/~unity-team/unity/phablet/revision/575
[08:22] <didrocks> seb128: oh lp: works in Vcs-Bzr? awesome :)
[08:22] <Saviq> why didn't we notice that before...
[08:22] <didrocks> seb128: we should go with this short form for everything :)
[08:22] <tsdgeos> mzanetti: you have whitespace, noOoOOoOOoOOoO
[08:22] <seb128> didrocks, ah, you meant for the Vcs-Bzr, sorry I though you were speaking about the target
[08:22] <didrocks> no, Vcs-Bzr…
[08:22]  * tsdgeos finds it silly that we have to wait 1 hour to get notified we have whitespace and the MR won't pass CI
[08:22] <mzanetti> Saviq: yep. looks like it does
[08:23] <tsdgeos> don't want to think how's this going to look like when we're pressed to do a release
[08:23] <Saviq> tsdgeos, you don't
[08:24] <Saviq> tsdgeos, you have local tests
[08:24] <Saviq> tsdgeos, that you should run before committing
[08:24] <Saviq> or at least before pushing
[08:24] <tsdgeos> Saviq: tell mzanetti ;-) he did the hook and not even he is running it :D
[08:24] <mzanetti> tsdgeos: ?
[08:25]  * mzanetti has nothing to do with the whitespace thingie
[08:25] <Saviq> mzanetti, he meant the on-commit test hook
[08:25] <Saviq> tsdgeos, make qmluitests is too long, but make test should be fine
[08:25] <mzanetti> yeah... the commit hook doesn't work out
[08:26] <Saviq> mzanetti, if we only run `make test`, that should be better
[08:26] <tsdgeos> mzanetti: https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/158129 failed because of whitespace
[08:26] <mzanetti> Saviq: not really, its just too annoying if it kills the commit message you just wrote because you didn't build all the parts that are required to test something you haven't ever seen before
[08:27] <Saviq> mzanetti, use qcommit, it will not kill your commit message
[08:27] <Saviq> and doesn't QtCreator strip trailing wspaces by default?
[08:27] <mzanetti> Saviq: yes, it does
[08:28] <Saviq> but yeah, regardless, we need to fix the QML coverage
[08:28] <mzanetti> Saviq: means disable it
[08:28] <mzanetti> ?
[08:28] <Saviq> mzanetti, disable what?
[08:28] <mzanetti> the QML coverage
[08:28] <Saviq> mzanetti, no, fix it
[08:29] <Saviq> mzanetti, we don't need need no-qml unit tests on qmluitestrunner, do we?
[08:29] <Saviq> -need
[08:29] <mzanetti> Saviq: the only way I see is not to have any tests that open all files
[08:29] <mzanetti> (in the short term)
[08:30] <mzanetti> we could define a new target tho
[08:30] <Saviq> mzanetti, yeah, that's what I'm thinking
[08:30] <Saviq> mzanetti, to not run the non-qml unittests on qmluitest jo
[08:30] <Saviq> b
[08:31] <mzanetti> like "make whitespacetests" or the like
[08:31] <mzanetti> those could still be included in make alltests but not in the runtests.sh script
[08:32] <Saviq> mzanetti, I was thinking the other way round
[08:33] <Saviq> mzanetti, we only run qml tests on qmluitest job
[08:33] <Saviq> mzanetti, it doesn't collect c++ coverage from there, does it?
[08:33] <mzanetti> Saviq: it does
[08:33] <mzanetti> Saviq: and also the make check target has contains qml-only tests too
[08:33] <Saviq> mzanetti, that's fine
[08:33] <Saviq> mzanetti, but only runtests.sh monitors the files opened
[08:34] <Saviq> mzanetti, so we just need to make sure that runtests.sh only runs qml tests
[08:34] <Saviq> both unit and UI
[08:34] <Saviq> and, btw, won't the "alltests" target cut it already?
[08:34] <mzanetti> cut what?
[08:35] <Saviq> mzanetti, `make alltests` runs all the qml tests, doesn't it?
[08:35] <Saviq> mzanetti, but not the "usual" tests
[08:35] <mzanetti> Saviq: mall alltests run ALLtests
[08:35] <mzanetti> Saviq: make alltests run ALLtests
[08:36] <jibel> didrocks, you can get these informations from the API for example http://paste.ubuntu.com/5697798/ but apart from the tooltip when you rollover the job on the build queue, I don't know where it is exposed on the UI.
[08:36] <mzanetti> Saviq: ok... so in the end we will have this:
[08:36] <Saviq> mzanetti, no it doesn't
[08:36] <Saviq> mzanetti, it's a custom target that we only add to via the add_qml_test macro
[08:37] <didrocks> jibel: ah, it's already a good news! so if we plan to do a dashboard, we can get those info :) Thanks for trying!
[08:37] <Saviq> mzanetti, if tests are only defined using add_test()
[08:37] <mzanetti> true... you're right...
[08:37] <Saviq> mzanetti, they don't run on make alltests
[08:37] <mzanetti> Saviq: I'm starting to wonder if its a good idea that we have all this stuff in one and the same project
[08:38] <Saviq> mzanetti, so can we generate c++ coverage from `make test` and qml coverage from `make alltests`
[08:38] <Saviq> mzanetti, it's fine, we just have to cooperate
[08:39] <Saviq> mzanetti, and those kind of things would bite us one way or another
[08:39] <nic-doffay> Saviq, do you have a moment to discuss the tests I need to do for the infographics?
[08:40] <Saviq> nic-doffay, in 20 mins?
[08:40] <nic-doffay> Saviq, sure np.
[08:41] <seb128> didrocks, https://code.launchpad.net/~seb128/unity-lens-video/correct-search-hint-string/+merge/158294
[08:42] <didrocks> seb128: approved! thanks ;)
[08:42] <seb128> didrocks, thank you ;-)
[08:43] <Saviq> mzanetti, so, that should fix qml coverage: http://pastebin.ubuntu.com/5697811/
[08:43] <Saviq> mzanetti, and we only need to make sure that `make check` is run in the job, too, to generate c++ coverage
[08:44] <Saviq> mzanetti, is that not correct?
[08:44] <mzanetti> Saviq: yeah... but we should rename it to make qmltests and add another make alltests target to really execute alltests
[08:44] <Saviq> mzanetti, sure
[08:45] <mzanetti> Saviq: people are not going to type 5 make targets before committing... knowing myself I'm actually already worried about one :D
[08:45] <Saviq> mzanetti, I'm on it, can you take care of the job changes?
[08:46] <mzanetti> Saviq: are we going to remove the qml unittests from the make check target too then?
[08:46] <Saviq> mzanetti, do we need to? is it a problem that they run twice?
[08:46] <Saviq> mzanetti, I know it's time
[08:46] <mzanetti> Saviq: yeah... just thinking about time...
[08:47] <mzanetti> in that case we might merge unittests and qmluitests indeed
[08:47] <mzanetti> well... lets see how it grows
[08:48] <Saviq> mzanetti, yeah, let's deal with it when it becomes a problem
[08:48] <Saviq> mzanetti, TBH I miss the ability in CMake to have multiple test targets
[08:50] <mzanetti> Saviq: +1
[08:50] <Saviq> that would save us some hacks
[08:50] <mzanetti> I'll poke alexander :D
[08:55] <mzanetti> Saviq: I *think* the job should be ok... I runs make check too
[08:57] <mzanetti> Saviq: I guess I should disable the license check in jenkins again then... no need to run it twice
[08:57] <Saviq> mzanetti, it's not merged yet, though
[08:57] <mzanetti> Saviq: ah no... there's still the issue with generated files
[08:58] <Saviq> mzanetti, just noticed something
[08:58] <Saviq> mzanetti, runtests doesn't take .js into account
[08:58] <Saviq> mzanetti, that on purpose?
[08:58] <mzanetti> true... no... just forgot it
[08:58] <mzanetti> should do I'd say
[08:59] <Saviq> mzanetti, fixing
[09:00] <didrocks> jibel: I've added and deployed all future stacks we know as of now so that you can do the creation in batch: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/files/head:/stacks/head/
[09:01] <jibel> didrocks, ack, appended to my todolist
[09:02] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity/phablet.fix-qml-coverage/+merge/158298
[09:03] <mzanetti> Saviq: why are we not allowed to do in-source builds any more?
[09:03] <Saviq> mzanetti, because they're evil
[09:03] <didrocks> jibel: thanks :)
[09:03] <mzanetti> Saviq: no, they're convenient
[09:04] <mzanetti> Saviq: I fully agree that out of source builds must work and are a good thing
[09:04] <Saviq> mzanetti, in-source builds hide issues
[09:04] <mzanetti> Saviq: but for just branching something, building running tests it just adds unneeded hazzle
[09:04] <Saviq> mzanetti, ./build builds out of source for you
[09:05] <Saviq> mzanetti, ./run runs out of source
[09:05] <Saviq> mzanetti, the only thing is that you need to `make -C builddir`, which is, I agree, not convenient
[09:05] <Saviq> mzanetti, and I'm thinking of "forwarding" make to builddir by default
[09:05] <Saviq> should be doable by a simple static Makefile in top dir
[09:06] <mzanetti> Saviq:  ./build forces me to build all deps from scratch
[09:06] <Saviq> mzanetti, huh?
[09:06] <Saviq> mzanetti, how so?
[09:07] <Saviq> mzanetti, you just need a ../unity_build
[09:07] <mzanetti> Saviq: well, let me check better, just have ran it for the first time and it complains
[09:07] <Saviq> and whether you're using colocated branches (which I recommend)
[09:07] <Saviq> or just branches in dirs
[09:07] <Saviq> you just need to make sure ../unity_build is there
[09:08] <Saviq> and not care about it unless something changes there
[09:11] <Saviq> mzanetti, out-of-source are just closer to what actually happens on the builders
[09:11] <Saviq> mzanetti, just one more way to let us fail faster
[09:11] <mzanetti> Saviq: sure. still its not always required and anforcing it wastes time
[09:11] <Saviq> mzanetti, how does it waste time?
[09:12] <Saviq> mzanetti, IMO, the time saved when you forget something that will prevent an out-of-source build
[09:12] <Saviq> is worth it
[09:12] <Saviq> we just need to know about as many failures that might bit us in CI as possible
[09:12] <Saviq> and as soon as possible
[09:15] <Saviq> nic-doffay, hangout?
[09:15] <nic-doffay> Sure Saviq
[09:37] <Saviq> mzanetti, looks like it worked http://s-jenkins:8080/job/unity-phablet-ci/
[09:39] <Saviq> mzanetti, only source is unavailable for some reason
[09:40] <mzanetti> Saviq: yeah... because real coverage and qml coverage are not build in the same step any more (I think)
[09:40] <mzanetti> Saviq: but it didn't add any real value anyways
[09:40] <Saviq> mzanetti, why?
[09:40] <mzanetti> Saviq: oh... its gone for c++ too
[09:40] <Saviq> mzanetti, yeah
[09:40] <mzanetti> I thought only for qml
[09:41] <Saviq> mzanetti, was it ever there for qml?
[09:41]  * Saviq might not have checked
[09:41] <mzanetti> Saviq: yeah... for some reason it started working once I enabled the c++ one
[09:41] <Saviq> lol
[09:45] <tsdgeos> Saviq: mzanetti: Can you have a look at https://code.launchpad.net/~aacid/unity/remove_proxymodel_rolenames/+merge/158307 ? I've invited Florian to it too, but not sure he'll find a moment
[09:45] <mzanetti> Saviq: the whitespace thing should print which lines
[09:45] <mzanetti> Saviq: or just fix them
[09:46] <Saviq> mzanetti, to "just fix them" you can have a bzr hook, but the test should not do it
[09:46] <Saviq> mzanetti, it'd have to push back to the branch ;)
[09:46] <mzanetti> Saviq: yeah, sure, not in the test... but somewhere
[09:46] <Saviq> mzanetti, but lineno, sure
[09:46] <Saviq> mzanetti, http://doc.bazaar.canonical.com/plugins/en/text-checker-plugin.html
[09:46] <mzanetti> Saviq: qtcreator does not remove them :/
[09:46] <Saviq> mzanetti, it should
[09:47]  * Saviq checks
[09:47] <mzanetti> Saviq: it does only in files he thinks belong to the project
[09:47] <mzanetti> Saviq: but since we're using CMake + qml...
[09:47] <Saviq> mzanetti, just open the qmlproject, no?
[09:48] <mzanetti> Saviq: ok... qtcreator tries, but it doesn't work everywhere
[09:49] <dednick> Cimi: ping
[09:49] <Cimi> dednick, pong
[09:49] <mzanetti> (which is news to me too)
[09:49] <dednick> Cimi: did you ever manage to get findChild working with the timer?
[09:49] <Saviq> mzanetti, see, that's thanks to the whitespace test ;)
[09:49] <Cimi> dednick, I didn't try
[09:49] <Saviq> mzanetti, but yeah, I agree it would be nice to print out lines
[09:49] <mzanetti> Saviq: tbh thats one thing I already hated in Qt gerrit
[09:49] <Cimi> dednick, I saw it was not working, so I moved to readonly properties
[09:49] <dednick> Cimi: ok
[09:49] <dednick> Cimi: thanks
[09:50] <Saviq> mzanetti, at least here you can run the test locally and know straight away :D
[09:50] <mzanetti> Saviq: yeah
[09:50] <Saviq> mzanetti, gerrit is git, doesn't git complain about whitespaces anyway?
[09:50] <mzanetti> Saviq: no
[09:51] <Saviq> mzanetti, I think it's built-in, but configurable
[09:59] <dednick> mzanetti: question about public/private properties. There is a timer in MenuContent which has a 5 second interval for stopping the indicator menus. I want to test this behaviour, but dont really want the tests to wait for 5 seconds. What's the best course of action here?
[10:00] <dednick> unless it's just to suck it up and wait.
[10:00] <mzanetti> dednick: yeah... good one... Problem is that Timers can't be found by findChild(). If possible, try to find another way to get a pointer to it out of the qml context to modify the interval for the test
[10:00] <mzanetti> dednick: waiting 5 secs is not an option
[10:01] <mzanetti> dednick: I'm thinking about adding a "interval" property to some other element in the code file and make the timer point to that
[10:01] <dednick> i think my head just exploded. ok. i'll give it a go :)
[10:02] <mzanetti> dednick: huh?
[10:02] <dednick> mzanetti: yeah, i thoush about the interval property
[10:02] <dednick> mzanetti: about fishing it out of the qml context.
[10:02] <mzanetti> dednick: tell me which file it is and I'll paste an example snippet
[10:03] <dednick> mzanetti: MenuContent.qml
[10:04] <tsdgeos> sigh, this listview Qt bug is getting annoying
[10:04] <tsdgeos> now one of the guys wants to make so that you have a "forceLayout" function in the listview you have to call if you want to make sure stuff like currentItem returns the correct value
[10:05] <dednick> :S
[10:05] <mzanetti> dednick: I think in this case it would make sense to add a public "property int contentReleaseInterval: 5000" and make the timer point to it
[10:05] <dednick> mzanetti: ok sure. thanks
[10:06] <mzanetti> tsdgeos: hehe... the SignalSpy bug seems to be gone with 5.0.1 though
[10:06] <tsdgeos> cool :-)
[10:06] <tsdgeos> now let's update to 5.0.2 :D
[10:08] <tsdgeos> Saviq: what'd be the correct blueprint "milestone" for that new hud task? Work items for ubuntu-13.04-month-5:?
[10:08] <Saviq> tsdgeos, -6
[10:09] <tsdgeos> why 6?
[10:11] <didrocks> tsdgeos: ubuntu-13.04-month-5 would mean you did it last month ;)
[10:11] <didrocks> tsdgeos: it's an offset from the release schedule
[10:11] <didrocks> month 1 in developping raring
[10:11] <didrocks> and so on…
[10:11] <Cimi> mzanetti, not really sure what to test of LensView if not the Timer
[10:11] <tsdgeos> brrrrr
[10:11] <tsdgeos> ok
[10:12] <didrocks> tsdgeos: yeah, let's make it not easy, right? :p
[10:12] <Cimi> the signals are emitted externally
[10:12]  * mzanetti opens LensView.qml
[10:17] <mzanetti> Cimi: yeah... there's really only that timer...
[10:18] <mzanetti> Cimi: I'd say let it be...
[10:19] <mzanetti> really doesn't look like anything useful can come out of that
[10:30] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity/phablet.improve-check-whitespaces/+merge/158325
[10:32] <mzanetti> ack
[10:37] <Cimi> Saviq, wouldn't be easier to simply remove trailing whitespaces?
[10:37] <Saviq> Cimi, no
[10:37] <Saviq> Cimi, we would have to push back to the branch
[10:37] <Saviq> Cimi, we don't want to do that
[10:37] <Cimi> do we need them? :)
[10:37] <Saviq> Cimi, no we don't, but that's our responsibility to not have them
[10:37] <Saviq> Cimi, so whenever you run `make test` you'll know
[10:37] <Cimi> Saviq, qtcreator removes them automatically for me
[10:38] <Saviq> Cimi, yeah, sure, but that's not reliable enough
[10:38] <mzanetti> Cimi: Saviq: does not work all the time
[10:38] <Saviq> Cimi, and now you can just `make test` and you'll know
[10:38] <Saviq> Cimi, and there's http://doc.bazaar.canonical.com/plugins/en/text-checker-plugin.html for those that want to automate tings
[10:38] <Saviq> things, even
[10:38] <Cimi> mzanetti, to me it always worked
[10:39] <Saviq> Cimi, but not everyone uses qtcreator, not for everything
[10:39] <Saviq> Cimi, and we have non-Qt code in the tree now, too
[10:39] <mzanetti> Cimi: open a file and do: Ctrl+A, Ctrl+I, Ctrl+B... you'll end up with a few
[10:40] <mzanetti> also for very simple changes I don't use qtcreator but some command line editor
[10:43] <mzanetti> didrocks: [mzanetti] document what apps can run on the desktop: TODO
[10:43] <mzanetti> anything still needed?
[10:44] <didrocks> mzanetti: I don't think more is needed, do you mind checking with mterry, cyphermox, robru, ken if they have all the autopilot tests they need to be run?
[10:45] <mzanetti> didrocks: all of the projects I've ever been involved have a -autopilot package
[10:45] <didrocks> mzanetti: excellent, that's what we needed, so yeah, you can mark it as DONE
[10:45] <mzanetti> didrocks: ack
[10:46] <didrocks> thanks!
[10:46] <mzanetti> didrocks: (apps and shell, that is)
[11:05] <dednick> dont suppose anyone knows how to use a debugger with a qml file?
[11:05] <dednick> getting an odd segfault
[11:06] <Cimi> mzanetti, any convention on the function we want to use to call before each test? like a particular initTest?
[11:06] <dednick> and gdb is less than usefull when it comes to qml stacktraces.
[11:06] <mzanetti> Cimi: no
[11:06] <mzanetti> dednick: yep
[11:06] <Cimi> mzanetti, initTest is already used?
[11:06] <Cimi> mzanetti, or I should skip the word Test?
[11:06] <mzanetti> Cimi: dunno... I haven't use one so far
[11:06] <Cimi> ok
[11:07] <mzanetti> Cimi: probably skipping the word test makes sense, yes
[11:07] <mzanetti> Cimi: oh... btw
[11:07] <Cimi> mzanetti, tst_Showable uses init_test
[11:07] <mzanetti> Cimi: for Qt in C++ if you have a function "void init()" it will be automatically called before each testcase
[11:07] <mzanetti> Cimi: try that
[11:08] <Cimi> ok
[11:08] <mzanetti> Cimi: and in C++ if you have one called "void initTestCase()" it'll be called automatically before the whole suite (I know... naming seems reversed)
[11:08] <mzanetti> Cimi: same for cleanup() and cleanupTestCase()
[11:08] <Cimi> mzanetti, in case we can improve tst_Showable
[11:09] <Cimi> mzanetti, try renaming init_test to init()
[11:09] <Cimi> remove the function calls
[11:09] <mzanetti> Cimi: I don't know if that works in QML too tho... you would need to test if first
[11:09] <Cimi> and add a console.log :)
[11:09] <Cimi> sure I am doing
[11:09] <Cimi> before I need to finish my test
[11:09] <mzanetti> ok
[11:16] <Cimi> how can I See how qmltestrunner is running with the imports?
[11:16] <Cimi> I am in tests/qmluitests/Dash
[11:16] <Cimi> and I added
[11:17] <Cimi> add_qml_test(LensView IMPORT_PATH ${CMAKE_SOURCE_DIR}/plugins)
[11:17] <Cimi> in order to import
[11:17] <Cimi> Unity 0.1
[11:17] <Cimi> which didn't work
[11:24] <mzanetti> tsdgeos: I just looked at your MP regarding the roles
[11:24] <tsdgeos> whatcha think
[11:24] <tsdgeos> ?
[11:24] <mzanetti> tsdgeos: I *think* there has been an issue in early QML days (Qt 4.7) where a proxy model had to have its own role names. at least I remember having to do that back in the days
[11:25] <mzanetti> that might explain why this code was here
[11:25] <mzanetti> tsdgeos: I think your MP is ok nowadays
[11:25] <Cimi> with import builddir/plugins imports something
[11:25] <Cimi> but then complains
[11:25] <Cimi>  undefined symbol: _ZTIN5unity4dash13PeoplePreviewE)
[11:25] <Cimi> time to recompile unity?
[11:26] <mzanetti> tsdgeos: especially since you with qt5 roleNames is a virtual method instead of a "setRoleNames()" thingie and you already directly forward stuff i'm quite sure its ok
[11:27] <tsdgeos> yep
[11:27] <tsdgeos> that's my thought too
[11:27] <mzanetti> tsdgeos: +1'd it
[11:30] <tsdgeos> Saviq: which was the ppa you used that made valueselectors work?
[11:31] <Saviq> tsdgeos, ppa:ubuntu-sdk-team
[11:31] <tsdgeos> tx
[11:31] <Cimi> Saviq, builld_unity is missing libibus
[11:42] <mzanetti> someone please re-review this: https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/158329
[11:44] <tsdgeos> what happened to the other?
[11:44] <mzanetti> tsdgeos: I wasn't able to merge it any more...
[11:45] <tsdgeos> lol
[11:45] <mzanetti> tsdgeos: it complained about missing includes somewhere in unity and I couldn't figure why
[11:45] <tsdgeos> i'll do it after lunch, ok? ~1 hour aprox
[11:45] <mzanetti> I guess by then its full of conflicts again :D
[11:46] <mzanetti> or rather :(
[11:46] <mzanetti> but sure... enjoy your lunch
[11:57] <Saviq> greyback, there's an import issue with LVWPH test
[11:57] <Saviq> greyback, ../../Components doesn't import
[11:58] <greyback> Saviq: yep just pushing fix now
[11:58] <Saviq> greyback, tks
[11:58] <greyback> Saviq: pushed
[12:04] <mardy> luv: hi! I just noticed that SignOn::Identity has a signOut() method, and a quick look at the implementation suggests me that it should be working
[12:06] <luv> mardy: hey! thanks! .... strange? I played with that from python too (and indeed I stored the results afterwards and all that) but to no result (though I used the gi python bindings  - maybe that's the problem :-/ )
[12:06] <luv> would signOut delete the credentials or just signout (ie delete current token (or whatever is appropriate) and tell the apps using the account to log out)?
[12:08] <Saviq> Cimi, that might be a new requirement? what fails?
[12:08] <Cimi> Saviq, nux
[12:08] <Saviq> Cimi, you're on quantal?
[12:08] <Cimi> raring
[12:08] <Saviq> Cimi, we're not building nux on raring
[12:08] <Cimi> I am not sure though
[12:08] <Cimi> why is it?
[12:08] <Cimi> mmm
[12:09]  * Cimi redoes the thing again
[12:12] <Saviq> Cimi, 'cause nux in raring is new enough
[12:12] <Saviq> Cimi, it's not so in quantal
[12:12] <Cimi> Saviq, I might had an old build script
[12:12] <Saviq> Cimi, but when we switch the phone builds to raring we'll probably drop quantal support anyway
[12:12] <Cimi> I'm redoing from phablet
[12:12] <Saviq> k
[12:12] <luv> ok, let mse see the code
[12:13] <luv> umm, I wont be able to untill I get home, the browse functionality here https://code.google.com/p/accounts-sso/source/browse/#git is not working
[12:17] <dandrader> Saviq, I don't think the current add_qml_test (in CMake) would support two IMPORT_PATH parameters would it?
[12:17] <Saviq> dandrader, it doesn't now, but should be really easy to add
[12:18] <Cimi> who can help me with the issue above?
[12:18] <dandrader> Saviq, cool. will look into it
[12:18] <Saviq> dandrader, http://www.cmake.org/cmake/help/v2.8.9/cmake.html#module:CMakeParseArguments that's important
[12:21] <Cimi> http://paste.ubuntu.com/5698294/
[12:21] <Cimi> add_qml_test(LensView IMPORT_PATH ${CMAKE_SOURCE_DIR}/builddir/plugins)
[12:22] <Cimi> import Unity 0.1
[12:24] <Saviq> Cimi, why would you import Unity in a test?
[12:24] <Saviq> Cimi,
[12:24] <Saviq> you need to fake the Unity plugin
[12:24] <Saviq> Cimi, we can't import the actual Unity plugin in a test
[12:25] <Saviq> tsdgeos, could we have a test for https://code.launchpad.net/~aacid/unity/remove_proxymodel_rolenames/+merge/158307 ?
[12:26] <Saviq> tsdgeos, and move the tests for it under tests/ while we're at it?
[12:27] <Cimi> Saviq, to use lenses?
[12:27] <Saviq> Cimi, we can't
[12:27] <Saviq> Cimi, you can't use the actual lenses in a test
[12:27] <Cimi> it worked for the DashBar
[12:28] <Cimi> like two weeks ago
[12:28] <Cimi> three
[12:28] <Saviq> Cimi, that doesn't mean it's right
[12:28] <Cimi> now doesn't work anymore though
[12:28] <Saviq> Cimi, you need to fake the Unity plugin and whatever the LensView requires of it
[12:28] <Cimi> I should write what, a mock plugin just for the test?
[12:29] <Saviq> Cimi, yes
[12:30] <paulliu> hi. How can I run a specific test rather than make alltests.
[12:30] <Saviq> paulliu, `make testComponentName`
[12:30] <paulliu> Saviq: ok. thanks
[12:30] <Saviq> paulliu, i.e. `make testOpenEffect`
[12:30] <Saviq> paulliu, when you've added the test with add_qml_test() macro
[12:30] <Saviq> Cimi, and you wouldn't be the first to have done sone, tsdgeos wrote a fake HudClient plugin for the Hud tests
[12:30] <Saviq> Cimi, that's just what you do
[12:31] <Cimi> Saviq, I will do, after learning how to write a plugin and C++ :)
[12:31] <Saviq> Cimi, look at test/qmluitests/Hud/qml
[12:32] <Saviq> +s
[12:32] <Cimi> Saviq, already digging
[12:41] <Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity/phablet.fix-run_on_device/+merge/158348
[12:56] <tsdgeos> Saviq: which test do you want for https://code.launchpad.net/~aacid/unity/remove_proxymodel_rolenames/+merge/158307 ? the existing test already has some regarding rolenames
[12:56] <Saviq> tsdgeos, sorry, didn't check
[12:57] <mzanetti> Saviq: hey, I'm having troubles testing Dash/People/Data and Delegate
[12:58] <mzanetti> Saviq: I don't really get what the Data is actually doing
[12:58] <Saviq> tsdgeos, right, could you then just move it to where it belongs, under tests/?
[12:58] <tsdgeos> Saviq: same commit?
[12:58] <mzanetti> Saviq: to me it seems like its just a container where we set data from the outside and use it again. Don't see where the DeeVariantText actually comes in
[12:58] <Saviq> tsdgeos, yeah
[12:58] <tsdgeos> ok
[12:58] <Saviq> tsdgeos, and actually, shouldn't we drop setRoleNames() from there?
[12:58] <Saviq> tsdgeos, it's deprecated, no?
[12:59] <tsdgeos> Saviq: i dropped it
[12:59] <Saviq> tsdgeos, from the test I mean
[12:59] <tsdgeos> ah
[12:59] <tsdgeos> well the tests needs it to have a way to set roles to the mock model
[12:59] <tsdgeos> i think it's fine
[12:59] <Saviq> tsdgeos, right
[12:59] <Saviq> mzanetti, Data.qml unserializes the GVariant string
[12:59] <tsdgeos> i can rename it if you want
[13:00] <tsdgeos> so that it does not "collide" with the deprecated method
[13:00] <Saviq> tsdgeos, might be good to avoid
[13:00] <Saviq> yeah
[13:00] <tsdgeos> and it's more obvious it's a "local" method
[13:00] <Saviq> mzanetti, and then looks through it
[13:00] <tsdgeos> ok
[13:00] <Saviq> mzanetti, and sets some properties on itself
[13:00] <mzanetti> Saviq: yeah, thats the thing... I can't see where we are actually using that...
[13:00] <mzanetti> Saviq: it looks like there is column_0 .. column_n coming from the model
[13:01] <mzanetti> Saviq: we set that on the Data, and just read it again in the delegate
[13:01] <Saviq> mzanetti, yeah, and we "convert that" into meaningful names
[13:01] <Saviq> mzanetti, but then we also read stuff like the phone number, email addresses and social statuses
[13:01] <Saviq> mzanetti, from the GVariant string
[13:02] <tsdgeos> Saviq: about the run_on_device thing
[13:02] <Saviq> mzanetti, and set those on the meaningful named properties
[13:02] <tsdgeos> it's failing to find boost_regex here
[13:02] <tsdgeos> probably because it's a new dependecy
[13:02] <Saviq> tsdgeos, yeah, that's why the release
[13:02] <tsdgeos> and hte build-dep of the old package fails
[13:03] <tsdgeos> ok
[13:03] <tsdgeos> will manually install
[13:03] <Saviq> tsdgeos, that and libgtest-dev
[13:03] <mzanetti> Saviq: I might just leave that one test to you :D
[13:03] <Saviq> mzanetti, Data.qml can actually be tested separately
[13:04] <Saviq> mzanetti, just so you know, all of that should go away (and happen in the backend)
[13:04] <mzanetti> Saviq: oh... then it probably doesn't make sense writing a test now at all
[13:05] <Saviq> mzanetti, yeah might be
[13:05] <Saviq> mzanetti, as it's the backend that should just give us all the values prepared
[13:05] <mzanetti> Saviq: given the indaba thing is a giant mess right now and most likely will be rewritten...
[13:05] <Saviq> indeed
[13:05] <mzanetti> Saviq: do backends actually have to be written in vala or could we use Qt for those too?
[13:06] <Saviq> mzanetti, if you build Qt bindings for them...
[13:06] <Saviq> mzanetti, but anyway they won't be vala for much longer
[13:06] <Saviq> mzanetti, and AFAIK we don't want them in Qt, either
[13:06] <Saviq> OTOH
[13:06] <Saviq> who cares
[13:07] <Saviq> if there's going to be a C and a C++ API, if there's bindings for Qt
[13:07] <Saviq> we can just as well build them in Qt
[13:07] <Saviq> mzanetti, but anyway, not our part of the cake :)
[13:07] <mzanetti> Saviq: ah ok...
[13:07] <mzanetti> ok... I'll strikeout the Delegate and Data then
[13:07] <Saviq> yeah that's fine
[13:20] <tsdgeos> Saviq: moved the test and renamed the method
[13:20] <Saviq> tsdgeos, cheers
[13:20] <tsdgeos> and pushed to the wrong branch
[13:20] <tsdgeos> ...
[13:20] <tsdgeos> :D
[13:20] <Saviq> tsdgeos, yeah ;)
[13:21] <tsdgeos> now
[13:22] <Saviq> tsdgeos, does not contain a CMakeLists.txt file.
[13:22] <mzanetti> here's another way of increasing test coverage :D https://code.launchpad.net/~mzanetti/unity/phablet.remove-unused-header/+merge/158364
[13:22] <tsdgeos> does not?
[13:22] <tsdgeos> indeed
[13:23] <tsdgeos> Saviq: pushed
[13:24] <Saviq> tsdgeos, yup
[13:24] <Saviq> mzanetti, :)
[13:24] <mzanetti> :D
[13:24] <mzanetti> ok then... bbl
[13:43] <Cimi> greyback, tried my mail?
[13:44] <greyback> Cimi: no actually I haven't. I'll have a play once I've written up the API proposal
[13:45] <Cimi> ok
[13:50] <tsdgeos> Cimi: btw if you need some help with the fake plugin, try copying mine from the HUD and if you don't understand something just give me a shout
[13:50] <didrocks> mterry: you can deploy whenever you want :)
[13:50] <Cimi> tsdgeos, ok thx :)
[13:51] <mterry> didrocks, k, waiting for it to automerge.  I'm manually patching enough things today
[13:52] <didrocks> mterry: it's merged
[13:52] <didrocks> (you mean cupstream2distro?)
[13:52] <mterry> didrocks, oh!  well then
[13:52] <mterry> didrocks, yeah
[13:52] <didrocks> -config*
[13:52] <didrocks> mterry: I just skimmed over the emails at the minute it was sent! ;)
[13:52] <mterry> didrocks, you're faster than thunderbird
[13:52] <mterry> didrocks, though I suppose that's not saying much  ;)
[13:53] <Saviq> tsdgeos, should we just go for "setRoles"?
[13:53] <tsdgeos> Saviq: ok
[13:54] <mterry> didrocks, is there a way to run cu2d-update-stack -U on the whole set?
[13:54] <didrocks> mterry: yeah, I'm not sure to like the comparison ;)
[13:54] <tsdgeos> Saviq: done
[13:54] <didrocks> mterry: no :/
[13:54] <Saviq> tsdgeos, thanks
[13:54] <mterry> didrocks, should I be running it on the changed phablet ones too?
[13:55] <didrocks> mterry: well, if you ran it on your desktop, it's good enough
[13:55] <didrocks> mterry: I think we'll still have some FTBFS TBH
[13:55] <didrocks> mterry: so let's figure them out first ;)
[13:55] <mterry> didrocks, yes, we will have ftbfs.  But I meant should I be running it on the cfg files under phablet/
[13:55] <jibel> didrocks, http://10.97.0.1:8080/view/cu2d/view/Head/
[13:56] <jibel> didrocks, I didn't create the 'network' view, there is no job with this name and the name of the stack is 'location' in the configuration file
[13:57] <didrocks> mterry: oh not under phablet
[13:57] <didrocks> mterry: we never deployed it
[13:58] <mterry> didrocks, ok
[13:58] <didrocks> jibel: network and locations are differents
[13:59] <didrocks> jibel: let me deploy it quickly, sorry for missing it
[13:59] <didrocks> jibel: done
[13:59] <jibel> didrocks, I guessed so, that's why "name: location" in network.cfg sounds weird
[14:02] <didrocks> jibel: no, it was exactly what I wanted to do… hem :p
[14:07] <mterry> didrocks, jibel: when trying to deploy, I keep getting connection timed out errors (but, like, midway through).  Any known issues with jenkins?
[14:09] <didrocks> mterry: oh? not that I know of or saw today even
[14:10] <jibel> mterry, which stack? always the same or different one each time? can you paste the full output of the command?
[14:10] <mterry> jibel, sure
[14:10] <mterry> jibel, I got this with both the apps and platform stacks: http://pastebin.ubuntu.com/5698566/
[14:10] <mterry> jibel, I assume I'd get it with more, can try if you want
[14:11] <mterry> It's reliable
[14:40] <ChrisTownsend> Is there even a chance that the fix for https://bugs.launchpad.net/compiz/+bug/763148 is SRUable for 12.10 and more importantly, 12.04?
[14:46] <didrocks> fginther: does      indicator-icons still change?
[14:47] <didrocks> fginther: I think the icons are merged in ubuntu-themes
[14:55] <fginther> didrocks, there hasn't been a merge since Feb 20
[14:55] <didrocks> fginther: yeah, can you kill it please?
[14:55] <fginther> didrocks, no problem
[14:55] <didrocks> thanks!
[15:04] <Cimi> tsdgeos, what calls fake_libhud_client?
[15:12] <tsdgeos> Cimi: not sure what you mean
[15:12] <Cimi> tsdgeos, I'm studying the plugin
[15:12] <Cimi> tsdgeos, fake_hud_plugin registers
[15:13] <Cimi> tsdgeos, libhud_client_stub is the code of the plugin registered by fake_hud_plugin
[15:13] <Cimi> tsdgeos, I'm wondering when all the processing in lin fake_libhud_client happens
[15:13] <tsdgeos> yes
[15:13] <smspillaz> ChrisTownsend: probably, the code change is not too complicated
[15:13] <smspillaz> ChrisTownsend: ask the distro team
[15:13] <tsdgeos> Cimi: when those functions are called
[15:13] <tsdgeos> what i'm doing there is implement a stub of the libhudclient
[15:14] <tsdgeos> so i'm "implementing" the functions of the real libhudclient
[15:14] <tsdgeos> they are called from plugins/HudClient/*
[15:14] <ChrisTownsend> smspillaz: Thanks.  Yeah, I'll follow up with them.  If they think it's ok, then I'll work on backporting it.
[15:14] <dednick> Cimi: the plugin path that is test in the test overrides the default hudclient path, so it's loaded instead of the one from plugins/HudClient.
[15:15] <dednick> *set in the test
[15:15] <tsdgeos> anyone has any idea why ./run_on_device is not syncing one of my files? (it's new)
[15:16] <dednick> Cimi: so when tst_hud.qml does "importHudClient 0.1" it's loading from the qml folder, where the HudClientStub is registered
[15:16] <Cimi> ah ok
[15:17] <dednick> the Panel does it as well, except with qml files instead of a library.
[15:18] <tsdgeos> ok, needed to bzr add them
[15:30] <tsdgeos> mzanetti: what happened? https://code.launchpad.net/~aacid/unity/remove_proxymodel_rolenames/+merge/158307
[15:30]  * mzanetti checks
[15:30] <mzanetti> tsdgeos: thats a bit unfortunate and shouldn't happen... the mediumtests-builder job failed
[15:30] <mterry> fginther: any ideas on that jenkins timeout?
[15:32] <mzanetti> tsdgeos: 16/16 Test #16: cleanincludes ........................***Not Run   0.00 sec
[15:32] <mzanetti> tsdgeos: full log: http://s-jenkins:8080/job/generic-mediumtests-builder/1097/console
[15:33] <tsdgeos> mzanetti: oh i see :-/
[15:34] <mzanetti> tsdgeos: do you know what failed?
[15:34] <mzanetti> tsdgeos: actually the generic-mediumtests-builder should never fail if the other ci jobs pass - that's why it has been hidden in the comment that jenkins posts
[15:34] <fginther> mterry, are you referring to tsdgeos' build?
[15:35] <mterry> fginther, sorry no, I was trying to deploy a new config earlier
[15:35] <mterry> fginther, I was getting timeout errors
[15:35] <mzanetti> tsdgeos: since yesterday I've seen some of the new API team tests fail only on that one... no idea yet what exactly happens
[15:35]  * fginther checks the logs
[15:36] <mterry> fginther, sorry
[15:36] <mterry> fginther, I meant to ping jibel
[15:36] <mterry> fginther, for some reason I remembered it as you
[15:36] <mterry> jibel, any ideas on that jenkins timeout?  (nailed it!)
[15:37] <tsdgeos> mzanetti: no i don't
[15:37] <tsdgeos> it was a "i see" of "i couldn't find what failed"
[15:37] <mzanetti> jussi might have an idea... he wrote that test
[15:37] <tsdgeos> mzanetti: but "not run?"
[15:37] <tsdgeos> i "could" understand not passed
[15:37] <mzanetti> tsdgeos: it says BAD_COMMAND
[15:37] <tsdgeos> but not run...
[15:38] <mzanetti> 2 lines down
[15:38] <mzanetti> whatever that means
[15:38] <tsdgeos> binary not available?
[15:39] <mzanetti> tsdgeos: its a python script
[15:39] <mzanetti> tsdgeos: but so is the whitespace one, and that passed
[15:39]  * tsdgeos shrugs
[15:42] <Saviq> mzanetti, tsdgeos, autolanding / ci has python
[15:43] <Saviq> mzanetti, tsdgeos, but pbuilder does not
[15:43] <mzanetti> yeah... I know
[15:43] <Saviq> or PPA, rather
[15:43] <mzanetti> Saviq: do you know what "test not run (BAD_COMMAND)" means?
[15:44] <Saviq> mzanetti, yeah, python3 wasn't there
[15:44] <mzanetti> ok... I know whats happening then
[15:44] <Saviq> mzanetti, tsdgeos https://code.launchpad.net/~saviq/unity/phablet.add-python3-dep
[15:44]  * mzanetti fixes
[15:44] <Saviq> or https://code.launchpad.net/~saviq/unity/phablet.add-python3-dep/+merge/158398 rather
[15:45] <tsdgeos> mzanetti: i'd give it a "broken hardware" thing
[15:45] <tsdgeos> i mean that test run when it was autolanded
[15:45] <tsdgeos> no?
[15:45] <mzanetti> tsdgeos: the mediumtests builder can run on precise machines, while the other only run on quantal & raring
[15:46] <mzanetti> tsdgeos: I'll restrict the builder to quantal and see if that helps
[15:46] <tsdgeos> weird :D
[15:49] <mzanetti> tsdgeos: indeed... jenkins config says it should be restricted on quantal-i386.. yet it ran on a precise machine.
[15:49] <tsdgeos> lol
[15:49] <mzanetti> tsdgeos: but I guess the precise machine has a quantal pbuilder chroot which makes it qualify for that
[15:50] <mzanetti> yep... also the other quantal builds run on precise hosts... so thats not the issue
[15:50] <mzanetti> now I'm really puzzled why it fails only in there and not everywhere
[15:51] <mterry> didrocks, any word on jenkins/deploying feasibility?
[16:00] <jibel> mterry, no idea, I cannot reproduce it and no error message in servers logs
[16:03] <mterry> jibel, oh.  :(  will try again
[16:11] <mterry> didrocks, I guess there is some mterry-specific error with jenkins deployment right now.  Can you deploy -config trunk for me?
[16:11] <didrocks> mterry: sure, what stacks?
[16:19] <mterry> didrocks, stacks/head/hud.cfg
[16:19] <mterry> stacks/head/location.cfg
[16:19] <mterry> stacks/head/network.cfg
[16:19] <mterry> stacks/head/phone.cfg
[16:19] <mterry> stacks/head/apps.cfg
[16:19] <mterry> stacks/head/indicators.cfg
[16:19] <mterry> stacks/head/media.cfg
[16:19] <mterry> stacks/head/mir.cfg
[16:19] <mterry> stacks/head/platform.cfg
[16:19] <mterry> stacks/head/unity.cfg
[16:19] <didrocks> all?
[16:19] <didrocks> you have made that many changes?
[16:19] <didrocks> like location is empty
[16:19] <didrocks> I already deployed it this morning :p
[16:20] <mterry> didrocks, then not that one.  I was just working off the list of modified files when I did a bzr pull
[16:21] <didrocks> mterry: ok, deploying them one afoter another
[16:21] <Zhenech>  /wi60
[16:21] <Zhenech> ups
[16:21] <mterry> didrocks, is there a reason we couldn't automate it?
[16:21] <didrocks> mterry: we need to first poke if the stack is running
[16:22] <didrocks> mterry: because if the stack is running, it needs to wait before deploying
[16:22] <mterry> didrocks, I mean, we still need the atchive-admin bit.  but we should always deploy after a change, right?
[16:22] <mterry> hmm
[16:23] <mterry> didrocks, how about right before a stack runs, it deploys itself
[16:23] <didrocks> mterry: if you have a patch for that, I would be happy :)
[16:24] <mterry> didrocks, not today, anyway.  I think I'll just keep having you deploy for me until you get tired of it and patch it yourself.  ;)
[16:25] <didrocks> mterry: or get your machine fixed?
[16:25] <mterry> didrocks, yeah, I wonder why only I get this error
[16:57] <mzanetti> Saviq: you have an idea what could be happening here by any chance?
[16:57] <mzanetti> QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id: 0, major code: 140 (Unknown), minor code: 20
[16:57] <mzanetti> and the application never finishes to initialize
[17:19] <mzanetti> super simple MP anyone? https://code.launchpad.net/~mzanetti/unity/phablet-bring-back-launcher-tests/+merge/158434
[17:19] <Saviq> mzanetti, on it
[17:19] <Saviq> mzanetti, about the xcb error, no :/
[17:33] <mzanetti> Saviq: FYI: I have no clue why, but code contents in cobertura reports are back
[17:34] <Saviq> mzanetti, yay!
[17:34] <Saviq> :D
[17:34] <mzanetti> Saviq: and there is really not much red in our testing doc any more
[17:34] <Saviq> mzanetti, yup
[17:34] <mzanetti> tomorrow I'll check the state of our ListItems
[17:35] <mzanetti> I'm a bit afraid of the Dashs
[17:35] <mzanetti> but most likely because I haven't tought good enough about how to test them yet....
[17:37] <mzanetti> Saviq: I commented on Shell.qml in the testing doc. when you have a minute think about it and let me know if you agree. Not necessarily today any more.
[17:37] <mzanetti> I'll call it a day now
[17:37] <Saviq> mzanetti, any more? ;)
[17:37] <Saviq> mzanetti, cheers
[17:58] <Saviq> mzanetti, still around?
[17:59] <Saviq> mzanetti, if you are, can you look at http://10.97.2.10:8080/job/unity-phablet-qmluitests/238/console
[17:59] <Saviq> sergiusens, or you ^?
[18:01] <sil2100> mterry, mzanetti: sorry for again messing up the work items in the blueprint! Had a misunderstanding with firefox ;) But I think it's all ok now
[18:01] <mterry> sil2100, heh, I do it all the time
[18:23] <kgunn> mterry: hey, so one item that needs to get added somewhere is "hint where launcher is" from greeter
[18:24] <kgunn> should that be an item for launcher? greeter? or just the shell ?
[18:25] <mterry> kgunn, I'd say greeter.  Design is looking at various ways to hint both launcher and right-side swipe from the greeter, so they may come up with a related fix for both
[18:25] <mterry> kgunn, I'll add
[18:25] <kgunn> mterry: you are awesome...
[18:25] <kgunn> thanks
[18:25] <mterry> kgunn, there is a "discover edges" item under greeter that I will expand for that
[18:25] <kgunn> mterry: ah...just saw it
[18:27] <kgunn> mterry: actually nic d'offay will own the ui portion of the infographic  & pete's gonna own the backend
[18:27] <mterry> kgunn, OK.  I'm still grappling with the engineers involved, thanks
[18:27] <mterry> kgunn, I didn't have to care before  ;)
[18:27] <kgunn> :))
[18:36] <sergiusens> Saviq: looking
[18:37] <mterry> kgunn, do you know which teams/engineers are working/available for other OOBE stuff, like the installer and first-time customizations?
[18:38] <kgunn> mterry: no i'm not...if it needs to be done, add it, then add a note saying no owner
[18:38] <mterry> kgunn, k
[18:56] <sergiusens> Saviq: is this /tmp/qmlfile.qml something you talked about with mzanetti?
[18:56] <mzanetti> sergiusens: whats whit it?
[18:56] <sergiusens> mzanetti: can't find that file in the tests and aborts it seems
[18:56] <sergiusens> mzanetti: my first hunch
[18:57] <mzanetti> sergiusens: oops. I'll fix it
[18:57] <sergiusens> mzanetti: is it supposed to be in the hook?
[18:57] <mzanetti> sergiusens: no...
[18:57] <sergiusens> mzanetti: ps-quantal-server-amd64-1 is offline in jenkins and started if you want to look into it
[18:58] <mzanetti> sergiusens: ah ok... thats why I can't reach it
[18:59] <sergiusens> mzanetti: just ssh into it :-)
[18:59] <mzanetti> sergiusens: no. need to change the job config
[18:59] <sergiusens> mzanetti: so you have qmlscene /tmp/qmlfile.qml & and also set -e and [ -f /tmp/qmlfile.qml ] is false
[19:00] <sergiusens> mzanetti: I'll put the machine online again and stop it from virsh if you don't think you'll need it
[19:00] <mzanetti> sergiusens: fixed
[19:01] <Saviq> mzanetti, thanks
[19:01] <sergiusens> mzanetti: node is back
[19:01] <mzanetti> sergiusens: so the problem is this: I haven't yet found out why, but sometimes the very first run of a Qt5 app in the VM just hangs
[19:01] <mzanetti> sergiusens: I had that already with the mediumtests in the i386 vm's
[19:02] <mzanetti> sergiusens: I just couldn't find the solution so I added a workaround that just fires up qmlscene and kills it again.
[19:02] <Saviq> sounds reliable :D
[19:02] <mzanetti> sergiusens: worked like a charm. at some point I noticed it wasn't required any more and removed it again
[19:02] <mzanetti> now the same thing started on the amd64 vms
[19:02] <sergiusens> mzanetti: great, at first I thought you were doing environment validation before running anything
[19:03] <mzanetti> Saviq: its the xcb error I posted earlier
[19:03] <sergiusens> mzanetti: do you have a log with the error?
[19:03] <mzanetti> sergiusens: yep, one sec
[19:03] <mzanetti> sergiusens: this is the line: QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id: 0, major code: 140 (Unknown), minor code: 20
[19:04] <mzanetti> sergiusens: everything else is exactly the same as with successful runs
[19:04] <mzanetti> sergiusens: if it hangs, it stalls at this line
[19:07] <sergiusens> mzanetti: this does ring a bell... I'll see if I create a vm on my machine
[19:17] <sergiusens> mzanetti: other topic, where is our current autopilot branch these days?
[19:18] <sergiusens> and how close are you with autopilot-1.3?
[19:25] <Saviq> mzanetti, we crossed the mark of 200 tests :D
[19:28] <bschaefer> Saviq, yay. Would you want something like this in ./run? As running things in gdb is slightly annoying atm.
[19:28] <bschaefer> Saviq, http://paste.ubuntu.com/5699506/
[19:30] <Saviq> bschaefer, sure, looks useful, only thing is that I'd probably drop the UNITY_CORE...
[19:30] <mzanetti> Saviq: \o/
[19:30] <Saviq> bschaefer, export LD_LIBRARY_PATH
[19:30] <Saviq> mzanetti, yup
[19:30] <mzanetti> Saviq: another 200 and we are gaining on Mir :P
[19:30] <bschaefer> Saviq, soo have the users do the export?
[19:31] <bschaefer> or have it in the bash script
[19:31] <Saviq> bschaefer, no no, in the script
[19:31] <bschaefer> Saviq, alright, ill do a MP for that :)
[19:31] <Saviq> bschaefer, but export the var instead of just running qml with it
[19:31] <bschaefer> alright
[19:31] <Saviq> bschaefer, and then run gdb directly, without the $OPTIONS var
[19:31] <Saviq> bschaefer, and please support -g, too
[19:32] <Saviq> bschaefer, and use getopt
[19:32] <Saviq> bschaefer, and we good!
[19:32] <bschaefer> Saviq, sounds good :), ill see what i can do
[19:34] <Saviq> bschaefer, one last thing - « gdb -ex run --args ... », please
[19:34] <Saviq> bschaefer, so that we don't have to type "run" manually
[19:34] <bschaefer> Saviq, o right, typing that r would get annoying if we can run it our selfs
[19:35] <Saviq> yup
[19:49] <fginther> cyphermox, what do I need to do to get https://code.launchpad.net/~fginther/cupstream2distro-config/qa-stack-update/+merge/158197 deployed?
[19:49] <fginther> cyphermox, the jenkins server looks quite
[19:49] <fginther> s/quite/quiet/
[20:06] <bschaefer> Saviq, heres what I have: https://code.launchpad.net/~brandontschaefer/unity/add-gdb-support-to-run-script/+merge/158465
[20:06] <bschaefer> works well for me
[20:07] <Saviq> bschaefer, no need for the shift
[20:07] <Saviq> I _think_
[20:07] <bschaefer> Saviq, hmm the shift moves over one if an option is matched right?
[20:07] <Saviq> bschaefer, yeah, but we should get the "rest" from getopt
[20:07] <Saviq> I _think_, again
[20:07]  * Saviq reads
[20:07] <bschaefer> Saviq, hmm well I also stole a bit of that code from ./build
[20:08] <Saviq> bschaefer, yeah, but that didn't have $@, so no worry there
[20:08] <bschaefer> Saviq, as I would think, if its ./run -g 1 2 3, and we hit a -g it shifts $@ = 1 2 3
[20:08] <Saviq> bschaefer, whereas for ./run we need it
[20:08] <bschaefer> Saviq, correct, ooo you're saying it'll shift all the params
[20:09] <bschaefer> right, ill remove that and find an option for the qml_phone_shell to test it out if it gets the args or not
[20:10] <Saviq> bschaefer, just make sure that there's no "better" way for getopt
[20:10] <Saviq> to get "the rest"
[20:10] <bschaefer> Saviq, alright cool, let me do some more digging to make sure we get all the args from $@
[20:10] <Saviq> bschaefer, and maybe we should separate the args passed to qml-phone-shell with --
[20:10] <bschaefer> Saviq, hmm I could look into adding them to the run script
[20:11] <Saviq> bschaefer, to be somewhat "standard" compliant
[20:11] <bschaefer> or you're saying have a break
[20:11] <bschaefer> Saviq, i've actually never used getopts before soo let me read more of the man pages :)
[20:11] <Saviq> bschaefer, yeah, `./run -g -- --whatever --options --for --qml --shell`
[20:11] <Saviq> bschaefer, sure
[20:12] <bschaefer> Saviq, we should be able to stop eating args up when we hit a '--' that would be nice
[20:12]  * bschaefer thinks there should be a better way possibly
[20:13] <Saviq> bschaefer, that might help http://serverfault.com/questions/95077/how-can-i-get-remaining-args-after-pulling-out-parsed-items-using-getopts
[20:13] <bschaefer> Saviq, you are very good at this google thing
[20:13] <Saviq> lol
[20:13] <bschaefer> haha, thanks! Ill read through it :)
[20:14] <Saviq> oh, that's interesting http://rsalveti.wordpress.com/2007/04/03/bash-parsing-arguments-with-getopts/
[20:14] <Saviq> :D
[20:14] <Saviq> we have ourselves a getopts master around :]
[20:14] <cyphermox> fginther: can we also migrate gtester2xunit and pyruntest?
[20:14] <rsalveti> jezz, that's from 2007!
[20:14] <rsalveti> :-)
[20:14] <bschaefer> o awesome
[20:15] <fginther> cyphermox, I don't have permissions to migration gtester2xunit (need Martin) and we don't want to continue support of pyruntest.
[20:15] <fginther> cyphermox, so if you want to wait until the other work can be done, I'm fine
[20:18] <cyphermox> I'd rather it all be done yeahd
[20:19] <fginther> cyphermox, ok, I'll make a note in the MP
[20:19] <cyphermox> including pyruntest if possible, if anyone wants to pick it back up then we can just keep doing just the fixes in a stable branch
[20:19] <cyphermox> ok
[20:19] <cyphermox> thomi: ^^ how do you feel about branching pyruntest for a stable branch?
[20:20] <thomi> cyphermox: we're actually talking about deprecating pyruntest, since you can do everything with subunit & testtools
[20:20] <cyphermox> yeah, but still ;)
[20:21] <cyphermox> you know, there might still be bug fixes even though it's attained perfection already ;)
[20:21] <thomi> cyphermox: if someone else maintains it, that's fine with me, but I have too many projects on the go at once, and it's not particularly well written
[20:21] <thomi> Once martin gets back I'll be pushing that we adopt subunit & friends as our standard way of running python tests
[20:23] <bschaefer> Saviq, one thing, is rsalveti example didn't shift the arguments out, but the other example has this: shift $(( $OPTIND -1 )) soo that should work nicely :)
[20:23]  * bschaefer attempts
[20:23] <bschaefer> unless I missed something in his example :)
[20:23] <fginther> cyphermox, thomi, if we just need to create a '13.04' type branch, I don't have a problem with that. We can then remove it from head once it's removed from all projects?
[20:24] <Saviq> bschaefer, yeah
[20:25] <bschaefer> Saviq, cool, well ill be sure to poke you next when I have it working. Thanks for the links!
[20:30] <Saviq> bschaefer, cheers
[21:09] <bschaefer> Saviq, when you get a chance: https://code.launchpad.net/~brandontschaefer/unity/add-gdb-support-to-run-script/+merge/158465
[21:10] <bschaefer> order does matter, run options have to come before the qml-phone-shell options
[21:10] <bschaefer> (shift can't eat specific indexes)
[21:12] <Saviq> bschaefer, yeah, that's fine, didn't manage to get the -- to separate args to ./run from args to the binary?
[21:12] <bschaefer> Saviq, hmm well its not needed, but I can look into getting it that way
[21:12] <bschaefer> ./run -g -frameless works
[21:12] <Saviq> bschaefer, yeah I know it's not needed, but it's the convention
[21:12] <bschaefer> Saviq, oo alright, let me get that in
[21:13] <Saviq> bschaefer, also, please bring back --gdb
[21:13] <bschaefer> Saviq, getopts can only do single options :(
[21:13] <Saviq> bschaefer, --longopts?
[21:13] <Saviq> --longoptions, actually
[21:13] <bschaefer> Saviq, hmm what I read, it can only do single
[21:13] <bschaefer> Saviq, http://stackoverflow.com/questions/402377/using-getopts-in-bash-shell-script-to-get-long-and-short-command-line-options
[21:14] <Saviq> bschaefer, we even have long opts in ./build and ./build_unity
[21:14] <Saviq> bschaefer, and you did have them before
[21:14] <bschaefer> Saviq, but it uses getopt
[21:14] <Saviq> ah getopt vs. getopts
[21:14] <Saviq> bschaefer, use getopts, then
[21:14] <Saviq> as we do in the other scripts
[21:14] <bschaefer> yup, but I can look back at getopt and see if I can count up to N until we hit a --
[21:15] <bschaefer> Saviq, well the other scripts use getopt
[21:15] <Saviq> bschaefer, and they use --longoptions, I'm confused
[21:15] <bschaefer> Saviq, getopt can use --longoptions, getopts cannot
[21:15] <bschaefer> getopts loops through the options
[21:16] <bschaefer> err...
[21:16] <Saviq> ah got it, getopts is the bash thing
[21:16] <Saviq> while getopt is the cript
[21:16] <Saviq> script
[21:16]  * bschaefer is doing bad at explaining this
[21:16] <Saviq> confused the two
[21:16] <bschaefer> Saviq, yeah, the 's', but I can see if I can get getopt working
[21:16] <Saviq> bschaefer, yeah, should work fine I imagine
[21:16] <bschaefer> since we will have an order of things, and stop when we hit an '--', and count up
[21:16] <bschaefer> cool, let me play with that, im learning quite a bit about bash haha
[21:16] <Saviq> yup
[21:17] <Saviq> bschaefer, sorry to badger you like that, it's just a freakin' run script after all....
[21:17] <Saviq> but while we're at it, we might just as well make it more useful :)
[21:17] <bschaefer> Saviq, haha, no worries, I would prefer to do it right :)
[21:17] <bschaefer> yup!
[21:17] <bschaefer> should be easy to add more options after this
[21:20] <Saviq> afk
[21:58] <bschaefer> Saviq, when you return, i've got the branch ready. It shifts until it hits a '--' then breaks, leaving the args after the '--' untouched