[01:36] I am developing a syntax highlighter for the terminal using python code, and I need some help answering one question [01:36] Unity is going to be using qt5 ? [01:37] If my program is going to be compatible unity (and the hud and everything), do I need to design the ui for my app using qtcreator? [01:37] compatible with* [01:38] and further; will this be possible with python, seeing as no qt5 libraries exist for it yet? [02:27] Akiva-Mobile: i'd recommend to ping this channel again mid day for europe time for the best response [02:27] Akiva-Mobile: but, if you're starting from scratch, I'd recommend looking into qt/qml [02:27] kgunn: Dawww [02:27] Akiva-Mobile: i don't see a reason that would preclude use of python [02:28] Akiva-Mobile: but i'm not an expert either.... [02:28] python bindings for qt5 do not exist yet [02:28] Akiva-Mobile: ah [02:29] Akiva-Mobile: ...surprising [02:29] tho === jussi01 is now known as jussi === jono is now known as Guest75135 [07:36] good morning [07:43] yay! down to 27 merges :D [07:45] \o/ [07:51] didrocks: not much news on the skype problem. riddell has a list of missing symbols from packaging, but maybe that's not the real problem (or could it be?) [07:52] Mirv: ok, keep up pushing, we need to fix it one way of the other. I think let's take a decision by EOW [07:52] didrocks: ok [07:52] Mirv: do you know more about the documentation update for the sdk? [07:53] Saviq: man, i was just doing https://code.launchpad.net/~saviq/unity/phablet-mods.fix-resultiterator-warnings :D [07:54] you win by 10 minutes :D [07:54] tsdgeos, :D [07:54] didrocks: it's been in the discussions, but I don't know the latest status [07:54] tsdgeos, https://code.launchpad.net/~saviq/unity/phablet-mods.fix-resultiterator-warnings/+merge/158006 [07:54] Mirv: can you track and ensure it's fixed promptly? The documentation is wrong right now with what we support, not really good for developers… [07:55] didrocks: ok, will do [07:55] Saviq: btw the const should have been moved to the end of the function declaration in unity [07:55] but that's another story [07:55] thanks Mirv ;) [07:55] tsdgeos, they approved ;D [07:56] Saviq: you createing a merge request for build_unity too? [07:56] tsdgeos, yes, just checking that it works [07:57] oka [07:57] tsdgeos, /plugins/Unity/categories.cpp:0: Note: No relevant classes found. No output generated. [07:57] that's new? [07:57] it might [07:57] i saw it today too and stricked me as "did we have this before?" [07:58] probably new [07:58] why are we passing the cpp to moc? [07:59] well, one can define classes in the cpp, that's right, but not that common [07:59] tsdgeos, ah I know [07:59] tsdgeos, the CategoryFilter class was moved out of there [07:59] tsdgeos, need to drop the #include moc [07:59] right [07:59] or tweak it actually [07:59] so that automoc only looks at the header [07:59] and not the cpp [08:00] dropping the #include is "the right thing" if we're automoc'ing i think [08:02] tsdgeos, it has to be there, just #include "moc_categories.cpp", not "categories.moc", no? [08:03] tsdgeos, « if a source file contains an #include "foo.moc", the Q_OBJECT is expected in the source file itself and moc is executed accordingly. [08:03] if a source file contains an #include "moc_foo.cpp", the Q_OBJECT is expected in the corresponding header file foo.h, and moc is run on the header » [08:04] Saviq: where's that quote from? [08:04] tsdgeos, first stuff in google about automoc [08:04] tsdgeos, http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc [08:04] ok [08:04] tsdgeos, you can't contradict blogs.kde.org, you can't [08:04] i'd say that's old :D [08:05] Saviq: just remove the both includes in categories.cpp and categoryfilter.cpp [08:05] and see that it still works [08:05] is there a new The Right Way ™? [08:05] afaik in newer automocs you don't really "need" to include the moc [08:05] it'll be done for you [08:05] since basically including the moc is just a way to get the moc compiled [08:06] right, cool [08:06] and that's done by builddir/plugins/Unity/Unity-qml_automoc.cpp [08:06] yeah... I just converted xbmcremote from qmake to cmake and did not have to include those [08:06] so i'd just remove them [08:06] but won't complain if you prefer to move them to #include "moc_categories.cpp" [08:07] tsdgeos, or remove all of them altogether [08:07] tsdgeos, can you? [08:07] sure [08:07] * tsdgeos does [08:07] Saviq: should I set this to DONE? [08:07] work out a way to measure QML test coverage: TODO [08:07] or are we not satisfied yet? [08:08] mzanetti, yeah, and add another one to "improve ways to measure QML test coverage" at the bottom ;) [08:08] Saviq: there is already another one [08:08] mzanetti, ok then [08:08] integrate with Qt's Javascript engine to enable code coverage metrics for QML/JS code (similar to JSCover's approach): TODO [08:12] Saviq: I think I'll write a test now for the PeoplePreview thingies and then the only thing left are the Dashes. However, as I expect them to change a lot in the near future I'm not sure we should spend the effort right now. [08:12] Saviq: whats your opinion? [08:14] mzanetti, I'd expect the gist of it to not change, or at least in a way that should make the tests still valid [08:14] mzanetti, but not the Dash{Apps,Music} etc. [08:14] those will go away [08:14] * Saviq looks at the list again [08:15] mzanetti, so Dash/DashContent.qml should be relatively testable [08:15] Saviq: Dash/DashContent.qml. Thats one of our memory eaters in combination with LVWPH. I would expect that to change [08:16] mzanetti, hmm internally, yes [08:16] ok... if it just gets rid of the huge cachebuffer and adds some things to better cache/load invisible dashes tests might still work, yes [08:16] mzanetti, but externally not so much [08:18] eh. running qmluitests just killed my system... [08:19] Saviq: mzanetti: https://code.launchpad.net/~aacid/unity/remove_unneeded_moc_includes/+merge/158012 [08:19] dednick: lol [08:19] dednick, do we have qmluitests for the power indicator ;D [08:19] dednick: just commented in https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicators/+merge/157678 [08:19] lol [08:20] dednick: hey! I just posted a comment in the IndicatorItem tests MP [08:20] tsdgeos, https://code.launchpad.net/~saviq/unity/phablet.bump-unity-revision/+merge/158011 [08:20] dednick: with that change Cimi broke the IndicatorRow but your tests are still passing [08:21] dednick: https://code.launchpad.net/~unity-team/unity/phablet.test_IndicatorItem/+merge/157919 [08:21] tsdgeos, although we might wait for the merge to lp:unity/phablet-mods [08:21] mzanetti: thanks [08:21] Saviq: better :D [08:21] tsdgeos, it'd only really bite if people went and ./build_unity ;) [08:22] who does that! [08:22] not me :D [08:22] Saviq: phablet-mods *does* autoland, right? [08:22] tsdgeos, http://s-jenkins:8080/job/unity-phablet-mods-autolanding/11/ [08:22] oka [08:22] tsdgeos, you can see by "PS Jenkins: pending" review [08:23] right [08:23] tsdgeos, that jenkins is set up to do stuff [08:23] mzanetti, we found some issues with our jenkins set up, wanna have a look or should I find some of mmrazik minions (and I don't mean his daughters)? [08:24] Saviq: depends on what it is [08:24] * mzanetti reads [08:24] mzanetti, what do you reda? [08:24] *read [08:24] I thought it would get clear from your discussion with tsdgeos [08:24] mzanetti, we thought it might make sense to queue armhf builds _after_ i386 passed [08:25] Saviq: reason? [08:25] mzanetti, time [08:25] wouldn't that increase build time? [08:25] mzanetti, it would decrease turnaround time [08:25] tsdgeos: replied to your comment [08:25] Saviq: only on failures [08:25] mzanetti, indeed [08:25] Saviq: good runs would take longer [08:26] mzanetti, right so it would be fine for us, but for mir, not so much [08:26] mzanetti, could we cancel the jobs maybe? [08:26] mzanetti, i.e. if i386 fails, cancel the other jobs? [08:27] Saviq: hmm... also doesn't sound quite good. it hides later failures which in turn would again increase time it there more than 1 issues [08:27] dednick: so the icons weren't "working" before, no? [08:27] Saviq: I think what you want is to post failures immediately [08:27] mzanetti, yeah, that was my next proposla [08:27] Saviq: which _could_ lead to spam im rare cases [08:28] Saviq: we should only post failures or one summary on good runs [08:28] mzanetti, yeah, but failures you could post straight away [08:28] Saviq: ack [08:28] I think [08:28] lets go for that [08:28] Saviq: however, I think that's really mmrazik's domain [08:28] tsdgeos: this is just for the fake PluginModel. Previously there were no tests which exposed the issue (on the overview menu). [08:28] mzanetti, yeah, just fishing for an opinion here [08:29] Saviq: all the jenkins LP integration is his code. [08:29] Saviq: but in general, that would be something I would think adds value without impeding other things [08:29] mzanetti, yup, will file bug [08:29] mzanetti, another thing [08:29] dednick: ok [08:29] mzanetti, test runs are not atomic [08:29] mzanetti, i.e. http://s-jenkins:8080/job/unity-phablet-ci/386/ [08:30] mzanetti, passed on the builders [08:30] mzanetti, but conflicted on the VM [08:30] mzanetti, because stuff merged in trunk between the builders run [08:30] and the ui test run [08:30] Saviq: hmmm I see [08:31] mzanetti, do autopilot tests build its own version, too? [08:31] Saviq: yes [08:31] mzanetti, so maybe we should think of a way of passing the results from the build runs to the testers [08:31] by packaging the tests, too [08:31] Saviq: would double round trip time [08:32] mzanetti, how so? [08:32] Saviq: and for autopilot tests I wanted a release version without cobertura, coverity, debug symbold and all the show that makes it slower [08:32] yeah that's what I thought, too [08:33] mzanetti, maybe a common branch between the builders and the test machines? [08:33] mzanetti, small question, why you added tag to the data function? https://code.launchpad.net/~mzanetti/unity/phablet-test-sidestage/+merge/157921 [08:33] mzanetti, 'cause I could even imagine the tests to pass on i386 and fail on armhf [08:33] if armhf were queued and some conflicting merge happened during that time [08:33] Cimi: tags are printed in the output when running tests [08:34] mzanetti, ah useful, thanks for the tip! [08:34] Saviq: yes. can happen right now [08:34] Saviq: I'm just thinking if that actually causes a real problem [08:35] mzanetti, right, if there's a conflicting merge you need to merge anyway [08:35] Saviq: ok. I _could_ kill an autolanding job in very rare cases [08:35] dednick: can you quick fix avtive -> active in that branch? [08:35] Saviq: but in ci its actually a good thing. so you realize it right away and not only in autolanding [08:35] tsdgeos: sure [08:36] mzanetti, it might be just that we need to be aware of that [08:36] mzanetti, otherwise people get scared by what happened [08:36] +can [08:36] that builds worked but tests conflicted [08:36] Saviq: yeah... [08:36] Saviq: otoh I usually expect people to enable their brain when developing [08:37] its not that is a unsovable riddle [08:37] mzanetti, tyrant [08:37] haha [08:37] mzanetti, ok, so whether that's a feature or a bug is debatable, agreed [08:37] mzanetti, last thing http://s-jenkins:8080/job/unity-phablet-autolanding/154/ [08:37] mzanetti, autolanding only noticed after 25 mins that there's a conflict [08:37] tsdgeos: done [08:38] dednick: also do you really need the PluginModel.qml in the bzrignore? it seems it just ends up in the builddir here [08:38] Saviq: because it was queued? [08:38] tsdgeos: ah right. no, forgot i added the builddir after. [08:38] mzanetti, I don't think so [08:38] mzanetti, it was running for 25 mins [08:39] Saviq: well, it sais started 9 mins ago :D [08:39] dednick: ok, plz kill it! [08:39] mzanetti, hmm wrong job? [08:39] Saviq: oh... messed up... 9hrs that is [08:39] mzanetti, 9hrs [08:39] Saviq: yeah... let me check [08:39] and took 26mins [08:39] not sure if queue is included in that time [08:40] tsdgeos: done [08:40] Saviq: ok here's what happened: [08:40] dednick: tx [08:40] Saviq: ci job started, triggered all 5 downstream jobs [08:40] Saviq: most of them immediately failed, some of them had to wait in the queue [08:41] mzanetti, right, so the same issue as above [08:41] Saviq: the overall result was only posted once all failed [08:41] Saviq: yep. should be covered with your bug report [08:42] Saviq: thing is, the SDK guys copied my qmluitests job now and are with us on the same VM's [08:42] Saviq: if Mir does a commit, one of the 2 VM's is blocked for 1.5 hours [08:43] Saviq: unity-phablet is fast (~10 mins) but in average produces a new MP every 10 mins - so you could say we completely block the other VM [08:43] Saviq: and now SDK comes in too [08:43] mzanetti, yeah, saw that [08:44] dednick: i think i found a behaviour regression, writing it on the MR [08:44] Saviq: anyways, we have building new VMs in the queue... Now that the server has more resources [08:45] Saviq: also, switching to raring will decrease qmluitests time by around 5 mins [08:45] mzanetti, nice [08:46] so there are improvments ahead in that area. just not comming in today [08:47] dednick: added https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicators/+merge/157678 [08:48] tsdgeos: thanks, i'll take a look [08:49] Saviq: I'll prepopulate the quantal vm's with Qt5 now. that should give us the raring speedup already now [08:49] mzanetti, yeah, sounds good [08:49] (the problem is that installing Qt5 needs to replace also Qt4 which is what is killing those 5 mins) [08:53] Saviq, mzanetti what shall I do here? https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/157859 [08:53] Cimi: fix the other 2 comments I added and leave the precision as is [08:54] Cimi: after we collected the requirements as Saviq said, we'll fix all clocks we have [08:57] mzanetti, Cimi yup [08:57] mzanetti, about the long-running autolanding, is that on purpose that the test run starts along with the build runs? it's not the same in CI, is it? [08:58] Saviq: more precise please [08:58] you mean the mediumtests and qmluitests starting at the same time as the builders? [08:59] Saviq: oh yeah... autolanding and ci generated out of the same template [08:59] Saviq: right now there are small manual changes I made because the template didn't support collecting test results of multiple downstream jobs. [09:00] Saviq: but thanks to fginther it does now and I fixed our templates. Will deploy them today when fginther is around too. Starting then they will be 100% the same (except the name and merge target) [09:01] Saviq: but yeah, all downstream jobs start simultaneously. [09:02] mzanetti, is that the case for ci, too? [09:02] Saviq: yes [09:02] mzanetti, ah I thought it was on purpose that they waited [09:03] mzanetti, qml and medium were only ran after the builders completed, right? [09:03] Saviq: no... usually, when the VM queue is empty, the qmluitests are done even before the builders are [09:03] Saviq: no... I think you got confused by the generic-mediumtests job [09:03] Saviq: generic-mediumtests again has 2 downstream jobs: mediumtests-builder and mediumtests-runner [09:04] Saviq: those 2 are queued of course because the runner tests the build from the builder [09:04] mzanetti, riight, so it's only really queuing that can expose that "trunk changed between downstream jobs" issue [09:05] Saviq: in theory it _could_ happen while the builders are preparing themselves to build too. which is a quite short timeframe and very unlikely. [09:06] Saviq: but yeah. the queuing is the one that hit you [09:06] mzanetti, https://bugs.launchpad.net/ps-qa-tools/+bug/1167210 [09:06] Error: launchpad bug 1167210 not found [09:07] sorry ubot5 [09:07] hehe [09:18] Saviq: added my thoughts [09:18] mzanetti, cheers [09:20] mzanetti, another issue - https://code.launchpad.net/~jpakkane/unity/includecheck/+merge/158005 [09:21] mzanetti, it has a prerequisite, but doesn't actually include the prerequisite [09:21] mzanetti, which means it fails, because it just merges the branch on top of trunk [09:21] mzanetti, and until the other one lands that will fail [09:22] mzanetti, do you think we could have CI premerge prerequisites first? [09:22] or why can't we [09:22] Saviq: good one [09:22] Saviq: let me think... I guess the limitating factor here is the pbuilder itself... [09:23] limiwhat? [09:23] ;) [09:23] Saviq: it takes an argument for proposed branch and target branch [09:23] mzanetti, pbuilder itself? [09:24] Saviq: pbuilderjenkins that is... I think a modified version of the regular pbuilder [09:24] mzanetti, so it probably gets it as bzr+ssh://, no knowledge about LP, then [09:24] Saviq: yep [09:24] * Saviq files a bug anyway [09:24] Saviq: those are the parameters we use: http://s-jenkins:8080/job/unity-phablet-ci/362/rebuild/? [09:25] mzanetti, yeah I know [09:25] Saviq: I'm thinking if it would be possible to just give the prerequisite branch... but that won't work for chained prerequisites [09:25] mzanetti, so the job could prepare a list of premerges [09:25] mzanetti, and pbuilder would merge them in order [09:25] maybe limiting to 5 or so [09:25] and just fail straight away if there's more [09:25] Saviq: yeah... that would also fix the issue with different codebases for different builders [09:26] Saviq: or kill the feature of having the most recent possible codebase - depending how you look at it [09:26] mzanetti, how would that fix it? [09:27] mzanetti, no no [09:27] Saviq: but It could be solved with one initial job that does only merges of the target branch, walking through all the prerequisites into a temporary branch somewhere [09:27] mzanetti, i meant trunk + prereq + prereq + prereq + branch [09:27] mzanetti: pbuilder doesn't know about branch FYI [09:27] mzanetti: it only knows about source packages [09:27] didrocks, pbuilderjenkins does, apparently [09:27] didrocks: yeah... thats what I meant... [09:27] pbuilderjenkins is AFAIK just a wrapper starting pbuilder :) [09:27] like handling bzr [09:27] didrocks, yeah [09:27] and creating the source package [09:28] didrocks, so yeah, still, pbuilderjenkins needs to start caring about prerequisites ;) [09:28] yeah, this is fortunately something we are upstream for ;) [09:30] so all in all, that could be fixed, either by having a job that merges everything together into a temporary branch and then passing that one to the builders, or by making pbuilderjenkins aware of prerequisites itself [09:31] mzanetti, yup [09:36] mzanetti, https://bugs.launchpad.net/ps-qa-tools/+bug/1167240 (sorry ubot5) [09:36] Error: launchpad bug 1167240 not found [09:39] mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/157859 [09:41] mzanetti, checking if the time is updated properly is a bit difficult [09:41] because setting a date breaks the binding (1) and we need a minute to test if it updated (2) [09:42] tsdgeos, https://codereview.qt-project.org/#change,53235 :P [09:43] Saviq: working on it, Alan agreed with Andrew that removing the applyPendingChanges from count is probably the best way [09:43] and i'm going to do that and add some tests [09:44] Saviq: nothing to add to that bug report. [09:44] mzanetti, just mark it as affecting you ;) [09:44] tsdgeos, the ":P" is essential in what I wrote [09:44] i'm a bit weirded because some of the tests that are supposed to work are failing here [09:44] Saviq: however, the correct component would be jenkins-launchpad-plugin [09:45] Saviq: at least for the first one. but thats a proprietary one which jenkins-launchpad-plugin doesn't accept :D [09:45] already confirmed both, yes [09:45] mzanetti, cheers [09:48] Cimi: I though about just checking if the time changes automatically (i.e. label.text != cachedTextFromBefore) [09:49] Cimi: as you already have another test that check the calculation is correct you don't need to check for the exact string here, just make sure that the time is actually updating [09:49] yikes jenkins is failing today [09:49] Saviq: how? [09:50] mzanetti, IOErrors everywhere [09:50] noooooo [09:50] http://nooooooooooooooo.com/ [09:51] mzanetti, the time updates every minute [09:51] mzanetti, I can sleep for 60 seconds if you want :) [09:51] mzanetti, ps-panda-4 dying? [09:51] Cimi: you could set timer.interval = 1 for the test, no? [09:51] * mzanetti checks pandas [09:51] mzanetti, I need to create another property then [09:52] Cimi: oh right... missed that... I wouldn't export the timerRunning property [09:52] mzanetti, 4 failures with IOException on ps-panda-4 within the last hour or so [09:52] mzanetti, I'll add __ [09:52] Cimi: but rather use findChild() on the timer [09:52] mzanetti, doesn't work [09:52] mzanetti, it's not a child [09:53] interesting... does that only work for visible childs? [09:53] no... cant belive that... [09:53] maybe, didn't try [09:53] I tried with findChild and wasn't working [09:53] Saviq: I disabled panda-4 [09:55] tsdgeos: fixed the regression and added a test [09:55] good stuff :-) [09:55] * tsdgeos checks [09:59] I love it when a plan comes together (and the general flurry of activity) [10:02] dednick: that works, but i wonder why are we needing that extra code? [10:02] tsdgeos: if we go from hint -> locked without hitting reveal the menu's dont show. [10:03] it's unlikely, but it happened when manually setting progress values in tests. === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [10:05] dednick: i see, so you found a bug while testing that introduced the other bug, yes? === tvoss is now known as tvoss|sick [10:05] tsdgeos: yes [10:05] ok :-) [10:05] all clear now [10:05] :) [10:10] arg, replacing unity with kwin and then with unity again makes Alt+f4 not work [10:10] * tsdgeos logs out and in [10:13] mzanetti, dunno how to test it [10:13] mzanetti, when the time updates, date changes [10:14] but not necessarely the labels, because the labels are each minute [10:14] I can check if the date changes [10:15] Cimi: let me try [10:25] Cimi: can I push to your branch? [10:25] mzanetti, obviously [10:25] mzanetti, I put unity-team for collaboration in all my branches [10:29] Cimi: I found another issue: Qt.formatDate() creates a different string here because I use german date format in my system [10:30] Cimi: I've added one test function that takes care of that too. [10:30] Cimi: you just need to update the first test function to do the same [10:30] Cimi: pushed [10:31] Cimi: also feel free to rename my test function [10:31] mzanetti, I don't understand your wait(0) [10:31] especially the first one [10:32] you test the time is not running? [10:32] *timer [10:32] Cimi: right... need to change the timer interval... one sec [10:36] Cimi: you're right... Timers cannot be findChild()ed [10:36] sucks [10:36] Cimi: in that case we probably want to add a property alias interval: timer.interval [10:36] mzanetti, it exist [10:36] mzanetti, __timerInterval [10:36] mzanetti, I added it [10:37] hmm, thats nice [10:37] ciao sam :) [10:37] the arm builders seem to be running out of memory [10:37] Cimi: howdy [10:37] Cimi: ok... just set the interval to 1 and change the first wait to wait(5) or so [10:37] the transform origins for a QML item are by default the centre, correct? [10:37] Cimi: leave the second wait to 0 though [10:38] nic-doffay: not exaclty sure why you mean, but I would assume 0, 0 [10:38] nic-doffay: but it should be easy to find out, no? [10:38] It's not mentioned in the documentation. [10:38] I'll do some experimentation. [10:39] The answer is yes. [10:44] mzanetti, we could add if current time is 11:13 then don't test the last [10:44] no? [10:45] looks ugly both ways :D [10:45] * Cimi let's not add code [10:46] Cimi: maybe just a small (if time == "11:13") wait(60000) [10:46] indeed [10:52] mzanetti, pushed [10:54] Cimi: looks good [10:55] Cimi: I would have kept the test_customDate() though [10:56] mzanetti, I will add it [10:56] because that one passing a prerequisite of the new one to be useful [10:56] Cimi: if the test_customDate() would fail, the test_dateUpdate() is useless [10:56] mzanetti, I'll merge the two [10:57] mzanetti, put the customdate compare after the first three lines of dateUpdate() [10:57] I'd make it different cases. in case something fails its easier to debug [10:57] Cimi: ^ [10:57] nope [10:57] ues [10:57] ok [10:58] mzanetti, remember, debugging sucks, testing rocks [10:58] anyways... just add it back somehow and I'll approve [10:58] hehe [10:58]