[00:07] 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] 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] didrocks: ping [06:19] hey veebers [06:19] Hi didrocks how's everything? [06:20] didrocks: who can I annoy about this bug? https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1163358 [06:20] veebers: I'm good, thanks! yourself? [06:20] Launchpad bug 1163358 in ust (Ubuntu) "Missing liblttng-ust-ctl.so.0" [Undecided,Fix released] [06:20] veebers: it's fixed, isn't it? [06:20] * didrocks looks [06:20] didrocks: can't complain, days are getting colder and darker; but at least still some sun [06:20] didrocks: I'm experiencing the same issue even with that version (have commented on that bug) [06:21] veebers: the new soname is liblttng-ust-ctl.so.1 [06:22] 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] does that mean something is incorrect with lttng-tools? [06:22] veebers: right, I think lttng-tools wasn't rebuilt against latest liblttng-ust [06:23] veebers: I'm trying that, in a chroot [06:23] didrocks: cool, thanks [06:25] didrocks: Dinner is ready, I'll be back a little later on [06:26] veebers: enjoy! [06:26] veebers: hum, the -tools FTBFS [06:26] /usr/bin/ld: tp.o: undefined reference to symbol 'rcu_dereference_sym' [06:26] /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] /usr/lib/liburcu-bp.so.1: could not read symbols: Invalid operation [06:26] so I guess we can't just rebuild the old version [07:20] good morning [07:25] hiz [07:27] didrocks: d'oh that sucks, how do we/I proceed from here? [07:27] veebers: we are going to merge with debian, suck to do that that late though :/ [07:28] 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] didrocks: ah ok, thank you for taking care of that [07:28] no worry! [07:29] didrocks: what's a good way to ensure that we can maintain something? (i.e. from my point of view) [07:30] veebers: ensure that we have a good "ack" from distro people, bringing that to ubuntu-devel ML [07:30] veebers: as all the tools you are using, they should be maintained, so in main [07:30] didrocks: mostly I just check is there a ubuntu package? yes awesome I'll use it (for personal projects etc.) [07:30] and we need to figure out who will maintain them, and so on… [07:30] veebers: check the package is in main [07:31] didrocks: ack, thanks for the info. I'll share this sentiment with those involved too [07:31] excellent, thanks veebers ;) [07:31] oh something else [07:32] do not relaunch the generic job alone [07:32] this won't fix the -check jobs that are monitoring it [07:32] didrocks: ah ok [07:32] so, only do it if you want to check that a UTAH fix fixes something [07:32] what's the prefered way of doing that (instead of just building and c&p-ing the parameters) [07:32] veebers: do you know a little bit of daily release? [07:33] didrocks: a little bit, not a massive amount [07:33] 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] didrocks: yeah sure sounds good, or failing that at the sprint [07:33] veebers: yep, good as well :) [07:34] veebers: just remind me about it please! [07:34] didrocks: will do :-) [07:34] thanks ;) [07:53] hey [07:53] what happened to the hud in the indicators raring tests? [07:53] ups indicator->unity [07:55] seb128: what job are you talking about? [07:55] didrocks, http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-ati/41/testReport/ [07:55] this isn't the unity raring tests [07:55] this is the unity head tests [07:56] 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] you don't see it complicated there [07:56] so you don't have the run number [07:56] it will be either 42 or 43 I guess [07:56] clicked on the blinking "ps-generic-autopilot-release-testing" line [07:56] ok [07:57] I guess from the url I gave, I need to click on the #16 [07:57] the console output [07:57] and use the links in there when they will be in it? [07:57] right [07:58] but this only appears once the job finishes [07:58] one day I will manage browsing jenkins and find me way ;-) [07:58] not sure if jibel knows if there is a way to know about this before ^ [07:58] seb128: heh :) [07:58] but I agree, it's a PITA [07:58] and we need a dashboard to agregate that [07:58] (but I don't know if we have enough "running now" infos) [07:59] right [07:59] ok, I guess unity is red because the previous run fail on a broken ati round? [08:00] intel/nvidia numbers seem fine [08:00] seb128: yeah, yesterday's one [08:00] seb128: it was published [08:00] I asked mterry to do so [08:00] cool [08:01] hey sil2100! how are you? [08:01] didrocks: hello! Fine fine, fighting GIR a bit right now - what's up? [08:01] didrocks, sorry for the questions btw, trying to keep an eye on things daily and to get an hang of the details ;-) [08:01] sil2100, hey [08:01] seb128: no worry ;) [08:01] seb128: hello ;) [08:01] seb128: TBH, I had a look myself before ;) [08:01] hence the quick answer :p [08:02] sil2100: that bug about the qt popups, should it be fixed in raring already? [08:02] 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] didrocks: it should be ready today [08:03] sil2100: sweet! btw, can you update the spreadsheet once it's done with the criterias we have? [08:03] didrocks: it's basically ready, just don't want to modify too much code to make GIR work parallely [08:03] didrocks: ACK! [08:04] sil2100: thanks! :) [08:04] 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] 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] jibel: so, no way to know which run will have "this and this and this" parameters before it actually runs? [08:05] or that the -check job will trigger run #42 of this job? [08:05] (when it's waiting for job #41 to finish) [08:06] tsdgeos: shit, it didn't have a commit message, so it didn't get merged [08:06] sil2100: ouch [08:06] tsdgeos: re-approving [08:07] didrocks, not before they start. [08:09] jibel: so, jenkins just track that into memory for the jobs to run and no xmlrpc mechanism to query that? [08:13] mzanetti, hyum, so the whitespace test already made that happen (the 100% coverage), right? [08:17] didrocks, what's the vcs for unity-lens-video ? [08:17] didrocks, control says lp:~unity-team/unity-lens-video/trunk but that doesn't exist [08:18] Vcs-Bzr should be set to the right one? [08:18] oh [08:18] * didrocks tries with a s [08:18] interesting… [08:18] didrocks, I can't find it on https://code.launchpad.net/~unity-team [08:19] unity-lens-video: from cupstream2distro-config [08:19] let's see the latest build [08:19] didrocks, lp:unity-lens-video then? [08:19] that works [08:20] ~unity-lens-videos/unity-lens-video/trunk [08:20] didrocks, if I MR against that, it will land in raring? [08:20] Saviq: dunno which ones exactly [08:20] * didrocks blames again ken to have done something totally different for his scopes :/ [08:20] seb128: yep [08:21] seb128: do you mind changing Vcs-Bzr as well? [08:21] didrocks, thanks, should I update the control Vcs-Bzr [08:21] lol [08:21] will do ;-) [08:21] ;) [08:21] Thanks! [08:21] yw! [08:21] seb128: I think something with bzr+ssh://bazaar.launchpad.net/+branch/unity-lens-video/ should work [08:21] seb128: maybe trying with lp:unity-lens-video? [08:21] so that we really target trunk [08:21] whatever the name is [08:21] lp:unity-lens-video works [08:21] Saviq: but if a test opens every file, yes, that will cause that [08:21] mzanetti, http://bazaar.launchpad.net/~unity-team/unity/phablet/revision/575 [08:22] seb128: oh lp: works in Vcs-Bzr? awesome :) [08:22] why didn't we notice that before... [08:22] seb128: we should go with this short form for everything :) [08:22] mzanetti: you have whitespace, noOoOOoOOoOOoO [08:22] didrocks, ah, you meant for the Vcs-Bzr, sorry I though you were speaking about the target [08:22] 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] Saviq: yep. looks like it does [08:23] don't want to think how's this going to look like when we're pressed to do a release [08:23] tsdgeos, you don't [08:24] tsdgeos, you have local tests [08:24] tsdgeos, that you should run before committing [08:24] or at least before pushing [08:24] Saviq: tell mzanetti ;-) he did the hook and not even he is running it :D [08:24] tsdgeos: ? [08:25] * mzanetti has nothing to do with the whitespace thingie [08:25] mzanetti, he meant the on-commit test hook [08:25] tsdgeos, make qmluitests is too long, but make test should be fine [08:25] yeah... the commit hook doesn't work out [08:26] mzanetti, if we only run `make test`, that should be better [08:26] mzanetti: https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/158129 failed because of whitespace [08:26] 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] mzanetti, use qcommit, it will not kill your commit message [08:27] and doesn't QtCreator strip trailing wspaces by default? [08:27] Saviq: yes, it does [08:28] but yeah, regardless, we need to fix the QML coverage [08:28] Saviq: means disable it [08:28] ? [08:28] mzanetti, disable what? [08:28] the QML coverage [08:28] mzanetti, no, fix it [08:29] mzanetti, we don't need need no-qml unit tests on qmluitestrunner, do we? [08:29] -need [08:29] Saviq: the only way I see is not to have any tests that open all files [08:29] (in the short term) [08:30] we could define a new target tho [08:30] mzanetti, yeah, that's what I'm thinking [08:30] mzanetti, to not run the non-qml unittests on qmluitest jo [08:30] b [08:31] like "make whitespacetests" or the like [08:31] those could still be included in make alltests but not in the runtests.sh script [08:32] mzanetti, I was thinking the other way round [08:33] mzanetti, we only run qml tests on qmluitest job [08:33] mzanetti, it doesn't collect c++ coverage from there, does it? [08:33] Saviq: it does [08:33] Saviq: and also the make check target has contains qml-only tests too [08:33] mzanetti, that's fine [08:33] mzanetti, but only runtests.sh monitors the files opened [08:34] mzanetti, so we just need to make sure that runtests.sh only runs qml tests [08:34] both unit and UI [08:34] and, btw, won't the "alltests" target cut it already? [08:34] cut what? [08:35] mzanetti, `make alltests` runs all the qml tests, doesn't it? [08:35] mzanetti, but not the "usual" tests [08:35] Saviq: mall alltests run ALLtests [08:35] Saviq: make alltests run ALLtests [08:36] 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] Saviq: ok... so in the end we will have this: [08:36] mzanetti, no it doesn't [08:36] mzanetti, it's a custom target that we only add to via the add_qml_test macro [08:37] 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] mzanetti, if tests are only defined using add_test() [08:37] true... you're right... [08:37] mzanetti, they don't run on make alltests [08:37] 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] mzanetti, so can we generate c++ coverage from `make test` and qml coverage from `make alltests` [08:38] mzanetti, it's fine, we just have to cooperate [08:39] mzanetti, and those kind of things would bite us one way or another [08:39] Saviq, do you have a moment to discuss the tests I need to do for the infographics? [08:40] nic-doffay, in 20 mins? [08:40] Saviq, sure np. [08:41] didrocks, https://code.launchpad.net/~seb128/unity-lens-video/correct-search-hint-string/+merge/158294 [08:42] seb128: approved! thanks ;) [08:42] didrocks, thank you ;-) [08:43] mzanetti, so, that should fix qml coverage: http://pastebin.ubuntu.com/5697811/ [08:43] mzanetti, and we only need to make sure that `make check` is run in the job, too, to generate c++ coverage [08:44] mzanetti, is that not correct? [08:44] Saviq: yeah... but we should rename it to make qmltests and add another make alltests target to really execute alltests [08:44] mzanetti, sure [08:45] Saviq: people are not going to type 5 make targets before committing... knowing myself I'm actually already worried about one :D [08:45] mzanetti, I'm on it, can you take care of the job changes? [08:46] Saviq: are we going to remove the qml unittests from the make check target too then? [08:46] mzanetti, do we need to? is it a problem that they run twice? [08:46] mzanetti, I know it's time [08:46] Saviq: yeah... just thinking about time... [08:47] in that case we might merge unittests and qmluitests indeed [08:47] well... lets see how it grows [08:48] mzanetti, yeah, let's deal with it when it becomes a problem [08:48] mzanetti, TBH I miss the ability in CMake to have multiple test targets [08:50] Saviq: +1 [08:50] that would save us some hacks [08:50] I'll poke alexander :D [08:55] Saviq: I *think* the job should be ok... I runs make check too [08:57] Saviq: I guess I should disable the license check in jenkins again then... no need to run it twice [08:57] mzanetti, it's not merged yet, though [08:57] Saviq: ah no... there's still the issue with generated files [08:58] mzanetti, just noticed something [08:58] mzanetti, runtests doesn't take .js into account [08:58] mzanetti, that on purpose? [08:58] true... no... just forgot it [08:58] should do I'd say [08:59] mzanetti, fixing [09:00] 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] didrocks, ack, appended to my todolist [09:02] mzanetti, https://code.launchpad.net/~saviq/unity/phablet.fix-qml-coverage/+merge/158298 [09:03] Saviq: why are we not allowed to do in-source builds any more? [09:03] mzanetti, because they're evil [09:03] jibel: thanks :) [09:03] Saviq: no, they're convenient [09:04] Saviq: I fully agree that out of source builds must work and are a good thing [09:04] mzanetti, in-source builds hide issues [09:04] Saviq: but for just branching something, building running tests it just adds unneeded hazzle [09:04] mzanetti, ./build builds out of source for you [09:05] mzanetti, ./run runs out of source [09:05] mzanetti, the only thing is that you need to `make -C builddir`, which is, I agree, not convenient [09:05] mzanetti, and I'm thinking of "forwarding" make to builddir by default [09:05] should be doable by a simple static Makefile in top dir [09:06] Saviq: ./build forces me to build all deps from scratch [09:06] mzanetti, huh? [09:06] mzanetti, how so? [09:07] mzanetti, you just need a ../unity_build [09:07] Saviq: well, let me check better, just have ran it for the first time and it complains [09:07] and whether you're using colocated branches (which I recommend) [09:07] or just branches in dirs [09:07] you just need to make sure ../unity_build is there [09:08] and not care about it unless something changes there [09:11] mzanetti, out-of-source are just closer to what actually happens on the builders [09:11] mzanetti, just one more way to let us fail faster [09:11] Saviq: sure. still its not always required and anforcing it wastes time [09:11] mzanetti, how does it waste time? [09:12] mzanetti, IMO, the time saved when you forget something that will prevent an out-of-source build [09:12] is worth it [09:12] we just need to know about as many failures that might bit us in CI as possible [09:12] and as soon as possible [09:15] nic-doffay, hangout? [09:15] Sure Saviq [09:37] mzanetti, looks like it worked http://s-jenkins:8080/job/unity-phablet-ci/ [09:39] mzanetti, only source is unavailable for some reason [09:40] Saviq: yeah... because real coverage and qml coverage are not build in the same step any more (I think) [09:40] Saviq: but it didn't add any real value anyways [09:40] mzanetti, why? [09:40] Saviq: oh... its gone for c++ too [09:40] mzanetti, yeah [09:40] I thought only for qml [09:41] mzanetti, was it ever there for qml? [09:41] * Saviq might not have checked [09:41] Saviq: yeah... for some reason it started working once I enabled the c++ one [09:41] lol [09:45] 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] Saviq: the whitespace thing should print which lines [09:45] Saviq: or just fix them [09:46] mzanetti, to "just fix them" you can have a bzr hook, but the test should not do it [09:46] mzanetti, it'd have to push back to the branch ;) [09:46] Saviq: yeah, sure, not in the test... but somewhere [09:46] mzanetti, but lineno, sure [09:46] mzanetti, http://doc.bazaar.canonical.com/plugins/en/text-checker-plugin.html [09:46] Saviq: qtcreator does not remove them :/ [09:46] mzanetti, it should [09:47] * Saviq checks [09:47] Saviq: it does only in files he thinks belong to the project [09:47] Saviq: but since we're using CMake + qml... [09:47] mzanetti, just open the qmlproject, no? [09:48] Saviq: ok... qtcreator tries, but it doesn't work everywhere [09:49] Cimi: ping [09:49] dednick, pong [09:49] (which is news to me too) [09:49] Cimi: did you ever manage to get findChild working with the timer? [09:49] mzanetti, see, that's thanks to the whitespace test ;) [09:49] dednick, I didn't try [09:49] mzanetti, but yeah, I agree it would be nice to print out lines [09:49] Saviq: tbh thats one thing I already hated in Qt gerrit [09:49] dednick, I saw it was not working, so I moved to readonly properties [09:49] Cimi: ok [09:49] Cimi: thanks [09:50] mzanetti, at least here you can run the test locally and know straight away :D [09:50] Saviq: yeah [09:50] mzanetti, gerrit is git, doesn't git complain about whitespaces anyway? [09:50] Saviq: no [09:51] mzanetti, I think it's built-in, but configurable [09:59] 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] unless it's just to suck it up and wait. [10:00] 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] dednick: waiting 5 secs is not an option [10:01] 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] i think my head just exploded. ok. i'll give it a go :) [10:02] dednick: huh? [10:02] mzanetti: yeah, i thoush about the interval property [10:02] mzanetti: about fishing it out of the qml context. [10:02] dednick: tell me which file it is and I'll paste an example snippet [10:03] mzanetti: MenuContent.qml [10:04] sigh, this listview Qt bug is getting annoying [10:04] 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] :S [10:05] 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] mzanetti: ok sure. thanks [10:06] tsdgeos: hehe... the SignalSpy bug seems to be gone with 5.0.1 though [10:06] cool :-) [10:06] now let's update to 5.0.2 :D [10:08] Saviq: what'd be the correct blueprint "milestone" for that new hud task? Work items for ubuntu-13.04-month-5:? [10:08] tsdgeos, -6 [10:09] why 6? [10:11] tsdgeos: ubuntu-13.04-month-5 would mean you did it last month ;) [10:11] tsdgeos: it's an offset from the release schedule [10:11] month 1 in developping raring [10:11] and so on… [10:11] mzanetti, not really sure what to test of LensView if not the Timer [10:11] brrrrr [10:11] ok [10:12] tsdgeos: yeah, let's make it not easy, right? :p [10:12] the signals are emitted externally [10:12] * mzanetti opens LensView.qml [10:17] Cimi: yeah... there's really only that timer... [10:18] Cimi: I'd say let it be... [10:19] really doesn't look like anything useful can come out of that [10:30] mzanetti, https://code.launchpad.net/~saviq/unity/phablet.improve-check-whitespaces/+merge/158325 [10:32] ack [10:37] Saviq, wouldn't be easier to simply remove trailing whitespaces? [10:37] Cimi, no [10:37] Cimi, we would have to push back to the branch [10:37] Cimi, we don't want to do that [10:37] do we need them? :) [10:37] Cimi, no we don't, but that's our responsibility to not have them [10:37] Cimi, so whenever you run `make test` you'll know [10:37] Saviq, qtcreator removes them automatically for me [10:38] Cimi, yeah, sure, but that's not reliable enough [10:38] Cimi: Saviq: does not work all the time [10:38] Cimi, and now you can just `make test` and you'll know [10:38] Cimi, and there's http://doc.bazaar.canonical.com/plugins/en/text-checker-plugin.html for those that want to automate tings [10:38] things, even [10:38] mzanetti, to me it always worked [10:39] Cimi, but not everyone uses qtcreator, not for everything [10:39] Cimi, and we have non-Qt code in the tree now, too [10:39] Cimi: open a file and do: Ctrl+A, Ctrl+I, Ctrl+B... you'll end up with a few [10:40] also for very simple changes I don't use qtcreator but some command line editor [10:43] didrocks: [mzanetti] document what apps can run on the desktop: TODO [10:43] anything still needed? [10:44] 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] didrocks: all of the projects I've ever been involved have a -autopilot package [10:45] mzanetti: excellent, that's what we needed, so yeah, you can mark it as DONE [10:45] didrocks: ack [10:46] thanks! [10:46] didrocks: (apps and shell, that is) === MacSlow is now known as MacSlow|lunch [11:05] dont suppose anyone knows how to use a debugger with a qml file? [11:05] getting an odd segfault [11:06] mzanetti, any convention on the function we want to use to call before each test? like a particular initTest? [11:06] and gdb is less than usefull when it comes to qml stacktraces. [11:06] Cimi: no [11:06] dednick: yep [11:06] mzanetti, initTest is already used? [11:06] mzanetti, or I should skip the word Test? [11:06] Cimi: dunno... I haven't use one so far [11:06] ok [11:07] Cimi: probably skipping the word test makes sense, yes [11:07] Cimi: oh... btw [11:07] mzanetti, tst_Showable uses init_test [11:07] Cimi: for Qt in C++ if you have a function "void init()" it will be automatically called before each testcase [11:07] Cimi: try that [11:08] ok [11:08] 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] Cimi: same for cleanup() and cleanupTestCase() [11:08] mzanetti, in case we can improve tst_Showable [11:09] mzanetti, try renaming init_test to init() [11:09] remove the function calls [11:09] Cimi: I don't know if that works in QML too tho... you would need to test if first [11:09] and add a console.log :) [11:09] sure I am doing [11:09] before I need to finish my test [11:09]