Akiva-MobileI am developing a syntax highlighter for the terminal using python code, and I need some help answering one question01:36
Akiva-MobileUnity is going to be using qt5 ?01:36
Akiva-MobileIf 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
Akiva-Mobilecompatible with*01:37
Akiva-Mobileand further; will this be possible with python, seeing as no qt5 libraries exist for it yet?01:38
kgunnAkiva-Mobile: i'd recommend to ping this channel again mid day for  europe time for the best response02:27
kgunnAkiva-Mobile: but, if you're starting from scratch, I'd recommend looking into qt/qml02:27
Akiva-Mobilekgunn: Dawww02:27
kgunnAkiva-Mobile: i don't see a reason that would preclude use of python02:27
kgunnAkiva-Mobile: but i'm not an expert either....02:28
Akiva-Mobilepython bindings for qt5 do not exist yet02:28
kgunnAkiva-Mobile: ah02:28
kgunnAkiva-Mobile: ...surprising02:29
=== jussi01 is now known as jussi
=== jono is now known as Guest75135
mzanettigood morning07:36
tsdgeosyay! down to 27 merges :D07:43
mzanetti \o/07:45
Mirvdidrocks: 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:51
didrocksMirv: ok, keep up pushing, we need to fix it one way of the other. I think let's take a decision by EOW07:52
Mirvdidrocks: ok07:52
didrocksMirv: do you know more about the documentation update for the sdk?07:52
tsdgeosSaviq: man, i was just doing https://code.launchpad.net/~saviq/unity/phablet-mods.fix-resultiterator-warnings :D07:53
tsdgeosyou win by 10 minutes :D07:54
Saviqtsdgeos, :D07:54
Mirvdidrocks: it's been in the discussions, but I don't know the latest status07:54
Saviqtsdgeos, https://code.launchpad.net/~saviq/unity/phablet-mods.fix-resultiterator-warnings/+merge/15800607:54
didrocksMirv: 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:54
Mirvdidrocks: ok, will do07:55
tsdgeosSaviq: btw the const should have been moved to the end of the function declaration in unity07:55
tsdgeosbut that's another story07:55
didrocksthanks Mirv ;)07:55
Saviqtsdgeos, they approved ;D07:55
tsdgeosSaviq: you createing a merge request for build_unity too?07:56
Saviqtsdgeos, yes, just checking that it works07:56
Saviqtsdgeos, /plugins/Unity/categories.cpp:0: Note: No relevant classes found. No output generated.07:57
Saviqthat's new?07:57
tsdgeosit might07:57
tsdgeosi saw it today too and stricked me as "did we have this before?"07:57
tsdgeosprobably new07:58
tsdgeoswhy are we passing the cpp to moc?07:58
tsdgeoswell, one can define classes in the cpp, that's right, but not that common07:59
Saviqtsdgeos, ah I know07:59
Saviqtsdgeos, the CategoryFilter class was moved out of there07:59
Saviqtsdgeos, need to drop the #include moc07:59
Saviqor tweak it actually07:59
Saviqso that automoc only looks at the header07:59
Saviqand not the cpp07:59
tsdgeosdropping the #include is "the right thing" if we're automoc'ing i think08:00
Saviqtsdgeos, it has to be there, just #include "moc_categories.cpp", not "categories.moc", no?08:02
Saviqtsdgeos, « 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
Saviqif 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:03
tsdgeosSaviq: where's that quote from?08:04
Saviqtsdgeos, first stuff in google about automoc08:04
Saviqtsdgeos, http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc08:04
Saviqtsdgeos, you can't contradict blogs.kde.org, you can't08:04
tsdgeosi'd say that's old :D08:04
tsdgeosSaviq: just remove the both includes in categories.cpp and categoryfilter.cpp08:05
tsdgeosand see that it still works08:05
Saviqis there a new The Right Way ™?08:05
tsdgeosafaik in newer automocs you don't really "need" to include the moc08:05
tsdgeosit'll be done for you08:05
tsdgeossince basically including the moc is just a way to get the moc compiled08:05
Saviqright, cool08:06
tsdgeosand that's done by builddir/plugins/Unity/Unity-qml_automoc.cpp08:06
mzanettiyeah... I just converted xbmcremote from qmake to cmake and did not have to include those08:06
tsdgeosso i'd just remove them08:06
tsdgeosbut won't complain if you prefer to move them to  #include "moc_categories.cpp"08:06
Saviqtsdgeos, or remove all of them altogether08:07
Saviqtsdgeos, can you?08:07
* tsdgeos does08:07
mzanettiSaviq: should I set this to DONE?08:07
mzanettiwork out a way to measure QML test coverage: TODO08:07
mzanettior are we not satisfied yet?08:07
Saviqmzanetti, yeah, and add another one to "improve ways to measure QML test coverage" at the bottom ;)08:08
mzanettiSaviq: there is already another one08:08
Saviqmzanetti, ok then08:08
mzanettiintegrate with Qt's Javascript engine to enable code coverage metrics for QML/JS code (similar to JSCover's approach): TODO08:08
mzanettiSaviq: 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
mzanettiSaviq: whats your opinion?08:12
Saviqmzanetti, I'd expect the gist of it to not change, or at least in a way that should make the tests still valid08:14
Saviqmzanetti, but not the Dash{Apps,Music} etc.08:14
Saviqthose will go away08:14
* Saviq looks at the list again08:14
Saviqmzanetti, so Dash/DashContent.qml should be relatively testable08:15
mzanettiSaviq: Dash/DashContent.qml. Thats one of our memory eaters in combination with LVWPH. I would expect that to change08:15
Saviqmzanetti, hmm internally, yes08:16
mzanettiok... if it just gets rid of the huge cachebuffer and adds some things to better cache/load invisible dashes tests might still work, yes08:16
Saviqmzanetti, but externally not so much08:16
dednickeh. running qmluitests just killed my system...08:18
tsdgeosSaviq: mzanetti: https://code.launchpad.net/~aacid/unity/remove_unneeded_moc_includes/+merge/15801208:19
tsdgeosdednick: lol08:19
Saviqdednick, do we have qmluitests for the power indicator ;D08:19
tsdgeosdednick: just commented in https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicators/+merge/15767808:19
mzanettidednick: hey! I just posted a comment in the IndicatorItem tests MP08:20
Saviqtsdgeos, https://code.launchpad.net/~saviq/unity/phablet.bump-unity-revision/+merge/15801108:20
mzanettidednick: with that change Cimi broke the IndicatorRow but your tests are still passing08:20
mzanettidednick: https://code.launchpad.net/~unity-team/unity/phablet.test_IndicatorItem/+merge/15791908:21
Saviqtsdgeos, although we might wait for the merge to lp:unity/phablet-mods08:21
dednickmzanetti: thanks08:21
tsdgeosSaviq: better :D08:21
Saviqtsdgeos, it'd only really bite if people went and ./build_unity ;)08:21
Saviqwho does that!08:22
tsdgeosnot me :D08:22
tsdgeosSaviq: phablet-mods *does* autoland, right?08:22
Saviqtsdgeos, http://s-jenkins:8080/job/unity-phablet-mods-autolanding/11/08:22
Saviqtsdgeos, you can see by "PS Jenkins: pending" review08:22
Saviqtsdgeos, that jenkins is set up to do stuff08:23
Saviqmzanetti, 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:23
mzanettiSaviq: depends on what it is08:24
* mzanetti reads08:24
Saviqmzanetti, what do you reda?08:24
mzanettiI thought it would get clear from your discussion with tsdgeos08:24
Saviqmzanetti, we thought it might make sense to queue armhf builds _after_ i386 passed08:24
mzanettiSaviq: reason?08:25
Saviqmzanetti, time08:25
mzanettiwouldn't that increase build time?08:25
Saviqmzanetti, it would decrease turnaround time08:25
dednicktsdgeos: replied to your comment08:25
mzanettiSaviq: only on failures08:25
Saviqmzanetti, indeed08:25
mzanettiSaviq: good runs would take longer08:25
Saviqmzanetti, right so it would be fine for us, but for mir, not so much08:26
Saviqmzanetti, could we cancel the jobs maybe?08:26
Saviqmzanetti, i.e. if i386 fails, cancel the other jobs?08:26
mzanettiSaviq: hmm... also doesn't sound quite good. it hides later failures which in turn would again increase time it there more than 1 issues08:27
tsdgeosdednick: so the icons weren't "working" before, no?08:27
mzanettiSaviq: I think what you want is to post failures immediately08:27
Saviqmzanetti, yeah, that was my next proposla08:27
mzanettiSaviq: which _could_ lead to spam im rare cases08:27
mzanettiSaviq: we should only post failures or one summary on good runs08:28
Saviqmzanetti, yeah, but failures you could post straight away08:28
mzanettiSaviq: ack08:28
SaviqI think08:28
mzanettilets go for that08:28
mzanettiSaviq: however, I think that's really mmrazik's domain08:28
dednicktsdgeos: this is just for the fake PluginModel. Previously there were no tests which exposed the issue (on the overview menu).08:28
Saviqmzanetti, yeah, just fishing for an opinion here08:28
mzanettiSaviq: all the jenkins LP integration is his code.08:29
mzanettiSaviq: but in general, that would be something I would think adds value without impeding other things08:29
Saviqmzanetti, yup, will file bug08:29
Saviqmzanetti, another thing08:29
tsdgeosdednick: ok08:29
Saviqmzanetti, test runs are not atomic08:29
Saviqmzanetti, i.e. http://s-jenkins:8080/job/unity-phablet-ci/386/08:29
Saviqmzanetti, passed on the builders08:30
Saviqmzanetti, but conflicted on the VM08:30
Saviqmzanetti, because stuff merged in trunk between the builders run08:30
Saviqand the ui test run08:30
mzanettiSaviq: hmmm I see08:30
Saviqmzanetti, do autopilot tests build its own version, too?08:31
mzanettiSaviq: yes08:31
Saviqmzanetti, so maybe we should think of a way of passing the results from the build runs to the testers08:31
Saviqby packaging the tests, too08:31
mzanettiSaviq: would double round trip time08:31
Saviqmzanetti, how so?08:32
mzanettiSaviq: and for autopilot tests I wanted a release version without cobertura, coverity, debug symbold and all the show that makes it slower08:32
Saviqyeah that's what I thought, too08:32
Saviqmzanetti, maybe a common branch between the builders and the test machines?08:33
Cimimzanetti, small question, why you added tag to the data function? https://code.launchpad.net/~mzanetti/unity/phablet-test-sidestage/+merge/15792108:33
Saviqmzanetti, 'cause I could even imagine the tests to pass on i386 and fail on armhf08:33
Saviqif armhf were queued and some conflicting merge happened during that time08:33
mzanettiCimi: tags are printed in the output when running tests08:33
Cimimzanetti, ah useful, thanks for the tip!08:34
mzanettiSaviq: yes. can happen right now08:34
mzanettiSaviq: I'm just thinking if that actually causes a real problem08:34
Saviqmzanetti, right, if there's a conflicting merge you need to merge anyway08:35
mzanettiSaviq: ok. I _could_ kill an autolanding job in very rare cases08:35
tsdgeosdednick: can you quick fix avtive -> active in that branch?08:35
mzanettiSaviq: but in ci its actually a good thing. so you realize it right away and not only in autolanding08:35
dednicktsdgeos: sure08:35
Saviqmzanetti, it might be just that we need to be aware of that08:36
Saviqmzanetti, otherwise people get scared by what happened08:36
Saviqthat builds worked but tests conflicted08:36
mzanettiSaviq: yeah...08:36
mzanettiSaviq: otoh I usually expect people to enable their brain when developing08:36
mzanettiits not that is a unsovable riddle08:37
Saviqmzanetti, tyrant08:37
Saviqmzanetti, ok, so whether that's a feature or a bug is debatable, agreed08:37
Saviqmzanetti, last thing http://s-jenkins:8080/job/unity-phablet-autolanding/154/08:37
Saviqmzanetti, autolanding only noticed after 25 mins that there's a conflict08:37
dednicktsdgeos: done08:37
tsdgeosdednick: also do you really need the PluginModel.qml in the bzrignore? it seems it just ends up in the builddir here08:38
mzanettiSaviq: because it was queued?08:38
dednicktsdgeos: ah right. no, forgot i added the builddir after.08:38
Saviqmzanetti, I don't think so08:38
Saviqmzanetti, it was running for 25 mins08:38
mzanettiSaviq: well, it sais started 9 mins ago :D08:39
tsdgeosdednick: ok, plz kill it!08:39
Saviqmzanetti, hmm wrong job?08:39
mzanettiSaviq: oh... messed up... 9hrs that is08:39
Saviqmzanetti, 9hrs08:39
mzanettiSaviq: yeah... let me check08:39
Saviqand took 26mins08:39
Saviqnot sure if queue is included in that time08:39
dednicktsdgeos: done08:40
mzanettiSaviq: ok here's what happened:08:40
tsdgeosdednick: tx08:40
mzanettiSaviq: ci job started, triggered all 5 downstream jobs08:40
mzanettiSaviq: most of them immediately failed, some of them had to wait in the queue08:40
Saviqmzanetti, right, so the same issue as above08:41
mzanettiSaviq: the overall result was only posted once all failed08:41
mzanettiSaviq: yep. should be covered with your bug report08:41
mzanettiSaviq: thing is, the SDK guys copied my qmluitests job now and are with us on the same VM's08:42
mzanettiSaviq: if Mir does a commit, one of the 2 VM's is blocked for 1.5 hours08:42
mzanettiSaviq: 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 VM08:43
mzanettiSaviq: and now SDK comes in too08:43
Saviqmzanetti, yeah, saw that08:43
tsdgeosdednick: i think i found a behaviour regression, writing it on the MR08:44
mzanettiSaviq: anyways, we have building new VMs in the queue... Now that the server has more resources08:44
mzanettiSaviq: also, switching to raring will decrease qmluitests time by around 5 mins08:45
Saviqmzanetti, nice08:45
mzanettiso there are improvments ahead in that area. just not comming in today08:46
tsdgeosdednick: added https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicators/+merge/15767808:47
dednicktsdgeos: thanks, i'll take a look08:48
mzanettiSaviq: I'll prepopulate the quantal vm's with Qt5 now. that should give us the raring speedup already now08:49
Saviqmzanetti, yeah, sounds good08:49
mzanetti(the problem is that installing Qt5 needs to replace also Qt4 which is what is killing those 5 mins)08:49
CimiSaviq, mzanetti what shall I do here? https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/15785908:53
mzanettiCimi: fix the other 2 comments I added and leave the precision as is08:53
mzanettiCimi: after we collected the requirements as Saviq said, we'll fix all clocks we have08:54
Saviqmzanetti, Cimi yup08:57
Saviqmzanetti, 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:57
mzanettiSaviq: more precise please08:58
mzanettiyou mean the mediumtests and qmluitests starting at the same time as the builders?08:58
mzanettiSaviq: oh yeah... autolanding and ci generated out of the same template08:59
mzanettiSaviq: right now there are small manual changes I made because the template didn't support collecting test results of multiple downstream jobs.08:59
mzanettiSaviq: 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:00
mzanettiSaviq: but yeah, all downstream jobs start simultaneously.09:01
Saviqmzanetti, is that the case for ci, too?09:02
mzanettiSaviq: yes09:02
Saviqmzanetti, ah I thought it was on purpose that they waited09:02
Saviqmzanetti, qml and medium were only ran after the builders completed, right?09:03
mzanettiSaviq: no... usually, when the VM queue is empty, the qmluitests are done even before the builders are09:03
mzanettiSaviq: no... I think you got confused by the generic-mediumtests job09:03
mzanettiSaviq: generic-mediumtests again has 2 downstream jobs: mediumtests-builder and mediumtests-runner09:03
mzanettiSaviq: those 2 are queued of course because the runner tests the build from the builder09:04
Saviqmzanetti, riight, so it's only really queuing that can expose that "trunk changed between downstream jobs" issue09:04
mzanettiSaviq: in theory it _could_ happen while the builders are preparing themselves to build too. which is a quite short timeframe and very unlikely.09:05
mzanettiSaviq: but yeah. the queuing is the one that hit you09:06
Saviqmzanetti, https://bugs.launchpad.net/ps-qa-tools/+bug/116721009:06
ubot5Error: launchpad bug 1167210 not found09:06
Saviqsorry ubot509:07
mzanettiSaviq: added my thoughts09:18
Saviqmzanetti, cheers09:18
Saviqmzanetti, another issue - https://code.launchpad.net/~jpakkane/unity/includecheck/+merge/15800509:20
Saviqmzanetti, it has a prerequisite, but doesn't actually include the prerequisite09:21
Saviqmzanetti, which means it fails, because it just merges the branch on top of trunk09:21
Saviqmzanetti, and until the other one lands that will fail09:21
Saviqmzanetti, do you think we could have CI premerge prerequisites first?09:22
Saviqor why can't we09:22
mzanettiSaviq: good one09:22
mzanettiSaviq: let me think... I guess the limitating factor here is the pbuilder itself...09:22
mzanettiSaviq: it takes an argument for proposed branch and target branch09:23
Saviqmzanetti, pbuilder itself?09:23
mzanettiSaviq: pbuilderjenkins that is... I think a modified version of the regular pbuilder09:24
Saviqmzanetti, so it probably gets it as bzr+ssh://, no knowledge about LP, then09:24
mzanettiSaviq: yep09:24
* Saviq files a bug anyway09:24
mzanettiSaviq: those are the parameters we use: http://s-jenkins:8080/job/unity-phablet-ci/362/rebuild/?09:24
Saviqmzanetti, yeah I know09:25
mzanettiSaviq: I'm thinking if it would be possible to just give the prerequisite branch... but that won't work for chained prerequisites09:25
Saviqmzanetti, so the job could prepare a list of premerges09:25
Saviqmzanetti, and pbuilder would merge them in order09:25
Saviqmaybe limiting to 5 or so09:25
Saviqand just fail straight away if there's more09:25
mzanettiSaviq: yeah... that would also fix the issue with different codebases for different builders09:25
mzanettiSaviq: or kill the feature of having the most recent possible codebase - depending how you look at it09:26
Saviqmzanetti, how would that fix it?09:26
Saviqmzanetti, no no09:27
mzanettiSaviq: 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 somewhere09:27
Saviqmzanetti, i meant trunk + prereq + prereq + prereq + branch09:27
didrocksmzanetti: pbuilder doesn't know about branch FYI09:27
didrocksmzanetti: it only knows about source packages09:27
Saviqdidrocks, pbuilderjenkins does, apparently09:27
mzanettididrocks: yeah... thats what I meant...09:27
didrockspbuilderjenkins is AFAIK just a wrapper starting pbuilder :)09:27
didrockslike handling bzr09:27
Saviqdidrocks, yeah09:27
didrocksand creating the source package09:27
Saviqdidrocks, so yeah, still, pbuilderjenkins needs to start caring about prerequisites ;)09:28
didrocksyeah, this is fortunately something we are upstream for ;)09:28
mzanettiso 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 itself09:30
Saviqmzanetti, yup09:31
Saviqmzanetti, https://bugs.launchpad.net/ps-qa-tools/+bug/1167240 (sorry ubot5)09:36
ubot5Error: launchpad bug 1167240 not found09:36
Cimimzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/15785909:39
Cimimzanetti, checking if the time is updated properly is a bit difficult09:41
Cimibecause setting a date breaks the binding (1) and we need a minute to test if it updated (2)09:41
Saviqtsdgeos, https://codereview.qt-project.org/#change,53235 :P09:42
tsdgeosSaviq: working on it, Alan agreed with Andrew  that removing the applyPendingChanges from count is probably the best way09:43
tsdgeosand i'm going to do that and add some tests09:43
mzanettiSaviq: nothing to add to that bug report.09:44
Saviqmzanetti, just mark it as affecting you ;)09:44
Saviqtsdgeos, the ":P" is essential in what I wrote09:44
tsdgeosi'm a bit weirded because some of the tests that are supposed to work are failing here09:44
mzanettiSaviq: however, the correct component would be jenkins-launchpad-plugin09:44
mzanettiSaviq: at least for the first one. but thats a proprietary one which jenkins-launchpad-plugin doesn't accept :D09:45
mzanettialready confirmed both, yes09:45
Saviqmzanetti, cheers09:45
mzanettiCimi: I though about just checking if the time changes automatically (i.e. label.text != cachedTextFromBefore)09:48
mzanettiCimi: 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 updating09:49
Saviqyikes jenkins is failing today09:49
mzanettiSaviq: how?09:49
Saviqmzanetti, IOErrors everywhere09:50
Cimimzanetti, the time updates every minute09:51
Cimimzanetti, I can sleep for 60 seconds if you want :)09:51
Saviqmzanetti, ps-panda-4 dying?09:51
mzanettiCimi: you could set timer.interval = 1 for the test, no?09:51
* mzanetti checks pandas09:51
Cimimzanetti, I need to create another property then09:51
mzanettiCimi: oh right... missed that... I wouldn't export the timerRunning property09:52
Saviqmzanetti, 4 failures with IOException on ps-panda-4 within the last hour or so09:52
Cimimzanetti, I'll add __09:52
mzanettiCimi: but rather use findChild() on the timer09:52
Cimimzanetti, doesn't work09:52
Cimimzanetti, it's not a child09:52
mzanettiinteresting... does that only work for visible childs?09:53
mzanettino... cant belive that...09:53
Cimimaybe, didn't try09:53
CimiI tried with findChild and wasn't working09:53
mzanettiSaviq: I disabled panda-409:53
dednicktsdgeos: fixed the regression and added a test09:55
tsdgeosgood stuff :-)09:55
* tsdgeos checks09:55
SaviqI love it when a plan comes together (and the general flurry of activity)09:59
tsdgeosdednick: that works, but i wonder why are we needing that extra code?10:02
dednicktsdgeos: if we go from hint -> locked without hitting reveal the menu's dont show.10:02
dednickit's unlikely, but it happened when manually setting progress values in tests.10:03
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
tsdgeosdednick: i see, so you found a bug while testing that introduced the other bug, yes?10:05
=== tvoss is now known as tvoss|sick
dednicktsdgeos: yes10:05
tsdgeosok :-)10:05
tsdgeosall clear now10:05
tsdgeosarg, replacing unity with kwin and then with unity again makes Alt+f4 not work10:10
* tsdgeos logs out and in10:10
Cimimzanetti, dunno how to test it10:13
Cimimzanetti, when the time updates, date changes10:13
Cimibut not necessarely the labels, because the labels are each minute10:14
CimiI can check if the date changes10:14
mzanettiCimi: let me try10:15
mzanettiCimi: can I push to your branch?10:25
Cimimzanetti, obviously10:25
Cimimzanetti, I put unity-team for collaboration in all my branches10:25
mzanettiCimi: I found another issue: Qt.formatDate() creates a different string here because I use german date format in my system10:29
mzanettiCimi: I've added one test function that takes care of that too.10:30
mzanettiCimi: you just need to update the first test function to do the same10:30
mzanettiCimi: pushed10:30
mzanettiCimi: also feel free to rename my test function10:31
Cimimzanetti, I don't understand your wait(0)10:31
Cimiespecially the first one10:31
Cimiyou test the time is not running?10:32
mzanettiCimi: right... need to change the timer interval... one sec10:32
mzanettiCimi: you're right... Timers cannot be findChild()ed10:36
mzanettiCimi: in that case we probably want to add a property alias interval: timer.interval10:36
Cimimzanetti, it exist10:36
Cimimzanetti, __timerInterval10:36
Cimimzanetti, I added it10:36
smspillazhmm, thats nice10:37
Cimiciao sam :)10:37
smspillazthe arm builders seem to be running out of memory10:37
smspillazCimi: howdy10:37
mzanettiCimi: ok... just set the interval to 1 and change the first wait to wait(5) or so10:37
nic-doffaythe transform origins for a QML item are by default the centre, correct?10:37
mzanettiCimi: leave the second wait to 0 though10:37
mzanettinic-doffay: not exaclty sure why you mean, but I would assume 0, 010:38
mzanettinic-doffay: but it should be easy to find out, no?10:38
nic-doffayIt's not mentioned in the documentation.10:38
nic-doffayI'll do some experimentation.10:38
nic-doffayThe answer is yes.10:39
Cimimzanetti, we could add if current time is 11:13 then don't test the last10:44
Cimilooks ugly both ways :D10:45
* Cimi let's not add code10:45
mzanettiCimi: maybe just a small (if time == "11:13") wait(60000)10:46
Cimimzanetti, pushed10:52
mzanettiCimi: looks good10:54
mzanettiCimi: I would have kept the test_customDate() though10:55
Cimimzanetti, I will add it10:56
mzanettibecause that one passing a prerequisite of the new one to be useful10:56
mzanettiCimi: if the test_customDate() would fail, the test_dateUpdate() is useless10:56
Cimimzanetti, I'll merge the two10:56
Cimimzanetti, put the customdate compare after the first three lines of dateUpdate()10:57
mzanettiI'd make it different cases. in case something fails its easier to debug10:57
mzanettiCimi: ^10:57
Cimimzanetti, remember, debugging sucks, testing rocks10:58
mzanettianyways... just add it back somehow and I'll approve10:58
mzanettiThe guy setting up jenkins at Nokia had that written in huge letters on his office door :D10:58
Cimipushed btw11:01
=== MacSlow is now known as MacSlow|lunch
mzanettiCimi: the curstomDate() fails here. you need to use the dateString/timeString vars like in the other tests11:03
mzanettiCimi: rest looks good11:03
Cimiwhy would fail?11:03
Cimimzanetti, dateLabel has Qt.formatDate(__date, Qt.DefaultLocaleLongDate)11:05
mzanettiActual   (): Monday, October 13, 197511:06
mzanetti   Expected (): Monday, 13 October 197511:06
Cimimzanetti, tell me now11:10
tsdgeoscommas everywhere!11:16
=== pete-woods is now known as pete-woods|afk
cyphermox_Mirv: hey12:03
cyphermox_can you tell me more about why qtdeclarative isn't being built for powerpc?12:03
cyphermox_just checking if that's something I can help with, I didn't expect it, so I may need to update libhud-qt accordingly to avoid building on powerpc, or to fix qtdeclarative on powerpc12:04
=== MacSlow|lunch is now known as MacSlow
seb128cyphermox_, I think kenvandine said v8 is not supported on powerpc12:09
cyphermox_seb128: ah, thanks12:09
seb128that's an issue we should discuss on #ubuntu-devel if that hasn't been yet12:10
seb128it doesn't make sense to go and modify the arch list for every single qt5 user12:10
didrockskill powerpc ;)12:24
* didrocks goes back to take a shower12:24
didrocksmhr3: pstolowski: you should welcome finally the first round of the 100scopes features in the certified ppa :)12:29
pstolowskiyay! :)12:29
mhr3pstolowski, i see you took control of your hands this time ;)12:31
didrocksok, indicators tests finally passed as well12:33
didrockscyphermox_: ^12:33
=== cyphermox_ is now known as cyphermox
=== _salem is now known as salem_
Mirvcyphermox: yes, the qtjsbackend dependency12:36
cyphermoxdidrocks: did you mean indicators-raring? everything went through fine it seems12:43
didrockscyphermox: well, I had to relaunch is, there was some UTAH/installation issue this night12:44
cyphermoxyeah, figures12:44
=== hggdh_ is now known as hggdh
cyphermoxjust sayin' though12:44
didrocksso yeah "everything went through fine" after didrocks looked at it :p12:44
cyphermoxlet me handle "some of it" every once in a while :P12:44
didrockscyphermox: I wonder seriously if we shouldn't move the schedule for dailies12:44
didrockslike later, closer to your time of day12:45
cyphermoxnah, keep it as is12:45
cyphermoxor pull it *back*12:45
cyphermoxthat way I can easily check on it at EOD12:45
cyphermoxI already can, sometimes, if I'm up late12:45
didrockswe need to find a schedule matching everyone as we have dependencies between stacks12:46
cyphermoxbut like I said before, assuming we follow a UTC schedule, when it's your night, I can still make things work, and past my EOD you're not far from getting back online12:46
cyphermoxwe should confirm with mterry but I think he's in the same timezone as I am12:47
cyphermoxdepends how he wants to manage his time :)12:47
didrocksyep ;)12:47
cyphermoxif it's better, making the stuff run later is fine too12:48
cyphermoxbut I'm convinced we should be able to stagger the builds enough that in US timezones we can handle one run, and in EU timezones you can possibly handle another, so that it's easier for the tasks to be divided between us, and you don't just end up fixing everything before we get up :)12:49
cyphermoxnote, I love it, but it's not fair ;)12:49
* cyphermox starts creating the hud stack12:50
didrockscyphermox: I agree ;)12:50
didrockscyphermox: \o/12:50
didrockscyphermox: keep me posted!12:50
didrockssil2100: can you look at what cyphermox is doing for creating a stack? I think this will interest you as well ^12:50
sil2100didrocks: ACK12:51
sil2100cyphermox: any way I can help? I'm doing the indicator-messages stuff as well, but I you can out-source some work related to HUD to me as well12:52
cyphermoxI think I got the config right, now, I'll need to have didrocks and fginther double-check though, it's pretty complicated :)13:06
cyphermoxlooks simple when you think just about adding the two packages to a new stack13:07
cyphermoxbut then you also need to keep the old behavior where it makes sense13:07
cyphermoxso I pulled in the integration tests from indicators that made sense for hud13:08
cyphermoxhopefully that will remain not broken, though it will need to be checked13:08
cyphermoxfginther: pinging you again, because I can ;)  ^^13:08
* cyphermox needs to do a quick modemmanager bugfix upload13:09
sil2100cyphermox: ok, I'll review this13:09
didrockscyphermox: you should remove unity.tests.test_hud from the indicator stack13:10
cyphermoxI thought it didn't hurt to test that again in case it got broken by the indicators changes somehow13:10
fginthercyphermox, morning!13:11
didrockscyphermox: does the test exercise anything indicatorish?13:11
didrockscyphermox: if so, yeah, better to keep it :)13:11
cyphermoxfginther: don't ping me! you're hiding the top part of my terminal ! :D13:11
cyphermoxgood morning13:11
sil2100cyphermox: maybe we should also add some tests from test_search that are related to HUD?13:11
cyphermoxdidrocks: I don't know why / how the indicatos would break it though13:11
didrockscyphermox: ok, as you feel it ;)13:12
didrockscyphermox: libhud-qt-qml needs to be added IMHO13:12
cyphermoxsil2100: good catch, I think I saw one of those, didn't had it because it didn't include "hud"13:12
fginthercyphermox, I had a question yesterday about the qa stack when you get a chance, most of the projects have a raring branch now13:12
didrocksto the list of installed binary package13:12
cyphermoxfginther: yeah, I think it belongs being updated now that the branches have been branched13:12
didrockscyphermox: last thing, you need to add the dependencies between stacks (at least qa for autopilot), I think there is maybe on the indicators one for bamf?13:13
cyphermoxdidrocks: sil2100: I think I'd keep the tests as-is for indicators, but add the necessary bits to hud13:13
didrockscyphermox: and adjust the schedule to start just after those dependencies stack13:13
didrockscyphermox: apart from those small sniggets, excellent work! :)13:13
didrocks(for the daily release part)13:13
Cimimzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/15785913:20
didrockscyphermox: oh, why bamfdeamon in packages?13:20
didrockscyphermox: it's not part of the stack and should already be on the default iso13:21
didrockscyphermox: so not needed to list it13:21
didrocks(the packages are the binaries we are installing from this stack)13:21
cyphermoxseems to me like it goes along with libbamf ;)13:21
didrocksyeah, same reason for libbamf3-113:21
didrocksremove it :)13:21
cyphermoxthen neithr are useful yeah13:21
cyphermoxsorry, I understood you meant I should list them13:21
didrocksno worry, I was talking about the dependencies on indicators because of it :)13:22
cyphermoxI misunderstood13:22
didrockscyphermox: unity.tests.test_search is for the hud or libcolumbus or both?13:22
cyphermoxit's updated nao13:22
cyphermoxAFAIK it does both13:22
cyphermoxexercise libcolumbus via hud.13:22
didrockscyphermox: you should keep it as well in the indicators stack then13:23
cyphermoxindeed, I should13:23
mzanettiCimi: why does jenkins fail on your MP?13:23
cyphermoxdidrocks: actually13:24
cyphermoxshouldn't we rather move libcolumbus to the hud stack?13:24
cyphermoxbeing the principal user and all13:24
didrockshum, good question13:24
didrocksunity dash as well will use it13:24
didrocksbut it's depending on the HUD13:24
didrocksso yeah, you may be right13:24
didrockscyphermox: I think let's go with your proposal13:25
cyphermoxperhaps I'll do that, and we'll get libcolumbus already building13:25
cyphermoxI'll just make sure it's properly transitioned first13:25
didrockscyphermox: so unity should deps on the hud stack as well, mind doing that change?13:25
didrocksapart from that, everything looks gorgious for daily-build13:25
cyphermoxfginther: btw, if you want to make a qa-magic-branching doo-da on libcolumbus ;)13:26
didrocksnot sure for CI, I don't have this knowledge ;)13:26
Cimimzanetti, dunno, I don't have the vpn set up anymore13:26
mzanettiCimi: you don't need that to see the failures13:27
mzanettiCimi: and second, you still should :D13:27
seb128sil2100, hey, small comment, when you edit workitems, please refresh the page before13:27
Cimimzanetti, yeah upgraded to raring13:28
seb128sil2100, you reverted changes made 4 hours before your edit on client-1303-delivering-touch-apps-to-raring yesterday13:28
seb128sil2100, I restored them so no worry13:28
seb128(yeah, launchpad sucks for that, it should warn about edit conflicts)13:28
sil2100seb128: sorry about that! I could have refreshed13:29
seb128no worry ;-)13:29
sil2100But I actually thought that there is a 'conflicts' message indicator when that happens13:29
didrocksnothing on that, you are not the first ;)13:30
dednickomg my calendar sucks so badly. no matter what i do it wont give me alerts!13:31
Saviqdednick, it's google, actually13:33
Saviqdednick, the invite doesn't have alerts attached by default13:34
fginthercyphermox, sorry, I don't have permissions for libcolumbs13:34
cyphermoxfginther: sorry, I figure I didn't need to ask you13:34
cyphermoxI'm dealing with Jussi directly for that13:34
dednickSaviq: yeah, i'm put it in manually. But the thunderbird ones wont work13:34
fginthercyphermox, no worries.13:34
fginthercyphermox, do you have anything prepared for the qa stack split? If not I'll prepare an MP.13:35
cyphermoxso I'm going to file a separate merge to fix up libcolumbus in the indicators stack independently from the current changes13:35
cyphermoxnothing prepared for that yet, no13:35
cyphermoxfginther: well, it depends13:35
cyphermoxI think it's just a matter of editing stacks/raring/qa.cfg slightly13:35
cyphermoxdidrocks: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/libcolumbus-branch/+merge/15810813:42
didrockscyphermox: you want to make the change in head separated?13:42
cyphermoxdidrocks: yeah, head will get changed with the other branch13:42
cyphermoxI'll move libcolumbus in hud13:43
cyphermoxbut this one belongs being separate, so the change isn't delayed by the hud stack13:43
didrockscyphermox: perfect for me, approved :)13:43
cyphermoxsil2100: are the tests we want indeed the two you listed in your comment?13:44
sil2100cyphermox: yes, since there are 4 suites in the test_search package - two for application lens and two for HUD, so I guess those two are what we want13:45
cyphermoxok, that's done now13:47
cyphermoxdidrocks: ^ I also moved libcolumbus13:47
cyphermoxcoffee isn't agreeing with me this morning13:48
cyphermoxI feel sick :/13:48
fginthercyphermox, FYI, I'm reviewing the hud stack MP, it's a little tricky ;-(13:48
didrockscyphermox: urgh :/13:49
cyphermoxfginther: yeah, I know :/13:49
cyphermoxI tried to keep the logic that was already there in phablet/qt.cfg13:49
didrockscyphermox: +1 from my side13:49
cyphermoxbut I also had to bring in some stuff from indicators13:49
cyphermoxfginther: don't hesitate to tell me it's all wrong, I just don't know enough about the CI jobs to be able to tell13:50
didrockscyphermox: oh, just one thing, think about adding a dep in the unity stack on the hud stack13:51
cyphermoxdidrocks: yes!13:51
didrockscyphermox: otherwise, everything's perfect for me :)13:51
fginthercyphermox, yeah, we didn't really anticipate moving projects around much, makes for a bit of pain when the default sections are different13:52
fginthercyphermox, but as we get better at this, I'm hoping the projects will begin to converge and there will be fewer special cases13:53
cyphermoxfginther: didrocks: I wonder if it actually makes so much sense to have the ci jobs separated by stacks, rather than all flat13:53
didrockscyphermox: well, normally, I think most of factorized CI jobs parameters are in a default file13:54
cyphermoxsince it's pretty unrelated to the actual release process, and really just needs to get built, and merged, in a pretty isolated and per-branch fashion13:54
didrocksthen, it's overriden by stack/components13:54
didrocksnot sure in practice if they have enough factorized stuff13:54
cyphermoxfginther: didrocks: is there a document that outlines all of the config options currently used, their expected syntax, etc.?13:55
cyphermoxthat would be useful13:55
cyphermoxsince right now the ci changes that need to follow components I'm doing blindly, without having any idea of the net effect13:56
didrockscyphermox: for DailyRelease, it's in the wiki, latest ones are not listed though (like the dependencies and so on), I need to do that13:56
didrockscyphermox: for CI, I don't know13:56
cyphermoxdidrocks: thanks13:58
cyphermoxsergiusens: hey14:00
sergiusenscyphermox: here I am14:01
cyphermoxwhat do you mean by hud diverged?14:01
sergiusenscyphermox: let me save this channel :-)14:01
cyphermoxthis is explicitly to make the builds for phablet :)14:01
sergiusenscyphermox: for hud in raring, the one we have in our PPA at least (ppa:phablet-team), it's a version rolled back about 50 revisions14:02
cyphermoxsergiusens: so not equivalent to lp:hud/phablet?14:02
sergiusenscyphermox: the one in lp:hud/phablet at least, which if I recall, didrocks was going to make that the new trunk14:03
cyphermoxit's a good catch, we need to merge lp:hud/phablet into lp:hud like, post-haste14:03
cyphermoxso where is the code for the hud you use?14:04
tsdgeosQt 5.0.2 http://blog.qt.digia.com/blog/2013/04/10/qt-5-0-2-released/ :-)14:04
sergiusenscyphermox: this is the reason: https://launchpad.net/~phablet-team/+archive/ppa/+build/446383014:05
sergiusenscyphermox: after the demo, it was stuck on a revision, there is no more work going into it14:05
cyphermoxsergiusens: so where should I get hud?14:06
cyphermoxI'm sorry, I just need to be extremely clear with everything so that there are no mistakes14:07
cyphermoxis lp:hud/phablet not the right branch for the hud code that we are landing in raring for phablet?14:07
sergiusenscyphermox: that's more of a ted question, there was a divergence I wasn't aware of and noticed last week14:08
cyphermoxwell, if the issue is indicator-appmenu, let me jsut quickly make sure that's already fixed14:08
sergiusenscyphermox: they aren't using the phablet-team ppa for a while either (change I wasn't told about either) for lp:hud/phablet14:08
cyphermoxso right now you're just shipping an old hud14:09
cyphermoxyuck yuck yuck14:10
sergiusenscyphermox: yes...14:10
cyphermoxok... so I'm going to pull out my nexus 4 now, and try to build this hud on the current faily image14:10
cyphermoxsee how far it goes and what needs fixin'14:11
sergiusenscyphermox: well there is a bamf thing you might want to check with Saviq14:11
cyphermoxsergiusens: so, why does it matter with the landing job though?14:12
sergiusenscyphermox: because phablet-land pushes to ppa:phablet-team14:12
cyphermoxfair enough :)14:12
sergiusensSaviq: https://launchpad.net/~phablet-team/+archive/ppa/+packages?field.name_filter=bamf&field.status_filter=published&field.series_filter=14:13
cyphermoxso assuming hud/phablet magically builds fine, I'll leave the config as it is, since it would pretty much do what we want anyway14:13
Saviqsergiusens, actually... I think we can get rid of it from ppa:phablet-team14:14
sergiusensSaviq: if that's the case, then there is nothing to worry about14:14
Saviqsergiusens, with some tweaks in lp:unity/phablet-mods14:14
cyphermoxnexus 4 battery, you make me sad.14:14
sergiusensSaviq: just for raring or quantal too?14:15
Saviqsergiusens, both14:15
sergiusensSaviq: ok, cyphermox we'll need to wait for those fixes14:15
cyphermoxthe what?14:15
didrockssergiusens: which fixes?14:16
=== dandrader is now known as dandrader|afk
sergiusenslp:unity/phablet mods to get rid of the bamf in pp:phablet-team so hud can build14:17
didrockssergiusens: how is this ppa impacting daily release which is targetting lp:hud?14:17
didrockswith lp:hud/phablet merged into lp:hud14:17
sergiusensdidrocks: nothing really14:18
sergiusensdidrocks: I was just saying: don't use phablet-land as the autolanding job14:18
didrockscyphermox: can you remove this autolanding job parameter then? ^14:18
didrockssergiusens: then, I think you will go with manual merging until you can use lp:hud14:18
Saviqsergiusens, can I get a quick update on what's going on?14:21
Saviqand what do we need to do?14:21
sergiusensSaviq: well if we can get rid of bamf, that would be good... but let me come back to that14:24
sergiusensSaviq: daily releases are being setup, that's what's going on14:24
sergiusensSaviq: but I'm only half aware of the whole thing as I was kept out of the loop for the first half of this14:25
Saviqsergiusens, and why do we need to get rid of bamf?14:25
sergiusensSaviq: latest hud needs a newer bamf to build14:26
Saviqsergiusens, so we don't need to get rid of it, but we need to upgrade it ;)14:28
Saviqsergiusens, I assume it's not there for quantal14:28
Saviqthere as in in distro14:28
sergiusensSaviq: yeah, we need to get rid of the version bump for raring14:28
sergiusensSaviq: yeah, just for raring and beyond14:28
=== dandrader|afk is now known as dandrader
fginthercyphermox, hud stack mp reviewed14:33
Saviqsergiusens, now that you said it I don't know why I bumped the version there...14:34
cyphermoxfginther: I'd kiss you if I wasn't so busy ;)14:35
sergiusensSaviq: ah, it gets complicated :-)14:35
fginthercyphermox, :-)14:36
Saviqsergiusens, I'm dropping the package from raring14:38
Saviqsergiusens, I don't _think_ it will break anything ;)14:39
sergiusensSaviq: ok14:39
Saviqsergiusens, and will update it for quantal14:39
Saviqsergiusens, do we need to remove it from some cache for the images?14:40
sergiusensSaviq: no, but I can get webops to do a delete14:41
Saviqsergiusens, and could we simply have daily builds of bamf in phablet-team PPA for quantal?14:41
sergiusensSaviq: of latest and greatest bamf?14:41
Saviqsergiusens, yea14:41
Saviqsergiusens, bamf 0.4.0daily13.04.03-0ubuntu1 is enough for the new hud?14:42
Saviqsergiusens, same for hud, really, we want it for quantal, too, right?14:42
sergiusensSaviq: rsalveti wanted us to target a cutover to raring this week, not sure quantal is worth it14:43
Saviqsergiusens, fine by me14:44
sergiusenscyphermox: read above ^^14:44
* rsalveti reading14:44
cyphermoxI don't know; does it actually need bamf at all?14:44
rsalvetiyeah, hopefully raring will be good enough for the switch later this week14:45
cyphermoxtedg was mentioning platform-api more14:45
Saviqcyphermox, yes it does14:46
Saviqcyphermox, it finds out about apps from it for now14:46
cyphermoxbecause you see, I'm about to try to build with a --disable-bamf switch ;)14:46
cyphermoxok, no such switch, but if there is no such package, it looks (quickly) like things should build14:48
Saviqcyphermox, it won't work on the desktop, is all14:49
Saviqcyphermox, the phone does not have bamf indeed14:49
cyphermoxSaviq: that's fine14:49
cyphermoxon the phone, we won't have bamf, so we will build without bamf for arm14:50
Saviqcyphermox, we only had it for legacy unity (that we still build libunity-core-6.0 out of)14:50
cyphermoxon the desktop, we do have it so we can build with it14:50
Saviqcyphermox, yup14:50
cyphermoxSaviq: so do you think we're good?14:50
Saviqcyphermox, yeah, I'd say so14:50
Saviqcyphermox, if we don't care about quantal, we can drop bamf from the PPA altogether14:51
cyphermoxSaviq: don't need to just now, I'd say14:52
cyphermoxI'm mostly thinking about ubuntu-unity/daily-build-next PPA14:52
cyphermoxthen we can fix stuff later if it just means deleting packaged14:52
cyphermoxok, can't really "disable" bamf per-se, I'll file a merge request after to make that possible14:53
cyphermoxbut I can hack the build-depends now to ensure libbamf is only required on !armhf14:54
didrockshey mterry! did you look at unity? I tried to relaunch the tests, but I guess ati is dead…15:00
didrocksmterry: the results seems good on the other config, forcing publication? I know that slangasek would really like having his patch in ubuntu :p15:01
mterrydidrocks, last I checked, it was still running15:05
* mterry looks15:05
mterrydidrocks, ah yes, the ati is dead thing  :)15:06
didrocksmterry: yeah, seeing it's running for more than the regular time, I think that the hud service crashes or something like that15:06
didrocksat some point, we'll need to check with thomi on how to detect that and relaunch the session15:06
didrocksand fix the crash as well :p15:07
Cimimzanetti, mouseFlick has a speed parameter in UnityTestCase15:07
mterrydidrocks, yeah I'm fine with a manual push15:07
Cimimzanetti, who uses speed?15:07
didrocksmterry: \o/ please do, I'm sure you can easily poke slangasek once in unapproved to get it reviewed15:07
mzanettiCimi: wasn't it you who added that?15:07
CimiI am wondering if my implementation with duration was better15:07
didrocksmterry: just a feeling ;)15:08
mzanettiCimi: for the BottomBar tests15:08
Cimimzanetti, I added duration15:08
mzanettiCimi: ah ok... then it might have been greyback15:08
Cimimzanetti, mines wait15:08
Cimimzanetti, this one relies on faketime15:08
CimiI don't think this works for me15:08
greybackmzanetti: Cimi: frankly I don't notice a difference with changing the speed really.15:08
Cimigreyback, because this doesn't change the speed15:09
Cimigreyback, you need to add wait to change the speed15:09
Cimiwith this fake time15:10
Cimithe action is instant15:10
Cimi(you can move 1000 pixels in 1ms)15:10
Cimithen you obtain a fake time "yay, it took you 10s!"15:11
Cimiin reality the mouse movement passed to QML should be 1000px per ms15:11
greybackCimi: I expect you're right15:11
Cimiwhat I did was adding a wait in the for15:11
Cimimove 100px, wait 10ms, another 100px, 10ms etc15:12
greybackCimi: you can add the 4th parameter to mouseMove which adds a delay15:12
Cimigreyback, https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/15084715:12
Cimithis requires fixes (conflicts now with speed parameter)15:12
Cimigreyback, you can see the duration parameter15:13
Ciminow we have speed as 8th parameter15:13
Cimishall we keep speed? (who uses it?)15:13
Cimiand add duration?15:13
Cimior I can add a boolean as 9th parameter which adds a wait proportional to the speed set15:14
Cimiso for each cycle, not only update fakeTime but also wait the proportional ms15:14
greybackCimi: just need 2 params, distance and speed should be enough15:14
Cimigreyback, I'll add 9th as boolean?15:15
nic-doffayGuys, I have some spare time for the rest of the day. Can I help anyone with anything?15:15
greybackCimi: dude, 9 params? No come on, it needs to be simpler15:15
Cimigreyback, I don't want to break who added 'speed'15:16
greybackCimi: fix the other tests, as opposed to adding cruft15:16
greybackCimi: and if need be, a separate MR15:17
Cimigreyback, if somebody explains me why they added speed maybe I could do15:17
Cimiand why they didn't use wait but this fake time15:17
Saviqnic-doffay, read through https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests/+merge/155914 then15:17
greybackCimi: find who did it. "bzr blame" will show you who15:17
Saviqnic-doffay, and have a stab at doing the same for infographics15:17
nic-doffayWill do Saviq15:18
mzanettianyone here up for a review? https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/15812915:18
* mzanetti needs to go buy food. bbiab15:18
Cimidandrader, where are you using speed in mouseFLick?15:19
Cimidandrader, is it working for you?15:19
nic-doffaymzanetti, sure. I'll review now, also need to go to the shops quick!15:19
Saviqmzanetti, half of the result of that test are warnings ;)15:19
Saviqmzanetti, sounds like we should look at getting rid of them?15:19
dandraderCimi, let me check.15:20
andyrockmterry, ping15:20
mzanettimy gf cancelled the shopping tour15:20
mterryandyrock, hello15:20
andyrockmterry, hey, can we merge this branch now? https://code.launchpad.net/~mterry/unity/lens-friends/+merge/15658415:20
mzanettiSaviq: yeah.. probably. should I fix them with this MP?15:20
mterryandyrock, oh...  that shouldn't be necessary anymore15:21
mterryandyrock, unity must have been rebuilt with the latest libunity by now15:21
andyrockmterry, sweet... so can you delete this MP? :)15:22
mterryandyrock, just marked it rejected15:22
dandraderCimi, check test_maxFlickSpeedToLaunchApp in tst_Launcher.qml. It's just to fool DragginArea's speed calculation15:22
andyrockmterry, thanks15:22
greybackCimi: https://pastebin.canonical.com/88855/ works nicely for me. Speeds < 1 are nice and slow15:22
Cimidandrader, does work for you if you change speed?15:23
dandraderCimi, of course15:25
Cimidandrader, mmm15:25
dandraderCimi, but, again, only for DraggingArea. not for qml in general15:25
Cimidandrader, I don't like this fakedatetime15:25
Cimidandrader, I think a wait is enough15:26
dandraderCimi, how reliable will that be?15:26
Cimidandrader, instead of passing fake date times15:26
Cimidandrader, you add a wait to the mouseflick15:27
Cimidandrader, it works, without having to add code all around unity to fake slow events15:27
dandraderCimi, and then you get varied results depending on how fast is the machine where the test is run15:27
Cimidandrader, tests take some extra ms15:27
Cimidandrader, no15:27
Cimidandrader, because wait is a wait15:27
Saviqmzanetti, yeah, I'd say so15:28
mzanettiSaviq: yeah. already fixed most. Half of them are because of the shell.activateApplication() though15:28
mzanettiSaviq: which has a todo on it: // FIXME these should trigger actions on the lens/scope, when there's support15:28
Cimidandrader, if you look at https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/15084715:28
Cimidandrader, I had the same problem for my dashbar using dragging area15:29
Saviqmzanetti, right, let's not fix those, then15:29
mzanettiSaviq: I'll fix the others tho15:29
Cimidandrader, the simple call to wait inside mouseFlick works15:29
Cimiwithout any special code to launcher or dragginarea15:29
mzanettiSaviq: done15:31
cyphermoxsergiusens: didrocks: building hud right now, got some changes to apply to the CMakelists.txt, but it looks promising.15:32
cyphermoxback later, going to grab lunch and run some errands now15:32
didrockscyphermox: \o/ enjoy your lunch :)15:32
dandraderCimi, that won't be reliable. with those waits it will bet *at least* as slow as those waits. If the machine is slower to process the rendering etc it will be even slower and then the resulting speed will be slower than what you want15:33
dandraderCimi, and then to solve that you have to get the time elapsed since your previous mouseMove15:34
dandraderCimi, and do the next mouseMove considering the time elapsed since the last move and your desired speed15:34
Cimidandrader, which works for us because we test slow speeds15:34
Cimidandrader, so if it's slower, even better15:34
Cimithe speed is a minimum speed15:35
Cimiand I don't think we have machines so slow that lose seconds of overhead15:35
dandraderfor this specific case15:35
Cimijenkins is not a 386 :)15:35
dandraderit's worse, it's in a VM15:36
sergiusensSaviq: when you have a chance, people lens is broken in the raring build, do you think you can take a look at it?15:36
Cimiinstead the code with faketime makes the unity code itself less clear15:36
sergiusensSaviq: clarification-> raring && phablet15:36
dandraderCimi, I would rather try to get hold of the time and QAnimationDriver to ensure things happen exactly as we want in the tests15:37
dandraderCimi, to make then really reliable15:37
dandraderinstead of adding waits and hopping for the best15:37
Saviqsergiusens, the images from cdimage are good to test?15:37
dandraderotherwise we can get those familiar situations of "fails on jenkins but works on my machine"15:37
greybackdandrader: Cimi: Daniel is correct on the reliability thing. Firing mouseMoves with puases between gives me varying results. However some rough form of speed control would be useful, as right now all flicks are inhumanly fast15:37
Saviqsergiusens, hum15:38
Cimigreyback, if we add the wait as I did the mouseflick will work as we want, with faketime we have to patch each file that is testing a flick to calculate actions depending on a fake time15:39
Cimigreyback, just like launcher and dragging area and dashbar and future files will need15:39
sergiusensSaviq: mostly functional, yes http://sergiusens.github.io/posts/using-phablet-tools-to-install-raring-image.html15:40
Saviqsergiusens, looks bad, will have a look (or rather try and find someone with more knowledge) tomorrow15:40
greybackCimi: I'm not saying your approach is totally wrong, I'm just pointing out it isn't 100% safe either.15:40
Cimiwe're making the code way less simple just to avoid one line of code? (wait)15:40
Cimigreyback, and I understand15:40
sergiusensSaviq: well I bet it's the scope or something as the home lens is also empty15:40
Cimigreyback, I prefer better and simpler code in unity15:40
dandraderCimi, who doesn't?15:41
greybackCimi: well nobody is going to disagree with that statement15:41
dandraderCimi, but I also like reliable tests15:41
Cimiso why can't we add the wait and remove all those lines of code with fake timers?15:42
dandraderand there are cases where you can't achieve everything and have to make some compromises15:42
Cimidandrader, I don't think there's any chance that tests will start to fail because of a wait15:42
Saviqmhr3, pstolowski anything springs to mind ./glib/gvariant-serialiser.c:1324:g_variant_serialised_n_children: code should not be reached ?15:42
greybackCimi: but I don't want lots of fails due to mis-timings. I've experienced many times that things like this will fail arbitrarily, as another process steals the CPU just long enough to make those wait() calls too long and gestures are then broken15:42
mhr3Saviq, yep, you're seriously screwed :)15:43
pstolowskiSaviq: nope..15:43
Cimigreyback, dandrader I see that. But as we have things in dragging area, launcher etc etc, they work if the mouse movement is very slow. *nothing* can bpossibly break for a long wait15:43
mhr3Saviq, unreffed variant, invalid memory... not something that will be fun15:44
Cimiat the current state there's no test that benefits of this added code15:44
Cimiand I can't see this changing in the future15:45
Cimibut we'll still have this cruft added15:45
CimiI'm happy to use fake timers the day we will need them, at the moment it's just more code for no gain whatsoever15:45
greybackdandrader: Cimi: frankly I like the wait() thing too, but we'd have to police it so it is used with extreme care. I don't see any other good way of doing swipe gestures with qml tests.15:46
greybackdandrader: Cimi: right now I'm trying to use mouseFlick to flick a Flickable in certain ways. Aside from firing the flick() method of the Flickable itself, there's nothing else I can do15:47
Cimigreyback, exactly15:48
dandraderCimi, greyback: I think it might be worth to study how can we get complete control over timing. so that things like gesture and animation speed happens exactly how we expect in the tests regardless of the actual rendering speed of the machine running the tests15:48
Cimigreyback, fake timers will only work in custom components, where we can decide what a mouse event is doing15:48
dandraderCimi, greyback like checking this QAnimationDriver API15:48
Cimigreyback, it won't work on listview where we can't add a custom timer15:49
greybackdandrader: Agreed. But we need something now that's hopefully good enough when used carefully.15:49
Cimithe duration worked for me with waits15:50
Cimiwhat we could do to make it more robust15:50
Cimiis getting the initial time when the flick starts15:50
greybackdandrader: I'd also suspect that QAnimationDriver is only related to Animation{} component and their subclasses. I worry they're not used in things like Flickables15:50
Cimiand instead always waiting maxDurationOfFlick / flickSteps15:50
dandradergreyback, I don't know. that's why said "study" :)15:51
greybackdandrader: yep :)15:51
Cimieach time we check where we are in the steps and use an adaptive wait15:51
greybackCimi: that could help, yes15:51
Cimito guerantee that the flick will last exactly the duration we wanted (or in good approximation), being less precises in the middle15:52
greybackdandrader: what do you think of Cimi's suggestion. Use wait(), but instead of a fixed waiting period we monitor the time and try to calculate the waiting time to compensate for CPU differences/consumption15:53
greybacknot perfection, but it could be safe enough?15:53
cyphermoxno lunch for me yet it seems15:55
cyphermoxdidrocks: it's not quite building yet, but soon :)15:55
cyphermoxslowly fixing the issues15:55
dandradergreyback, yeah, could be15:55
greybackCimi: want to give it a go?15:55
Cimigreyback, I can give it a go, but I think dandrader would be better candidate15:56
Cimigreyback, because we have to remove the fakeTimers he added15:56
Cimiand I don't know how was before!15:56
CimiI can write the adaptive waiting code and put on pastebin15:57
Cimiif that helps15:57
greybackCimi: please write it up, and I'll see if it suits my work15:58
greybackCimi: and if it works for me, I'll throw together a branch removing the fake timers and see what dandrader thinks15:59
Cimiok good!15:59
Cimigreyback, deal :)15:59
greybackCimi: cool, thanks15:59
nic-doffaymzanetti, I'm going to have to hold off that review, found a bug I need to sort out :/16:00
=== dandrader is now known as dandrader|lunch
Cimimzanetti, how do I see what's wrong here? https://code.launchpad.net/~unity-team/unity/phablet.test_IndicatorItem/+merge/15791916:04
mzanettiCimi: I think it was a temporary failure. Just reapproved. lets see if it merges16:21
Cimimzanetti, ok16:21
mzanettiCimi: can you review my tests. Nic doesn't have time any more16:22
mzanettiCimi: that would be the link https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/15812916:22
Cimimzanetti, tomo morning16:23
mzanettiCimi: ok, cool16:23
mzanettiCimi: hey, what about this one? https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/15084716:27
Cimimzanetti, it's outdated16:27
Cimimzanetti, doesn't work16:28
Cimimzanetti, that's why I was chatting before16:28
mzanettitoo bad16:28
Cimigreyback, dandrader|lunch  http://paste.ubuntu.com/5695881/16:29
Cimigreyback, only thing I didn't cover is if finalTime is less than getCurrentTimeMs()16:30
Cimican be done with a Math.max or a clamp16:31
Cimidunno what js does for negative wait16:31
Cimigreyback, you read/there? (me was planning to go to the gym now and work another half an hour later, to avoid peak hour)16:36
greybackCimi: yes message received16:38
Cimigreyback, I didn't test it, cause my branch is broken, but should work16:38
greybackCimi: okay16:39
Cimigreyback, because the last wait is guaranteed to be exactly the remaining time16:39
Cimigreyback, we could move the wait at the end of the for, not sure how will change16:39
Cimiit makes sense to me have it before16:40
CimiI usually click then move the mouse, instead click and move, wait, release16:40
Cimiwhich works for iteration 016:40
Cimiat the price of possibly going after finalTime16:41
greybackCimi: this isn't really what I expected. You're averaging the remaining waits after each iteration. So it's there's one delay, all remaining times are changed, not just the next one16:43
greybackCimi: but go to the gym, we can chat later/tomorrow16:43
Cimigreyback, yeah16:44
Cimigreyback, you prefer to just changing one?16:44
Cimiimagine the average wait is 200ms16:45
greybackCimi: well say there should be a 100 ms delay between each mouseMove. Say one mouseMove delayed actually by 120ms. Then I think the next one should be at 80ms, so all others can be at 100ms again16:45
Cimiand the CPU misses 400ms16:45
Cimiwhat will happen to future steps?16:45
Cimiah ok16:45
Cimigreyback, and if the delay was 400?16:46
greybackthen we add additional logic for that case16:46
greybackprobably just extending the duration to compensate16:46
Cimiyour does 100, 120, 80, 100, 10016:46
greybackbecause we want to maintain the speed16:46
greybackas much as possible16:46
Cimimine 100, 120, 93, 93, 9316:47
greybackthat was my thinking. As it maintains an average speed16:47
Cimimakes sense16:47
Saviqmzanetti, someone stole our coverage graphs!16:47
mzanettiSaviq: yes, I did16:47
mzanettimistake in the automatik jenkins coverage16:48
mzanettithey'll come back soon16:48
Saviqmzanetti, ;)16:48
Cimigreyback, btw exdenting suration doesn't work, because we would like to preserve finalTime16:48
greybackCimi: the API defines the distance and the speed. From that the finalTime is decided internally. Why can't that be changed to suit timing problems?16:49
greybackCimi: when I say API, I mean you supply mouseFlick starting & end points and speed. That's it16:50
Cimigreyback, I'm wondering whether extending will change average speed16:50
Cimiaverage speed is distance / time16:50
greybackCimi: it will.16:50
Cimiwe set speed 10016:50
Cimiif we decide to extend time speed will be reduced no?16:51
greybackCimi: but your case was pretty extreme, so I think something has to be sacrificed to maintain sane behaviour16:51
greybackCimi: mind, dandrader|lunch 's __dateTime stuff is at least very reliable, so that's what we need to compete with.16:52
greybackso I'm interested to see how this goes16:52
cyphermoxdidrocks: it's alive!16:54
cyphermoxhud builds so far, running through tests16:54
didrockscyphermox: phablet or desktop?16:54
didrocksok :-)16:54
cyphermoxI'll re-test desktop as soon as that's done16:54
cyphermoxhad to apply a few changes16:55
didrocksgreat ;)16:56
didrocksnice work cyphermox16:56
cyphermoxwaiting : 11/20 Test #11: test-indicator-source ............   Passed    1.72 sec16:56
cyphermox      Start 12: test-application-list16:56
cyphermoxthe changes I did are specifically to make phablet a build-time switch16:56
=== dandrader|lunch is now known as dandrader
mzanettiSaviq: they're back. and better than ever :D17:02
didrocksfginther: hey, if you have a sec, do you mind deploying that: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/16717:23
fgintherdidrocks, done (not that you are here to notice :-) )17:24
Saviqmzanetti, \o/17:26
=== dandrader is now known as dandrader|afk
Saviqmzanetti, is something still in flux with the coverage jobs?18:08
Saviqmzanetti, https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-armhf-autolanding/173/console18:08
mzanettiSaviq: yeah18:08
mzanettiSaviq: fix is on the way18:08
Saviqmzanetti, thanks18:08
mzanettiSaviq: its the first time I use the new jenkins config so I messed up in 2 places18:08
Saviqbad mzanetti18:08
=== dandrader|afk is now known as dandrader
mzanettidandrader: heh... just read your mail. tapped into the same mistake myself earlier this week18:39
dandradermzanetti, :)18:40
mzanettiSaviq: jenkins is fixed.18:54
* mzanetti is off18:54
Saviqmzanetti, \o/18:54
Saviqmzanetti, take care18:54
mzanettiSaviq: do'h!18:59
mzanettiits not *grrrr*18:59
=== jhodapp is now known as jhodapp|afk
Saviqmzanetti, you really shouldn't do that close to EOD ;)19:04
mzanettiSaviq: so true...19:04
fginthercyphermox, not sure if daily-release is ready for this, but: https://code.launchpad.net/~fginther/cupstream2distro-config/qa-stack-update/+merge/15819719:15
jussiI wonder if this "Jussi" guy has an irc nick... perhaps we can educate people to use it :) (loving all the pings...)19:22
cyphermoxHahaha :-)19:23
cyphermoxfginther looks fine except the unstable branches which should not be necessary. Trunk is for that19:24
fginthercyphermox, do you mean the use of ppa:autopilot/unstable?19:26
cyphermoxAh that's a ppa yeah, never mind me then, I just don't understand that change19:27
mzanettiSaviq: now its really fixed.19:33
Saviqmzanetti, really? ;P19:33
mzanettiSaviq: I hope so :D19:33
Saviqthe green dots at the top look promising indeed19:34
mzanettiSaviq: there is at least a green CI run now and clicking through the artifacts looks good19:34
Saviqbut somehow test count fell down?19:34
mzanettiSaviq: yeah. thats why I've started to click through the artifacts19:34
mzanettibut can't find anything wrong so far19:34
mzanettiSaviq: hmm... but the fact that coverage is still up indicates something indeed19:35
Saviqmzanetti, http://s-jenkins:8080/job/unity-phablet-autolanding/176/testReport/19:35
Saviqvs. http://s-jenkins:8080/job/unity-phablet-autolanding/166/testReport/19:36
Saviqautopilot tests didn't get in?19:36
mzanettiSaviq: yep19:43
mzanettiSaviq: the file is in the artifacts though19:43
=== naee is now known as eean
cyphermoxsergiusens: fginther: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/hud-stack/+merge/15809822:04
cyphermoxupdated the merge for the reviews you contributed.22:04
fginthercyphermox, thanks, approved22:10
=== jhodapp|afk is now known as jhodapp
=== salem_ is now known as _salem
george_eQuick question - I notice that when I begin dragging something within an application, the Unity launcher automatically reveals itself. Can someone please point me to the relevant section of code for this?23:29
george_eI've looked through launcher.h/.cpp and wasn't able to find anything.23:29
bschaefergeorge_e, hmm well theres a few things that happens for that ... there is an Xdndmanager which gets a signal from Nux saying something has started to drag23:30
bschaeferand Xdndmanager calls Launcher::DndStart (i think)23:30
george_eAh, okay.23:30
bschaefergeorge_e, soo I would look at: void Launcher::DndStarted(std::string const& data)23:30
bschaeferas thats what Xdnd manager calls, which should move the launcher out of auto hide if its hidden23:31
george_eOkay, I've got that up here: http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/launcher/Launcher.cpp#L277723:31
george_eSo I should be looking through the source code for Nux then?23:32
bschaefergeorge_e, well what are you looking for?23:32
bschaefergeorge_e, or rather whats your end goal?23:32
george_eI'd like to implement something similar in a Qt app.23:32
george_eI'd like to be able to execute code when the user starts dragging something.23:33
bschaefergeorge_e, ooo, hmm yeah you'll have to get it through the X event loop23:33
george_eOh, okay.23:33
* bschaefer thinks...23:33
george_eWell, thanks for pointing me in the right direction.23:33
bschaeferits been a while...though you'll have to look at lp:nux23:33
bschaeferunder nux/NuxGraphics/GraphicsDisplayX11.cpp23:33
bschaefergeorge_e, possibly under:   void GraphicsDisplay::HandleDndDragSourceEvent(XEvent xevent)23:34
george_eOkay, I'll take a peek at that.23:35
bschaefergeorge_e, but its been a while since i've dug through the DND event handling in nux..23:35
bschaefernote that file is huge and a bit hard to read :(23:35
* george_e gasps at the size of the file :P23:35
bschaeferhaha...yeeah its never fun to dig through that one....23:36
bschaefergeorge_e, err..umm you are trying to get stuff from your Qt app to be able to drag it onto the launcher?23:36
bschaeferor are you trying to detect DND stuff for your Qt app?23:37
george_eNo, I want users to be able to start dragging a file, for example, and have my app immediately jump to the front to act as a drop target.23:37
bschaefererr nm, as i re-read your comment above :)23:37
bschaeferpretty much there are these things called mimes that apps have to set for files etc, and when a Dnd is detected you have to pull those mimes data out and that will tell you info about whats being dragged23:38
bschaefer  std::list<char *> GraphicsDisplay::GetDndMimeTypes()23:38
bschaefergeorge_e, some more info: http://www.newplanetsoftware.com/xdnd/23:39
bschaeferhope that helps!23:39
=== slangase` is now known as slangasek

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!