| Akiva-Mobile | I am developing a syntax highlighter for the terminal using python code, and I need some help answering one question | 01:36 |
|---|---|---|
| Akiva-Mobile | Unity is going to be using qt5 ? | 01:36 |
| Akiva-Mobile | 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 |
| Akiva-Mobile | compatible with* | 01:37 |
| Akiva-Mobile | and further; will this be possible with python, seeing as no qt5 libraries exist for it yet? | 01:38 |
| kgunn | Akiva-Mobile: i'd recommend to ping this channel again mid day for europe time for the best response | 02:27 |
| kgunn | Akiva-Mobile: but, if you're starting from scratch, I'd recommend looking into qt/qml | 02:27 |
| Akiva-Mobile | kgunn: Dawww | 02:27 |
| kgunn | Akiva-Mobile: i don't see a reason that would preclude use of python | 02:27 |
| kgunn | Akiva-Mobile: but i'm not an expert either.... | 02:28 |
| Akiva-Mobile | python bindings for qt5 do not exist yet | 02:28 |
| kgunn | Akiva-Mobile: ah | 02:28 |
| kgunn | Akiva-Mobile: ...surprising | 02:29 |
| kgunn | tho | 02:29 |
| === jussi01 is now known as jussi | ||
| === jono is now known as Guest75135 | ||
| mzanetti | good morning | 07:36 |
| tsdgeos | yay! down to 27 merges :D | 07:43 |
| mzanetti | \o/ | 07:45 |
| Mirv | 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:51 |
| didrocks | 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 |
| Mirv | didrocks: ok | 07:52 |
| didrocks | Mirv: do you know more about the documentation update for the sdk? | 07:52 |
| tsdgeos | Saviq: man, i was just doing https://code.launchpad.net/~saviq/unity/phablet-mods.fix-resultiterator-warnings :D | 07:53 |
| tsdgeos | you win by 10 minutes :D | 07:54 |
| Saviq | tsdgeos, :D | 07:54 |
| Mirv | didrocks: it's been in the discussions, but I don't know the latest status | 07:54 |
| Saviq | tsdgeos, https://code.launchpad.net/~saviq/unity/phablet-mods.fix-resultiterator-warnings/+merge/158006 | 07:54 |
| didrocks | 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:54 |
| Mirv | didrocks: ok, will do | 07:55 |
| tsdgeos | Saviq: btw the const should have been moved to the end of the function declaration in unity | 07:55 |
| tsdgeos | but that's another story | 07:55 |
| didrocks | thanks Mirv ;) | 07:55 |
| Saviq | tsdgeos, they approved ;D | 07:55 |
| tsdgeos | Saviq: you createing a merge request for build_unity too? | 07:56 |
| Saviq | tsdgeos, yes, just checking that it works | 07:56 |
| tsdgeos | oka | 07:57 |
| Saviq | tsdgeos, /plugins/Unity/categories.cpp:0: Note: No relevant classes found. No output generated. | 07:57 |
| Saviq | that's new? | 07:57 |
| tsdgeos | it might | 07:57 |
| tsdgeos | i saw it today too and stricked me as "did we have this before?" | 07:57 |
| tsdgeos | probably new | 07:58 |
| tsdgeos | why are we passing the cpp to moc? | 07:58 |
| tsdgeos | well, one can define classes in the cpp, that's right, but not that common | 07:59 |
| Saviq | tsdgeos, ah I know | 07:59 |
| Saviq | tsdgeos, the CategoryFilter class was moved out of there | 07:59 |
| Saviq | tsdgeos, need to drop the #include moc | 07:59 |
| tsdgeos | right | 07:59 |
| Saviq | or tweak it actually | 07:59 |
| Saviq | so that automoc only looks at the header | 07:59 |
| Saviq | and not the cpp | 07:59 |
| tsdgeos | dropping the #include is "the right thing" if we're automoc'ing i think | 08:00 |
| Saviq | tsdgeos, it has to be there, just #include "moc_categories.cpp", not "categories.moc", no? | 08:02 |
| Saviq | 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 |
| Saviq | 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:03 |
| tsdgeos | Saviq: where's that quote from? | 08:04 |
| Saviq | tsdgeos, first stuff in google about automoc | 08:04 |
| Saviq | tsdgeos, http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc | 08:04 |
| tsdgeos | ok | 08:04 |
| Saviq | tsdgeos, you can't contradict blogs.kde.org, you can't | 08:04 |
| tsdgeos | i'd say that's old :D | 08:04 |
| tsdgeos | Saviq: just remove the both includes in categories.cpp and categoryfilter.cpp | 08:05 |
| tsdgeos | and see that it still works | 08:05 |
| Saviq | is there a new The Right Way ™? | 08:05 |
| tsdgeos | afaik in newer automocs you don't really "need" to include the moc | 08:05 |
| tsdgeos | it'll be done for you | 08:05 |
| tsdgeos | since basically including the moc is just a way to get the moc compiled | 08:05 |
| Saviq | right, cool | 08:06 |
| tsdgeos | and that's done by builddir/plugins/Unity/Unity-qml_automoc.cpp | 08:06 |
| mzanetti | yeah... I just converted xbmcremote from qmake to cmake and did not have to include those | 08:06 |
| tsdgeos | so i'd just remove them | 08:06 |
| tsdgeos | but won't complain if you prefer to move them to #include "moc_categories.cpp" | 08:06 |
| Saviq | tsdgeos, or remove all of them altogether | 08:07 |
| Saviq | tsdgeos, can you? | 08:07 |
| tsdgeos | sure | 08:07 |
| * tsdgeos does | 08:07 | |
| mzanetti | Saviq: should I set this to DONE? | 08:07 |
| mzanetti | work out a way to measure QML test coverage: TODO | 08:07 |
| mzanetti | or are we not satisfied yet? | 08:07 |
| Saviq | mzanetti, yeah, and add another one to "improve ways to measure QML test coverage" at the bottom ;) | 08:08 |
| mzanetti | Saviq: there is already another one | 08:08 |
| Saviq | mzanetti, ok then | 08:08 |
| mzanetti | integrate with Qt's Javascript engine to enable code coverage metrics for QML/JS code (similar to JSCover's approach): TODO | 08:08 |
| mzanetti | 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 |
| mzanetti | Saviq: whats your opinion? | 08:12 |
| Saviq | 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 |
| Saviq | mzanetti, but not the Dash{Apps,Music} etc. | 08:14 |
| Saviq | those will go away | 08:14 |
| * Saviq looks at the list again | 08:14 | |
| Saviq | mzanetti, so Dash/DashContent.qml should be relatively testable | 08:15 |
| mzanetti | Saviq: Dash/DashContent.qml. Thats one of our memory eaters in combination with LVWPH. I would expect that to change | 08:15 |
| Saviq | mzanetti, hmm internally, yes | 08:16 |
| mzanetti | 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 |
| Saviq | mzanetti, but externally not so much | 08:16 |
| dednick | eh. running qmluitests just killed my system... | 08:18 |
| tsdgeos | Saviq: mzanetti: https://code.launchpad.net/~aacid/unity/remove_unneeded_moc_includes/+merge/158012 | 08:19 |
| tsdgeos | dednick: lol | 08:19 |
| Saviq | dednick, do we have qmluitests for the power indicator ;D | 08:19 |
| tsdgeos | dednick: just commented in https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicators/+merge/157678 | 08:19 |
| dednick | lol | 08:19 |
| mzanetti | dednick: hey! I just posted a comment in the IndicatorItem tests MP | 08:20 |
| Saviq | tsdgeos, https://code.launchpad.net/~saviq/unity/phablet.bump-unity-revision/+merge/158011 | 08:20 |
| mzanetti | dednick: with that change Cimi broke the IndicatorRow but your tests are still passing | 08:20 |
| mzanetti | dednick: https://code.launchpad.net/~unity-team/unity/phablet.test_IndicatorItem/+merge/157919 | 08:21 |
| Saviq | tsdgeos, although we might wait for the merge to lp:unity/phablet-mods | 08:21 |
| dednick | mzanetti: thanks | 08:21 |
| tsdgeos | Saviq: better :D | 08:21 |
| Saviq | tsdgeos, it'd only really bite if people went and ./build_unity ;) | 08:21 |
| Saviq | who does that! | 08:22 |
| tsdgeos | not me :D | 08:22 |
| tsdgeos | Saviq: phablet-mods *does* autoland, right? | 08:22 |
| Saviq | tsdgeos, http://s-jenkins:8080/job/unity-phablet-mods-autolanding/11/ | 08:22 |
| tsdgeos | oka | 08:22 |
| Saviq | tsdgeos, you can see by "PS Jenkins: pending" review | 08:22 |
| tsdgeos | right | 08:23 |
| Saviq | tsdgeos, that jenkins is set up to do stuff | 08:23 |
| Saviq | 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:23 |
| mzanetti | Saviq: depends on what it is | 08:24 |
| * mzanetti reads | 08:24 | |
| Saviq | mzanetti, what do you reda? | 08:24 |
| Saviq | *read | 08:24 |
| mzanetti | I thought it would get clear from your discussion with tsdgeos | 08:24 |
| Saviq | mzanetti, we thought it might make sense to queue armhf builds _after_ i386 passed | 08:24 |
| mzanetti | Saviq: reason? | 08:25 |
| Saviq | mzanetti, time | 08:25 |
| mzanetti | wouldn't that increase build time? | 08:25 |
| Saviq | mzanetti, it would decrease turnaround time | 08:25 |
| dednick | tsdgeos: replied to your comment | 08:25 |
| mzanetti | Saviq: only on failures | 08:25 |
| Saviq | mzanetti, indeed | 08:25 |
| mzanetti | Saviq: good runs would take longer | 08:25 |
| Saviq | mzanetti, right so it would be fine for us, but for mir, not so much | 08:26 |
| Saviq | mzanetti, could we cancel the jobs maybe? | 08:26 |
| Saviq | mzanetti, i.e. if i386 fails, cancel the other jobs? | 08:26 |
| mzanetti | 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 |
| tsdgeos | dednick: so the icons weren't "working" before, no? | 08:27 |
| mzanetti | Saviq: I think what you want is to post failures immediately | 08:27 |
| Saviq | mzanetti, yeah, that was my next proposla | 08:27 |
| mzanetti | Saviq: which _could_ lead to spam im rare cases | 08:27 |
| mzanetti | Saviq: we should only post failures or one summary on good runs | 08:28 |
| Saviq | mzanetti, yeah, but failures you could post straight away | 08:28 |
| mzanetti | Saviq: ack | 08:28 |
| Saviq | I think | 08:28 |
| mzanetti | lets go for that | 08:28 |
| mzanetti | Saviq: however, I think that's really mmrazik's domain | 08:28 |
| dednick | tsdgeos: this is just for the fake PluginModel. Previously there were no tests which exposed the issue (on the overview menu). | 08:28 |
| Saviq | mzanetti, yeah, just fishing for an opinion here | 08:28 |
| mzanetti | Saviq: all the jenkins LP integration is his code. | 08:29 |
| mzanetti | Saviq: but in general, that would be something I would think adds value without impeding other things | 08:29 |
| Saviq | mzanetti, yup, will file bug | 08:29 |
| Saviq | mzanetti, another thing | 08:29 |
| tsdgeos | dednick: ok | 08:29 |
| Saviq | mzanetti, test runs are not atomic | 08:29 |
| Saviq | mzanetti, i.e. http://s-jenkins:8080/job/unity-phablet-ci/386/ | 08:29 |
| Saviq | mzanetti, passed on the builders | 08:30 |
| Saviq | mzanetti, but conflicted on the VM | 08:30 |
| Saviq | mzanetti, because stuff merged in trunk between the builders run | 08:30 |
| Saviq | and the ui test run | 08:30 |
| mzanetti | Saviq: hmmm I see | 08:30 |
| Saviq | mzanetti, do autopilot tests build its own version, too? | 08:31 |
| mzanetti | Saviq: yes | 08:31 |
| Saviq | mzanetti, so maybe we should think of a way of passing the results from the build runs to the testers | 08:31 |
| Saviq | by packaging the tests, too | 08:31 |
| mzanetti | Saviq: would double round trip time | 08:31 |
| Saviq | mzanetti, how so? | 08:32 |
| mzanetti | 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 |
| Saviq | yeah that's what I thought, too | 08:32 |
| Saviq | mzanetti, maybe a common branch between the builders and the test machines? | 08:33 |
| Cimi | mzanetti, small question, why you added tag to the data function? https://code.launchpad.net/~mzanetti/unity/phablet-test-sidestage/+merge/157921 | 08:33 |
| Saviq | mzanetti, 'cause I could even imagine the tests to pass on i386 and fail on armhf | 08:33 |
| Saviq | if armhf were queued and some conflicting merge happened during that time | 08:33 |
| mzanetti | Cimi: tags are printed in the output when running tests | 08:33 |
| Cimi | mzanetti, ah useful, thanks for the tip! | 08:34 |
| mzanetti | Saviq: yes. can happen right now | 08:34 |
| mzanetti | Saviq: I'm just thinking if that actually causes a real problem | 08:34 |
| Saviq | mzanetti, right, if there's a conflicting merge you need to merge anyway | 08:35 |
| mzanetti | Saviq: ok. I _could_ kill an autolanding job in very rare cases | 08:35 |
| tsdgeos | dednick: can you quick fix avtive -> active in that branch? | 08:35 |
| mzanetti | Saviq: but in ci its actually a good thing. so you realize it right away and not only in autolanding | 08:35 |
| dednick | tsdgeos: sure | 08:35 |
| Saviq | mzanetti, it might be just that we need to be aware of that | 08:36 |
| Saviq | mzanetti, otherwise people get scared by what happened | 08:36 |
| Saviq | +can | 08:36 |
| Saviq | that builds worked but tests conflicted | 08:36 |
| mzanetti | Saviq: yeah... | 08:36 |
| mzanetti | Saviq: otoh I usually expect people to enable their brain when developing | 08:36 |
| mzanetti | its not that is a unsovable riddle | 08:37 |
| Saviq | mzanetti, tyrant | 08:37 |
| mzanetti | haha | 08:37 |
| Saviq | mzanetti, ok, so whether that's a feature or a bug is debatable, agreed | 08:37 |
| Saviq | mzanetti, last thing http://s-jenkins:8080/job/unity-phablet-autolanding/154/ | 08:37 |
| Saviq | mzanetti, autolanding only noticed after 25 mins that there's a conflict | 08:37 |
| dednick | tsdgeos: done | 08:37 |
| tsdgeos | dednick: also do you really need the PluginModel.qml in the bzrignore? it seems it just ends up in the builddir here | 08:38 |
| mzanetti | Saviq: because it was queued? | 08:38 |
| dednick | tsdgeos: ah right. no, forgot i added the builddir after. | 08:38 |
| Saviq | mzanetti, I don't think so | 08:38 |
| Saviq | mzanetti, it was running for 25 mins | 08:38 |
| mzanetti | Saviq: well, it sais started 9 mins ago :D | 08:39 |
| tsdgeos | dednick: ok, plz kill it! | 08:39 |
| Saviq | mzanetti, hmm wrong job? | 08:39 |
| mzanetti | Saviq: oh... messed up... 9hrs that is | 08:39 |
| Saviq | mzanetti, 9hrs | 08:39 |
| mzanetti | Saviq: yeah... let me check | 08:39 |
| Saviq | and took 26mins | 08:39 |
| Saviq | not sure if queue is included in that time | 08:39 |
| dednick | tsdgeos: done | 08:40 |
| mzanetti | Saviq: ok here's what happened: | 08:40 |
| tsdgeos | dednick: tx | 08:40 |
| mzanetti | Saviq: ci job started, triggered all 5 downstream jobs | 08:40 |
| mzanetti | Saviq: most of them immediately failed, some of them had to wait in the queue | 08:40 |
| Saviq | mzanetti, right, so the same issue as above | 08:41 |
| mzanetti | Saviq: the overall result was only posted once all failed | 08:41 |
| mzanetti | Saviq: yep. should be covered with your bug report | 08:41 |
| mzanetti | Saviq: thing is, the SDK guys copied my qmluitests job now and are with us on the same VM's | 08:42 |
| mzanetti | Saviq: if Mir does a commit, one of the 2 VM's is blocked for 1.5 hours | 08:42 |
| mzanetti | 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 |
| mzanetti | Saviq: and now SDK comes in too | 08:43 |
| Saviq | mzanetti, yeah, saw that | 08:43 |
| tsdgeos | dednick: i think i found a behaviour regression, writing it on the MR | 08:44 |
| mzanetti | Saviq: anyways, we have building new VMs in the queue... Now that the server has more resources | 08:44 |
| mzanetti | Saviq: also, switching to raring will decrease qmluitests time by around 5 mins | 08:45 |
| Saviq | mzanetti, nice | 08:45 |
| mzanetti | so there are improvments ahead in that area. just not comming in today | 08:46 |
| tsdgeos | dednick: added https://code.launchpad.net/~nick-dedekind/unity/phablet-test-indicators/+merge/157678 | 08:47 |
| dednick | tsdgeos: thanks, i'll take a look | 08:48 |
| mzanetti | Saviq: I'll prepopulate the quantal vm's with Qt5 now. that should give us the raring speedup already now | 08:49 |
| Saviq | mzanetti, yeah, sounds good | 08:49 |
| mzanetti | (the problem is that installing Qt5 needs to replace also Qt4 which is what is killing those 5 mins) | 08:49 |
| Cimi | Saviq, mzanetti what shall I do here? https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/157859 | 08:53 |
| mzanetti | Cimi: fix the other 2 comments I added and leave the precision as is | 08:53 |
| mzanetti | Cimi: after we collected the requirements as Saviq said, we'll fix all clocks we have | 08:54 |
| Saviq | mzanetti, Cimi yup | 08:57 |
| Saviq | 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:57 |
| mzanetti | Saviq: more precise please | 08:58 |
| mzanetti | you mean the mediumtests and qmluitests starting at the same time as the builders? | 08:58 |
| mzanetti | Saviq: oh yeah... autolanding and ci generated out of the same template | 08:59 |
| mzanetti | Saviq: right now there are small manual changes I made because the template didn't support collecting test results of multiple downstream jobs. | 08:59 |
| mzanetti | 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:00 |
| mzanetti | Saviq: but yeah, all downstream jobs start simultaneously. | 09:01 |
| Saviq | mzanetti, is that the case for ci, too? | 09:02 |
| mzanetti | Saviq: yes | 09:02 |
| Saviq | mzanetti, ah I thought it was on purpose that they waited | 09:02 |
| Saviq | mzanetti, qml and medium were only ran after the builders completed, right? | 09:03 |
| mzanetti | Saviq: no... usually, when the VM queue is empty, the qmluitests are done even before the builders are | 09:03 |
| mzanetti | Saviq: no... I think you got confused by the generic-mediumtests job | 09:03 |
| mzanetti | Saviq: generic-mediumtests again has 2 downstream jobs: mediumtests-builder and mediumtests-runner | 09:03 |
| mzanetti | Saviq: those 2 are queued of course because the runner tests the build from the builder | 09:04 |
| Saviq | mzanetti, riight, so it's only really queuing that can expose that "trunk changed between downstream jobs" issue | 09:04 |
| mzanetti | 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:05 |
| mzanetti | Saviq: but yeah. the queuing is the one that hit you | 09:06 |
| Saviq | mzanetti, https://bugs.launchpad.net/ps-qa-tools/+bug/1167210 | 09:06 |
| ubot5 | Error: launchpad bug 1167210 not found | 09:06 |
| Saviq | sorry ubot5 | 09:07 |
| mzanetti | hehe | 09:07 |
| mzanetti | Saviq: added my thoughts | 09:18 |
| Saviq | mzanetti, cheers | 09:18 |
| Saviq | mzanetti, another issue - https://code.launchpad.net/~jpakkane/unity/includecheck/+merge/158005 | 09:20 |
| Saviq | mzanetti, it has a prerequisite, but doesn't actually include the prerequisite | 09:21 |
| Saviq | mzanetti, which means it fails, because it just merges the branch on top of trunk | 09:21 |
| Saviq | mzanetti, and until the other one lands that will fail | 09:21 |
| Saviq | mzanetti, do you think we could have CI premerge prerequisites first? | 09:22 |
| Saviq | or why can't we | 09:22 |
| mzanetti | Saviq: good one | 09:22 |
| mzanetti | Saviq: let me think... I guess the limitating factor here is the pbuilder itself... | 09:22 |
| Saviq | limiwhat? | 09:23 |
| Saviq | ;) | 09:23 |
| mzanetti | Saviq: it takes an argument for proposed branch and target branch | 09:23 |
| Saviq | mzanetti, pbuilder itself? | 09:23 |
| mzanetti | Saviq: pbuilderjenkins that is... I think a modified version of the regular pbuilder | 09:24 |
| Saviq | mzanetti, so it probably gets it as bzr+ssh://, no knowledge about LP, then | 09:24 |
| mzanetti | Saviq: yep | 09:24 |
| * Saviq files a bug anyway | 09:24 | |
| mzanetti | Saviq: those are the parameters we use: http://s-jenkins:8080/job/unity-phablet-ci/362/rebuild/? | 09:24 |
| Saviq | mzanetti, yeah I know | 09:25 |
| mzanetti | 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 |
| Saviq | mzanetti, so the job could prepare a list of premerges | 09:25 |
| Saviq | mzanetti, and pbuilder would merge them in order | 09:25 |
| Saviq | maybe limiting to 5 or so | 09:25 |
| Saviq | and just fail straight away if there's more | 09:25 |
| mzanetti | Saviq: yeah... that would also fix the issue with different codebases for different builders | 09:25 |
| mzanetti | Saviq: or kill the feature of having the most recent possible codebase - depending how you look at it | 09:26 |
| Saviq | mzanetti, how would that fix it? | 09:26 |
| Saviq | mzanetti, no no | 09:27 |
| mzanetti | 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 |
| Saviq | mzanetti, i meant trunk + prereq + prereq + prereq + branch | 09:27 |
| didrocks | mzanetti: pbuilder doesn't know about branch FYI | 09:27 |
| didrocks | mzanetti: it only knows about source packages | 09:27 |
| Saviq | didrocks, pbuilderjenkins does, apparently | 09:27 |
| mzanetti | didrocks: yeah... thats what I meant... | 09:27 |
| didrocks | pbuilderjenkins is AFAIK just a wrapper starting pbuilder :) | 09:27 |
| didrocks | like handling bzr | 09:27 |
| Saviq | didrocks, yeah | 09:27 |
| didrocks | and creating the source package | 09:27 |
| Saviq | didrocks, so yeah, still, pbuilderjenkins needs to start caring about prerequisites ;) | 09:28 |
| didrocks | yeah, this is fortunately something we are upstream for ;) | 09:28 |
| mzanetti | 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:30 |
| Saviq | mzanetti, yup | 09:31 |
| Saviq | mzanetti, https://bugs.launchpad.net/ps-qa-tools/+bug/1167240 (sorry ubot5) | 09:36 |
| ubot5 | Error: launchpad bug 1167240 not found | 09:36 |
| Cimi | mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/157859 | 09:39 |
| Cimi | mzanetti, checking if the time is updated properly is a bit difficult | 09:41 |
| Cimi | because setting a date breaks the binding (1) and we need a minute to test if it updated (2) | 09:41 |
| Saviq | tsdgeos, https://codereview.qt-project.org/#change,53235 :P | 09:42 |
| tsdgeos | Saviq: working on it, Alan agreed with Andrew that removing the applyPendingChanges from count is probably the best way | 09:43 |
| tsdgeos | and i'm going to do that and add some tests | 09:43 |
| mzanetti | Saviq: nothing to add to that bug report. | 09:44 |
| Saviq | mzanetti, just mark it as affecting you ;) | 09:44 |
| Saviq | tsdgeos, the ":P" is essential in what I wrote | 09:44 |
| tsdgeos | i'm a bit weirded because some of the tests that are supposed to work are failing here | 09:44 |
| mzanetti | Saviq: however, the correct component would be jenkins-launchpad-plugin | 09:44 |
| mzanetti | Saviq: at least for the first one. but thats a proprietary one which jenkins-launchpad-plugin doesn't accept :D | 09:45 |
| mzanetti | already confirmed both, yes | 09:45 |
| Saviq | mzanetti, cheers | 09:45 |
| mzanetti | Cimi: I though about just checking if the time changes automatically (i.e. label.text != cachedTextFromBefore) | 09:48 |
| mzanetti | 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 |
| Saviq | yikes jenkins is failing today | 09:49 |
| mzanetti | Saviq: how? | 09:49 |
| Saviq | mzanetti, IOErrors everywhere | 09:50 |
| mzanetti | noooooo | 09:50 |
| mzanetti | http://nooooooooooooooo.com/ | 09:50 |
| Cimi | mzanetti, the time updates every minute | 09:51 |
| Cimi | mzanetti, I can sleep for 60 seconds if you want :) | 09:51 |
| Saviq | mzanetti, ps-panda-4 dying? | 09:51 |
| mzanetti | Cimi: you could set timer.interval = 1 for the test, no? | 09:51 |
| * mzanetti checks pandas | 09:51 | |
| Cimi | mzanetti, I need to create another property then | 09:51 |
| mzanetti | Cimi: oh right... missed that... I wouldn't export the timerRunning property | 09:52 |
| Saviq | mzanetti, 4 failures with IOException on ps-panda-4 within the last hour or so | 09:52 |
| Cimi | mzanetti, I'll add __ | 09:52 |
| mzanetti | Cimi: but rather use findChild() on the timer | 09:52 |
| Cimi | mzanetti, doesn't work | 09:52 |
| Cimi | mzanetti, it's not a child | 09:52 |
| mzanetti | interesting... does that only work for visible childs? | 09:53 |
| mzanetti | no... cant belive that... | 09:53 |
| Cimi | maybe, didn't try | 09:53 |
| Cimi | I tried with findChild and wasn't working | 09:53 |
| mzanetti | Saviq: I disabled panda-4 | 09:53 |
| dednick | tsdgeos: fixed the regression and added a test | 09:55 |
| tsdgeos | good stuff :-) | 09:55 |
| * tsdgeos checks | 09:55 | |
| Saviq | I love it when a plan comes together (and the general flurry of activity) | 09:59 |
| tsdgeos | dednick: that works, but i wonder why are we needing that extra code? | 10:02 |
| dednick | tsdgeos: if we go from hint -> locked without hitting reveal the menu's dont show. | 10:02 |
| dednick | it'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 | ||
| tsdgeos | dednick: i see, so you found a bug while testing that introduced the other bug, yes? | 10:05 |
| === tvoss is now known as tvoss|sick | ||
| dednick | tsdgeos: yes | 10:05 |
| tsdgeos | ok :-) | 10:05 |
| tsdgeos | all clear now | 10:05 |
| dednick | :) | 10:05 |
| tsdgeos | arg, replacing unity with kwin and then with unity again makes Alt+f4 not work | 10:10 |
| * tsdgeos logs out and in | 10:10 | |
| Cimi | mzanetti, dunno how to test it | 10:13 |
| Cimi | mzanetti, when the time updates, date changes | 10:13 |
| Cimi | but not necessarely the labels, because the labels are each minute | 10:14 |
| Cimi | I can check if the date changes | 10:14 |
| mzanetti | Cimi: let me try | 10:15 |
| mzanetti | Cimi: can I push to your branch? | 10:25 |
| Cimi | mzanetti, obviously | 10:25 |
| Cimi | mzanetti, I put unity-team for collaboration in all my branches | 10:25 |
| mzanetti | Cimi: I found another issue: Qt.formatDate() creates a different string here because I use german date format in my system | 10:29 |
| mzanetti | Cimi: I've added one test function that takes care of that too. | 10:30 |
| mzanetti | Cimi: you just need to update the first test function to do the same | 10:30 |
| mzanetti | Cimi: pushed | 10:30 |
| mzanetti | Cimi: also feel free to rename my test function | 10:31 |
| Cimi | mzanetti, I don't understand your wait(0) | 10:31 |
| Cimi | especially the first one | 10:31 |
| Cimi | you test the time is not running? | 10:32 |
| Cimi | *timer | 10:32 |
| mzanetti | Cimi: right... need to change the timer interval... one sec | 10:32 |
| mzanetti | Cimi: you're right... Timers cannot be findChild()ed | 10:36 |
| mzanetti | sucks | 10:36 |
| mzanetti | Cimi: in that case we probably want to add a property alias interval: timer.interval | 10:36 |
| Cimi | mzanetti, it exist | 10:36 |
| Cimi | mzanetti, __timerInterval | 10:36 |
| Cimi | mzanetti, I added it | 10:36 |
| smspillaz | hmm, thats nice | 10:37 |
| Cimi | ciao sam :) | 10:37 |
| smspillaz | the arm builders seem to be running out of memory | 10:37 |
| smspillaz | Cimi: howdy | 10:37 |
| mzanetti | Cimi: ok... just set the interval to 1 and change the first wait to wait(5) or so | 10:37 |
| nic-doffay | the transform origins for a QML item are by default the centre, correct? | 10:37 |
| mzanetti | Cimi: leave the second wait to 0 though | 10:37 |
| mzanetti | nic-doffay: not exaclty sure why you mean, but I would assume 0, 0 | 10:38 |
| mzanetti | nic-doffay: but it should be easy to find out, no? | 10:38 |
| nic-doffay | It's not mentioned in the documentation. | 10:38 |
| nic-doffay | I'll do some experimentation. | 10:38 |
| nic-doffay | The answer is yes. | 10:39 |
| Cimi | mzanetti, we could add if current time is 11:13 then don't test the last | 10:44 |
| Cimi | no? | 10:44 |
| Cimi | looks ugly both ways :D | 10:45 |
| * Cimi let's not add code | 10:45 | |
| mzanetti | Cimi: maybe just a small (if time == "11:13") wait(60000) | 10:46 |
| Cimi | indeed | 10:46 |
| Cimi | mzanetti, pushed | 10:52 |
| mzanetti | Cimi: looks good | 10:54 |
| mzanetti | Cimi: I would have kept the test_customDate() though | 10:55 |
| Cimi | mzanetti, I will add it | 10:56 |
| mzanetti | because that one passing a prerequisite of the new one to be useful | 10:56 |
| mzanetti | Cimi: if the test_customDate() would fail, the test_dateUpdate() is useless | 10:56 |
| Cimi | mzanetti, I'll merge the two | 10:56 |
| Cimi | mzanetti, put the customdate compare after the first three lines of dateUpdate() | 10:57 |
| mzanetti | I'd make it different cases. in case something fails its easier to debug | 10:57 |
| mzanetti | Cimi: ^ | 10:57 |
| Cimi | nope | 10:57 |
| Cimi | ues | 10:57 |
| Cimi | ok | 10:57 |
| Cimi | mzanetti, remember, debugging sucks, testing rocks | 10:58 |
| mzanetti | anyways... just add it back somehow and I'll approve | 10:58 |
| mzanetti | hehe | 10:58 |
| mzanetti | The guy setting up jenkins at Nokia had that written in huge letters on his office door :D | 10:58 |
| Cimi | pushed btw | 11:01 |
| === MacSlow is now known as MacSlow|lunch | ||
| mzanetti | Cimi: the curstomDate() fails here. you need to use the dateString/timeString vars like in the other tests | 11:03 |
| mzanetti | Cimi: rest looks good | 11:03 |
| Cimi | why would fail? | 11:03 |
| Cimi | mzanetti, dateLabel has Qt.formatDate(__date, Qt.DefaultLocaleLongDate) | 11:05 |
| mzanetti | Cimi: | 11:06 |
| mzanetti | Actual (): Monday, October 13, 1975 | 11:06 |
| mzanetti | Expected (): Monday, 13 October 1975 | 11:06 |
| Cimi | mzanetti, tell me now | 11:10 |
| mzanetti | ? | 11:10 |
| tsdgeos | :D | 11:15 |
| tsdgeos | commas everywhere! | 11:16 |
| === pete-woods is now known as pete-woods|afk | ||
| cyphermox_ | Mirv: hey | 12: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 powerpc | 12:04 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | cyphermox_, I think kenvandine said v8 is not supported on powerpc | 12:09 |
| cyphermox_ | seb128: ah, thanks | 12:09 |
| seb128 | that's an issue we should discuss on #ubuntu-devel if that hasn't been yet | 12:10 |
| seb128 | it doesn't make sense to go and modify the arch list for every single qt5 user | 12:10 |
| didrocks | kill powerpc ;) | 12:24 |
| * didrocks goes back to take a shower | 12:24 | |
| didrocks | mhr3: pstolowski: you should welcome finally the first round of the 100scopes features in the certified ppa :) | 12:29 |
| pstolowski | yay! :) | 12:29 |
| mhr3 | wohooo! | 12:30 |
| mhr3 | pstolowski, i see you took control of your hands this time ;) | 12:31 |
| pstolowski | :D | 12:31 |
| didrocks | ok, indicators tests finally passed as well | 12:33 |
| didrocks | cyphermox_: ^ | 12:33 |
| cyphermox_ | yay | 12:34 |
| === cyphermox_ is now known as cyphermox | ||
| === _salem is now known as salem_ | ||
| Mirv | cyphermox: yes, the qtjsbackend dependency | 12:36 |
| cyphermox | didrocks: did you mean indicators-raring? everything went through fine it seems | 12:43 |
| didrocks | cyphermox: well, I had to relaunch is, there was some UTAH/installation issue this night | 12:44 |
| cyphermox | yeah, figures | 12:44 |
| === hggdh_ is now known as hggdh | ||
| cyphermox | just sayin' though | 12:44 |
| didrocks | so yeah "everything went through fine" after didrocks looked at it :p | 12:44 |
| cyphermox | let me handle "some of it" every once in a while :P | 12:44 |
| didrocks | cyphermox: I wonder seriously if we shouldn't move the schedule for dailies | 12:44 |
| didrocks | like later, closer to your time of day | 12:45 |
| cyphermox | nah, keep it as is | 12:45 |
| cyphermox | or pull it *back* | 12:45 |
| cyphermox | that way I can easily check on it at EOD | 12:45 |
| didrocks | back? | 12:45 |
| cyphermox | yeah | 12:45 |
| cyphermox | I already can, sometimes, if I'm up late | 12:45 |
| didrocks | we need to find a schedule matching everyone as we have dependencies between stacks | 12:46 |
| cyphermox | but 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 online | 12:46 |
| cyphermox | yeah | 12:46 |
| cyphermox | we should confirm with mterry but I think he's in the same timezone as I am | 12:47 |
| cyphermox | depends how he wants to manage his time :) | 12:47 |
| didrocks | yep ;) | 12:47 |
| cyphermox | if it's better, making the stuff run later is fine too | 12:48 |
| cyphermox | but 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 |
| cyphermox | note, I love it, but it's not fair ;) | 12:49 |
| * cyphermox starts creating the hud stack | 12:50 | |
| didrocks | cyphermox: I agree ;) | 12:50 |
| didrocks | cyphermox: \o/ | 12:50 |
| didrocks | cyphermox: keep me posted! | 12:50 |
| didrocks | sil2100: can you look at what cyphermox is doing for creating a stack? I think this will interest you as well ^ | 12:50 |
| cyphermox | hmm | 12:51 |
| sil2100 | didrocks: ACK | 12:51 |
| sil2100 | cyphermox: 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 well | 12:52 |
| cyphermox | indicator-messages? | 13:05 |
| cyphermox | I think I got the config right, now, I'll need to have didrocks and fginther double-check though, it's pretty complicated :) | 13:06 |
| didrocks | ;) | 13:06 |
| cyphermox | https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/hud-stack/+merge/158098 | 13:07 |
| cyphermox | looks simple when you think just about adding the two packages to a new stack | 13:07 |
| cyphermox | but then you also need to keep the old behavior where it makes sense | 13:07 |
| cyphermox | so I pulled in the integration tests from indicators that made sense for hud | 13:08 |
| cyphermox | hopefully that will remain not broken, though it will need to be checked | 13:08 |
| cyphermox | fginther: pinging you again, because I can ;) ^^ | 13:08 |
| * cyphermox needs to do a quick modemmanager bugfix upload | 13:09 | |
| sil2100 | cyphermox: ok, I'll review this | 13:09 |
| didrocks | cyphermox: you should remove unity.tests.test_hud from the indicator stack | 13:10 |
| cyphermox | yeah? | 13:10 |
| cyphermox | I thought it didn't hurt to test that again in case it got broken by the indicators changes somehow | 13:10 |
| fginther | cyphermox, morning! | 13:11 |
| didrocks | cyphermox: does the test exercise anything indicatorish? | 13:11 |
| didrocks | cyphermox: if so, yeah, better to keep it :) | 13:11 |
| cyphermox | fginther: don't ping me! you're hiding the top part of my terminal ! :D | 13:11 |
| cyphermox | good morning | 13:11 |
| sil2100 | cyphermox: maybe we should also add some tests from test_search that are related to HUD? | 13:11 |
| cyphermox | didrocks: I don't know why / how the indicatos would break it though | 13:11 |
| didrocks | cyphermox: ok, as you feel it ;) | 13:12 |
| didrocks | cyphermox: libhud-qt-qml needs to be added IMHO | 13:12 |
| cyphermox | sil2100: good catch, I think I saw one of those, didn't had it because it didn't include "hud" | 13:12 |
| fginther | cyphermox, I had a question yesterday about the qa stack when you get a chance, most of the projects have a raring branch now | 13:12 |
| didrocks | to the list of installed binary package | 13:12 |
| cyphermox | fginther: yeah, I think it belongs being updated now that the branches have been branched | 13:12 |
| didrocks | cyphermox: 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 |
| cyphermox | didrocks: sil2100: I think I'd keep the tests as-is for indicators, but add the necessary bits to hud | 13:13 |
| didrocks | cyphermox: and adjust the schedule to start just after those dependencies stack | 13:13 |
| cyphermox | ok | 13:13 |
| didrocks | cyphermox: apart from those small sniggets, excellent work! :) | 13:13 |
| didrocks | (for the daily release part) | 13:13 |
| cyphermox | updated. | 13:17 |
| Cimi | mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/157859 | 13:20 |
| didrocks | cyphermox: oh, why bamfdeamon in packages? | 13:20 |
| didrocks | cyphermox: it's not part of the stack and should already be on the default iso | 13:21 |
| didrocks | cyphermox: so not needed to list it | 13:21 |
| cyphermox | ok | 13:21 |
| didrocks | (the packages are the binaries we are installing from this stack) | 13:21 |
| cyphermox | seems to me like it goes along with libbamf ;) | 13:21 |
| cyphermox | oh | 13:21 |
| didrocks | yeah, same reason for libbamf3-1 | 13:21 |
| didrocks | remove it :) | 13:21 |
| cyphermox | then neithr are useful yeah | 13:21 |
| cyphermox | sorry, I understood you meant I should list them | 13:21 |
| didrocks | no worry, I was talking about the dependencies on indicators because of it :) | 13:22 |
| cyphermox | yeah | 13:22 |
| cyphermox | I misunderstood | 13:22 |
| didrocks | cyphermox: unity.tests.test_search is for the hud or libcolumbus or both? | 13:22 |
| cyphermox | it's updated nao | 13:22 |
| cyphermox | AFAIK it does both | 13:22 |
| cyphermox | exercise libcolumbus via hud. | 13:22 |
| didrocks | cyphermox: you should keep it as well in the indicators stack then | 13:23 |
| cyphermox | indeed, I should | 13:23 |
| mzanetti | Cimi: why does jenkins fail on your MP? | 13:23 |
| cyphermox | didrocks: actually | 13:24 |
| cyphermox | shouldn't we rather move libcolumbus to the hud stack? | 13:24 |
| cyphermox | being the principal user and all | 13:24 |
| didrocks | hum, good question | 13:24 |
| didrocks | unity dash as well will use it | 13:24 |
| didrocks | but it's depending on the HUD | 13:24 |
| cyphermox | yeah | 13:24 |
| didrocks | so yeah, you may be right | 13:24 |
| didrocks | cyphermox: I think let's go with your proposal | 13:25 |
| cyphermox | perhaps I'll do that, and we'll get libcolumbus already building | 13:25 |
| cyphermox | I'll just make sure it's properly transitioned first | 13:25 |
| didrocks | cyphermox: so unity should deps on the hud stack as well, mind doing that change? | 13:25 |
| cyphermox | ok | 13:25 |
| didrocks | apart from that, everything looks gorgious for daily-build | 13:25 |
| cyphermox | fginther: btw, if you want to make a qa-magic-branching doo-da on libcolumbus ;) | 13:26 |
| didrocks | not sure for CI, I don't have this knowledge ;) | 13:26 |
| Cimi | mzanetti, dunno, I don't have the vpn set up anymore | 13:26 |
| mzanetti | Cimi: you don't need that to see the failures | 13:27 |
| mzanetti | Cimi: and second, you still should :D | 13:27 |
| seb128 | sil2100, hey, small comment, when you edit workitems, please refresh the page before | 13:27 |
| Cimi | mzanetti, yeah upgraded to raring | 13:28 |
| seb128 | sil2100, you reverted changes made 4 hours before your edit on client-1303-delivering-touch-apps-to-raring yesterday | 13:28 |
| seb128 | sil2100, I restored them so no worry | 13:28 |
| seb128 | (yeah, launchpad sucks for that, it should warn about edit conflicts) | 13:28 |
| sil2100 | Ohshit | 13:28 |
| sil2100 | seb128: sorry about that! I could have refreshed | 13:29 |
| seb128 | no worry ;-) | 13:29 |
| sil2100 | But I actually thought that there is a 'conflicts' message indicator when that happens | 13:29 |
| didrocks | nothing on that, you are not the first ;) | 13:30 |
| dednick | omg my calendar sucks so badly. no matter what i do it wont give me alerts! | 13:31 |
| Saviq | dednick, it's google, actually | 13:33 |
| Saviq | dednick, the invite doesn't have alerts attached by default | 13:34 |
| fginther | cyphermox, sorry, I don't have permissions for libcolumbs | 13:34 |
| cyphermox | fginther: sorry, I figure I didn't need to ask you | 13:34 |
| cyphermox | I'm dealing with Jussi directly for that | 13:34 |
| dednick | Saviq: yeah, i'm put it in manually. But the thunderbird ones wont work | 13:34 |
| fginther | cyphermox, no worries. | 13:34 |
| fginther | cyphermox, do you have anything prepared for the qa stack split? If not I'll prepare an MP. | 13:35 |
| cyphermox | so I'm going to file a separate merge to fix up libcolumbus in the indicators stack independently from the current changes | 13:35 |
| cyphermox | nothing prepared for that yet, no | 13:35 |
| cyphermox | fginther: well, it depends | 13:35 |
| cyphermox | I think it's just a matter of editing stacks/raring/qa.cfg slightly | 13:35 |
| cyphermox | didrocks: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/libcolumbus-branch/+merge/158108 | 13:42 |
| didrocks | cyphermox: you want to make the change in head separated? | 13:42 |
| cyphermox | didrocks: yeah, head will get changed with the other branch | 13:42 |
| cyphermox | I'll move libcolumbus in hud | 13:43 |
| cyphermox | but this one belongs being separate, so the change isn't delayed by the hud stack | 13:43 |
| didrocks | cyphermox: perfect for me, approved :) | 13:43 |
| cyphermox | sil2100: are the tests we want indeed the two you listed in your comment? | 13:44 |
| sil2100 | cyphermox: 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 want | 13:45 |
| cyphermox | ok | 13:46 |
| cyphermox | yes | 13:46 |
| cyphermox | ok, that's done now | 13:47 |
| cyphermox | didrocks: ^ I also moved libcolumbus | 13:47 |
| sil2100 | \o/ | 13:48 |
| cyphermox | coffee isn't agreeing with me this morning | 13:48 |
| cyphermox | I feel sick :/ | 13:48 |
| fginther | cyphermox, FYI, I'm reviewing the hud stack MP, it's a little tricky ;-( | 13:48 |
| didrocks | cyphermox: urgh :/ | 13:49 |
| cyphermox | fginther: yeah, I know :/ | 13:49 |
| cyphermox | I tried to keep the logic that was already there in phablet/qt.cfg | 13:49 |
| didrocks | cyphermox: +1 from my side | 13:49 |
| cyphermox | but I also had to bring in some stuff from indicators | 13:49 |
| cyphermox | fginther: don't hesitate to tell me it's all wrong, I just don't know enough about the CI jobs to be able to tell | 13:50 |
| didrocks | cyphermox: oh, just one thing, think about adding a dep in the unity stack on the hud stack | 13:51 |
| cyphermox | didrocks: yes! | 13:51 |
| didrocks | cyphermox: otherwise, everything's perfect for me :) | 13:51 |
| fginther | cyphermox, yeah, we didn't really anticipate moving projects around much, makes for a bit of pain when the default sections are different | 13:52 |
| fginther | cyphermox, but as we get better at this, I'm hoping the projects will begin to converge and there will be fewer special cases | 13:53 |
| cyphermox | fginther: didrocks: I wonder if it actually makes so much sense to have the ci jobs separated by stacks, rather than all flat | 13:53 |
| didrocks | cyphermox: well, normally, I think most of factorized CI jobs parameters are in a default file | 13:54 |
| cyphermox | since 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 fashion | 13:54 |
| didrocks | then, it's overriden by stack/components | 13:54 |
| cyphermox | ok | 13:54 |
| didrocks | not sure in practice if they have enough factorized stuff | 13:54 |
| cyphermox | fginther: didrocks: is there a document that outlines all of the config options currently used, their expected syntax, etc.? | 13:55 |
| cyphermox | that would be useful | 13:55 |
| cyphermox | since right now the ci changes that need to follow components I'm doing blindly, without having any idea of the net effect | 13:56 |
| didrocks | cyphermox: for DailyRelease, it's in the wiki, latest ones are not listed though (like the dependencies and so on), I need to do that | 13:56 |
| didrocks | cyphermox: for CI, I don't know | 13:56 |
| cyphermox | didrocks: thanks | 13:58 |
| cyphermox | sergiusens: hey | 14:00 |
| sergiusens | cyphermox: here I am | 14:01 |
| cyphermox | what do you mean by hud diverged? | 14:01 |
| sergiusens | cyphermox: let me save this channel :-) | 14:01 |
| cyphermox | this is explicitly to make the builds for phablet :) | 14:01 |
| sergiusens | cyphermox: for hud in raring, the one we have in our PPA at least (ppa:phablet-team), it's a version rolled back about 50 revisions | 14:02 |
| cyphermox | sergiusens: so not equivalent to lp:hud/phablet? | 14:02 |
| sergiusens | cyphermox: the one in lp:hud/phablet at least, which if I recall, didrocks was going to make that the new trunk | 14:03 |
| cyphermox | yes | 14:03 |
| cyphermox | it's a good catch, we need to merge lp:hud/phablet into lp:hud like, post-haste | 14:03 |
| cyphermox | so where is the code for the hud you use? | 14:04 |
| tsdgeos | Qt 5.0.2 http://blog.qt.digia.com/blog/2013/04/10/qt-5-0-2-released/ :-) | 14:04 |
| sergiusens | cyphermox: this is the reason: https://launchpad.net/~phablet-team/+archive/ppa/+build/4463830 | 14:05 |
| sergiusens | cyphermox: after the demo, it was stuck on a revision, there is no more work going into it | 14:05 |
| cyphermox | sergiusens: so where should I get hud? | 14:06 |
| cyphermox | I'm sorry, I just need to be extremely clear with everything so that there are no mistakes | 14:07 |
| cyphermox | is lp:hud/phablet not the right branch for the hud code that we are landing in raring for phablet? | 14:07 |
| sergiusens | cyphermox: that's more of a ted question, there was a divergence I wasn't aware of and noticed last week | 14:08 |
| cyphermox | ok | 14:08 |
| cyphermox | well, if the issue is indicator-appmenu, let me jsut quickly make sure that's already fixed | 14:08 |
| sergiusens | cyphermox: they aren't using the phablet-team ppa for a while either (change I wasn't told about either) for lp:hud/phablet | 14:08 |
| cyphermox | ok | 14:09 |
| cyphermox | so right now you're just shipping an old hud | 14:09 |
| cyphermox | yuck yuck yuck | 14:10 |
| sergiusens | cyphermox: yes... | 14:10 |
| cyphermox | ok... so I'm going to pull out my nexus 4 now, and try to build this hud on the current faily image | 14:10 |
| cyphermox | see how far it goes and what needs fixin' | 14:11 |
| sergiusens | cyphermox: well there is a bamf thing you might want to check with Saviq | 14:11 |
| cyphermox | sergiusens: so, why does it matter with the landing job though? | 14:12 |
| Saviq | me? | 14:12 |
| sergiusens | cyphermox: because phablet-land pushes to ppa:phablet-team | 14:12 |
| cyphermox | ok | 14:12 |
| cyphermox | fair enough :) | 14:12 |
| sergiusens | Saviq: https://launchpad.net/~phablet-team/+archive/ppa/+packages?field.name_filter=bamf&field.status_filter=published&field.series_filter= | 14:13 |
| cyphermox | so assuming hud/phablet magically builds fine, I'll leave the config as it is, since it would pretty much do what we want anyway | 14:13 |
| Saviq | sergiusens, actually... I think we can get rid of it from ppa:phablet-team | 14:14 |
| sergiusens | Saviq: if that's the case, then there is nothing to worry about | 14:14 |
| Saviq | sergiusens, with some tweaks in lp:unity/phablet-mods | 14:14 |
| cyphermox | nexus 4 battery, you make me sad. | 14:14 |
| sergiusens | Saviq: just for raring or quantal too? | 14:15 |
| Saviq | sergiusens, both | 14:15 |
| sergiusens | Saviq: ok, cyphermox we'll need to wait for those fixes | 14:15 |
| cyphermox | the what? | 14:15 |
| didrocks | sergiusens: which fixes? | 14:16 |
| === dandrader is now known as dandrader|afk | ||
| sergiusens | lp:unity/phablet mods to get rid of the bamf in pp:phablet-team so hud can build | 14:17 |
| cyphermox | ok | 14:17 |
| didrocks | sergiusens: how is this ppa impacting daily release which is targetting lp:hud? | 14:17 |
| didrocks | with lp:hud/phablet merged into lp:hud | 14:17 |
| sergiusens | didrocks: nothing really | 14:18 |
| sergiusens | didrocks: I was just saying: don't use phablet-land as the autolanding job | 14:18 |
| didrocks | cyphermox: can you remove this autolanding job parameter then? ^ | 14:18 |
| didrocks | sergiusens: then, I think you will go with manual merging until you can use lp:hud | 14:18 |
| cyphermox | ok | 14:19 |
| cyphermox | updated | 14:20 |
| Saviq | sergiusens, can I get a quick update on what's going on? | 14:21 |
| Saviq | and what do we need to do? | 14:21 |
| sergiusens | Saviq: well if we can get rid of bamf, that would be good... but let me come back to that | 14:24 |
| sergiusens | Saviq: daily releases are being setup, that's what's going on | 14:24 |
| sergiusens | Saviq: but I'm only half aware of the whole thing as I was kept out of the loop for the first half of this | 14:25 |
| Saviq | sergiusens, and why do we need to get rid of bamf? | 14:25 |
| sergiusens | Saviq: latest hud needs a newer bamf to build | 14:26 |
| Saviq | sergiusens, so we don't need to get rid of it, but we need to upgrade it ;) | 14:28 |
| Saviq | sergiusens, I assume it's not there for quantal | 14:28 |
| Saviq | there as in in distro | 14:28 |
| sergiusens | Saviq: yeah, we need to get rid of the version bump for raring | 14:28 |
| sergiusens | Saviq: yeah, just for raring and beyond | 14:28 |
| === dandrader|afk is now known as dandrader | ||
| fginther | cyphermox, hud stack mp reviewed | 14:33 |
| Saviq | sergiusens, now that you said it I don't know why I bumped the version there... | 14:34 |
| cyphermox | fginther: I'd kiss you if I wasn't so busy ;) | 14:35 |
| sergiusens | Saviq: ah, it gets complicated :-) | 14:35 |
| fginther | cyphermox, :-) | 14:36 |
| Saviq | sergiusens, I'm dropping the package from raring | 14:38 |
| Saviq | sergiusens, I don't _think_ it will break anything ;) | 14:39 |
| sergiusens | Saviq: ok | 14:39 |
| Saviq | sergiusens, and will update it for quantal | 14:39 |
| Saviq | sergiusens, do we need to remove it from some cache for the images? | 14:40 |
| sergiusens | Saviq: no, but I can get webops to do a delete | 14:41 |
| Saviq | sergiusens, and could we simply have daily builds of bamf in phablet-team PPA for quantal? | 14:41 |
| sergiusens | Saviq: of latest and greatest bamf? | 14:41 |
| Saviq | sergiusens, yea | 14:41 |
| Saviq | sergiusens, bamf 0.4.0daily13.04.03-0ubuntu1 is enough for the new hud? | 14:42 |
| Saviq | sergiusens, same for hud, really, we want it for quantal, too, right? | 14:42 |
| sergiusens | Saviq: rsalveti wanted us to target a cutover to raring this week, not sure quantal is worth it | 14:43 |
| Saviq | sergiusens, fine by me | 14:44 |
| sergiusens | cyphermox: read above ^^ | 14:44 |
| * rsalveti reading | 14:44 | |
| cyphermox | I don't know; does it actually need bamf at all? | 14:44 |
| rsalveti | yeah, hopefully raring will be good enough for the switch later this week | 14:45 |
| cyphermox | tedg was mentioning platform-api more | 14:45 |
| Saviq | cyphermox, yes it does | 14:46 |
| cyphermox | ok | 14:46 |
| Saviq | cyphermox, it finds out about apps from it for now | 14:46 |
| Saviq | +running | 14:46 |
| cyphermox | because you see, I'm about to try to build with a --disable-bamf switch ;) | 14:46 |
| cyphermox | ok, no such switch, but if there is no such package, it looks (quickly) like things should build | 14:48 |
| Saviq | cyphermox, it won't work on the desktop, is all | 14:49 |
| Saviq | cyphermox, the phone does not have bamf indeed | 14:49 |
| cyphermox | Saviq: that's fine | 14:49 |
| cyphermox | on the phone, we won't have bamf, so we will build without bamf for arm | 14:50 |
| Saviq | cyphermox, we only had it for legacy unity (that we still build libunity-core-6.0 out of) | 14:50 |
| cyphermox | on the desktop, we do have it so we can build with it | 14:50 |
| Saviq | cyphermox, yup | 14:50 |
| cyphermox | Saviq: so do you think we're good? | 14:50 |
| Saviq | cyphermox, yeah, I'd say so | 14:50 |
| Saviq | cyphermox, if we don't care about quantal, we can drop bamf from the PPA altogether | 14:51 |
| cyphermox | Saviq: don't need to just now, I'd say | 14:52 |
| Saviq | yup | 14:52 |
| cyphermox | I'm mostly thinking about ubuntu-unity/daily-build-next PPA | 14:52 |
| cyphermox | then we can fix stuff later if it just means deleting packaged | 14:52 |
| cyphermox | ok, can't really "disable" bamf per-se, I'll file a merge request after to make that possible | 14:53 |
| cyphermox | but I can hack the build-depends now to ensure libbamf is only required on !armhf | 14:54 |
| didrocks | hey mterry! did you look at unity? I tried to relaunch the tests, but I guess ati is dead… | 15:00 |
| didrocks | mterry: the results seems good on the other config, forcing publication? I know that slangasek would really like having his patch in ubuntu :p | 15:01 |
| mterry | didrocks, last I checked, it was still running | 15:05 |
| * mterry looks | 15:05 | |
| mterry | didrocks, ah yes, the ati is dead thing :) | 15:06 |
| didrocks | mterry: yeah, seeing it's running for more than the regular time, I think that the hud service crashes or something like that | 15:06 |
| didrocks | at some point, we'll need to check with thomi on how to detect that and relaunch the session | 15:06 |
| didrocks | and fix the crash as well :p | 15:07 |
| Cimi | mzanetti, mouseFlick has a speed parameter in UnityTestCase | 15:07 |
| mterry | didrocks, yeah I'm fine with a manual push | 15:07 |
| Cimi | mzanetti, who uses speed? | 15:07 |
| didrocks | mterry: \o/ please do, I'm sure you can easily poke slangasek once in unapproved to get it reviewed | 15:07 |
| mzanetti | Cimi: wasn't it you who added that? | 15:07 |
| Cimi | I am wondering if my implementation with duration was better | 15:07 |
| didrocks | mterry: just a feeling ;) | 15:08 |
| mzanetti | Cimi: for the BottomBar tests | 15:08 |
| Cimi | mzanetti, I added duration | 15:08 |
| mzanetti | Cimi: ah ok... then it might have been greyback | 15:08 |
| Cimi | mzanetti, mines wait | 15:08 |
| Cimi | mzanetti, this one relies on faketime | 15:08 |
| Cimi | I don't think this works for me | 15:08 |
| greyback | mzanetti: Cimi: frankly I don't notice a difference with changing the speed really. | 15:08 |
| Cimi | greyback, because this doesn't change the speed | 15:09 |
| Cimi | greyback, you need to add wait to change the speed | 15:09 |
| Cimi | with this fake time | 15:10 |
| Cimi | the action is instant | 15:10 |
| Cimi | (you can move 1000 pixels in 1ms) | 15:10 |
| Cimi | then you obtain a fake time "yay, it took you 10s!" | 15:11 |
| Cimi | in reality the mouse movement passed to QML should be 1000px per ms | 15:11 |
| greyback | Cimi: I expect you're right | 15:11 |
| Cimi | what I did was adding a wait in the for | 15:11 |
| Cimi | move 100px, wait 10ms, another 100px, 10ms etc | 15:12 |
| greyback | Cimi: you can add the 4th parameter to mouseMove which adds a delay | 15:12 |
| Cimi | greyback, https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/150847 | 15:12 |
| Cimi | this requires fixes (conflicts now with speed parameter) | 15:12 |
| Cimi | greyback, you can see the duration parameter | 15:13 |
| Cimi | now we have speed as 8th parameter | 15:13 |
| Cimi | shall we keep speed? (who uses it?) | 15:13 |
| Cimi | and add duration? | 15:13 |
| Cimi | or I can add a boolean as 9th parameter which adds a wait proportional to the speed set | 15:14 |
| Cimi | so for each cycle, not only update fakeTime but also wait the proportional ms | 15:14 |
| greyback | Cimi: just need 2 params, distance and speed should be enough | 15:14 |
| Cimi | greyback, I'll add 9th as boolean? | 15:15 |
| nic-doffay | Guys, I have some spare time for the rest of the day. Can I help anyone with anything? | 15:15 |
| greyback | Cimi: dude, 9 params? No come on, it needs to be simpler | 15:15 |
| Cimi | greyback, I don't want to break who added 'speed' | 15:16 |
| greyback | Cimi: fix the other tests, as opposed to adding cruft | 15:16 |
| greyback | Cimi: and if need be, a separate MR | 15:17 |
| Cimi | greyback, if somebody explains me why they added speed maybe I could do | 15:17 |
| Cimi | and why they didn't use wait but this fake time | 15:17 |
| Saviq | nic-doffay, read through https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests/+merge/155914 then | 15:17 |
| greyback | Cimi: find who did it. "bzr blame" will show you who | 15:17 |
| Saviq | nic-doffay, and have a stab at doing the same for infographics | 15:17 |
| nic-doffay | Will do Saviq | 15:18 |
| mzanetti | anyone here up for a review? https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/158129 | 15:18 |
| * mzanetti needs to go buy food. bbiab | 15:18 | |
| Cimi | dandrader, where are you using speed in mouseFLick? | 15:19 |
| Cimi | dandrader, is it working for you? | 15:19 |
| nic-doffay | mzanetti, sure. I'll review now, also need to go to the shops quick! | 15:19 |
| Saviq | mzanetti, half of the result of that test are warnings ;) | 15:19 |
| Saviq | mzanetti, sounds like we should look at getting rid of them? | 15:19 |
| dandrader | Cimi, let me check. | 15:20 |
| andyrock | mterry, ping | 15:20 |
| mzanetti | my gf cancelled the shopping tour | 15:20 |
| mterry | andyrock, hello | 15:20 |
| andyrock | mterry, hey, can we merge this branch now? https://code.launchpad.net/~mterry/unity/lens-friends/+merge/156584 | 15:20 |
| mzanetti | Saviq: yeah.. probably. should I fix them with this MP? | 15:20 |
| mterry | andyrock, oh... that shouldn't be necessary anymore | 15:21 |
| mterry | andyrock, unity must have been rebuilt with the latest libunity by now | 15:21 |
| andyrock | mterry, sweet... so can you delete this MP? :) | 15:22 |
| mterry | andyrock, just marked it rejected | 15:22 |
| dandrader | Cimi, check test_maxFlickSpeedToLaunchApp in tst_Launcher.qml. It's just to fool DragginArea's speed calculation | 15:22 |
| andyrock | mterry, thanks | 15:22 |
| greyback | Cimi: https://pastebin.canonical.com/88855/ works nicely for me. Speeds < 1 are nice and slow | 15:22 |
| Cimi | dandrader, does work for you if you change speed? | 15:23 |
| dandrader | Cimi, of course | 15:25 |
| Cimi | dandrader, mmm | 15:25 |
| dandrader | Cimi, but, again, only for DraggingArea. not for qml in general | 15:25 |
| Cimi | dandrader, I don't like this fakedatetime | 15:25 |
| Cimi | dandrader, I think a wait is enough | 15:26 |
| dandrader | Cimi, how reliable will that be? | 15:26 |
| Cimi | dandrader, instead of passing fake date times | 15:26 |
| Cimi | dandrader, you add a wait to the mouseflick | 15:27 |
| Cimi | dandrader, it works, without having to add code all around unity to fake slow events | 15:27 |
| dandrader | Cimi, and then you get varied results depending on how fast is the machine where the test is run | 15:27 |
| Cimi | dandrader, tests take some extra ms | 15:27 |
| Cimi | dandrader, no | 15:27 |
| Cimi | dandrader, because wait is a wait | 15:27 |
| Saviq | mzanetti, yeah, I'd say so | 15:28 |
| mzanetti | Saviq: yeah. already fixed most. Half of them are because of the shell.activateApplication() though | 15:28 |
| mzanetti | Saviq: which has a todo on it: // FIXME these should trigger actions on the lens/scope, when there's support | 15:28 |
| Cimi | dandrader, if you look at https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/150847 | 15:28 |
| Cimi | dandrader, I had the same problem for my dashbar using dragging area | 15:29 |
| Saviq | mzanetti, right, let's not fix those, then | 15:29 |
| mzanetti | Saviq: I'll fix the others tho | 15:29 |
| Cimi | dandrader, the simple call to wait inside mouseFlick works | 15:29 |
| Cimi | without any special code to launcher or dragginarea | 15:29 |
| mzanetti | Saviq: done | 15:31 |
| cyphermox | sergiusens: didrocks: building hud right now, got some changes to apply to the CMakelists.txt, but it looks promising. | 15:32 |
| cyphermox | back later, going to grab lunch and run some errands now | 15:32 |
| didrocks | cyphermox: \o/ enjoy your lunch :) | 15:32 |
| dandrader | Cimi, 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 want | 15:33 |
| dandrader | Cimi, and then to solve that you have to get the time elapsed since your previous mouseMove | 15:34 |
| dandrader | Cimi, and do the next mouseMove considering the time elapsed since the last move and your desired speed | 15:34 |
| Cimi | dandrader, which works for us because we test slow speeds | 15:34 |
| Cimi | dandrader, so if it's slower, even better | 15:34 |
| Cimi | the speed is a minimum speed | 15:35 |
| Cimi | and I don't think we have machines so slow that lose seconds of overhead | 15:35 |
| dandrader | for this specific case | 15:35 |
| Cimi | jenkins is not a 386 :) | 15:35 |
| dandrader | it's worse, it's in a VM | 15:36 |
| sergiusens | Saviq: 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 |
| Cimi | instead the code with faketime makes the unity code itself less clear | 15:36 |
| sergiusens | Saviq: clarification-> raring && phablet | 15:36 |
| dandrader | Cimi, I would rather try to get hold of the time and QAnimationDriver to ensure things happen exactly as we want in the tests | 15:37 |
| dandrader | Cimi, to make then really reliable | 15:37 |
| dandrader | instead of adding waits and hopping for the best | 15:37 |
| Saviq | sergiusens, the images from cdimage are good to test? | 15:37 |
| dandrader | otherwise we can get those familiar situations of "fails on jenkins but works on my machine" | 15:37 |
| greyback | dandrader: 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 fast | 15:37 |
| Saviq | sergiusens, hum | 15:38 |
| Cimi | greyback, 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 time | 15:39 |
| Cimi | greyback, just like launcher and dragging area and dashbar and future files will need | 15:39 |
| sergiusens | Saviq: mostly functional, yes http://sergiusens.github.io/posts/using-phablet-tools-to-install-raring-image.html | 15:40 |
| Saviq | sergiusens, looks bad, will have a look (or rather try and find someone with more knowledge) tomorrow | 15:40 |
| greyback | Cimi: I'm not saying your approach is totally wrong, I'm just pointing out it isn't 100% safe either. | 15:40 |
| Cimi | we're making the code way less simple just to avoid one line of code? (wait) | 15:40 |
| Cimi | greyback, and I understand | 15:40 |
| sergiusens | Saviq: well I bet it's the scope or something as the home lens is also empty | 15:40 |
| Cimi | greyback, I prefer better and simpler code in unity | 15:40 |
| dandrader | Cimi, who doesn't? | 15:41 |
| greyback | Cimi: well nobody is going to disagree with that statement | 15:41 |
| Cimi | good | 15:41 |
| dandrader | Cimi, but I also like reliable tests | 15:41 |
| Cimi | so why can't we add the wait and remove all those lines of code with fake timers? | 15:42 |
| dandrader | and there are cases where you can't achieve everything and have to make some compromises | 15:42 |
| Cimi | dandrader, I don't think there's any chance that tests will start to fail because of a wait | 15:42 |
| Saviq | mhr3, pstolowski anything springs to mind ./glib/gvariant-serialiser.c:1324:g_variant_serialised_n_children: code should not be reached ? | 15:42 |
| greyback | Cimi: 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 broken | 15:42 |
| mhr3 | Saviq, yep, you're seriously screwed :) | 15:43 |
| pstolowski | Saviq: nope.. | 15:43 |
| Saviq | :/ | 15:43 |
| Cimi | greyback, 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 wait | 15:43 |
| mhr3 | Saviq, unreffed variant, invalid memory... not something that will be fun | 15:44 |
| Cimi | at the current state there's no test that benefits of this added code | 15:44 |
| Cimi | and I can't see this changing in the future | 15:45 |
| Cimi | but we'll still have this cruft added | 15:45 |
| Cimi | I'm happy to use fake timers the day we will need them, at the moment it's just more code for no gain whatsoever | 15:45 |
| greyback | dandrader: 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 |
| greyback | dandrader: 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 do | 15:47 |
| Cimi | greyback, exactly | 15:48 |
| dandrader | Cimi, 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 tests | 15:48 |
| Cimi | greyback, fake timers will only work in custom components, where we can decide what a mouse event is doing | 15:48 |
| dandrader | Cimi, greyback like checking this QAnimationDriver API | 15:48 |
| Cimi | greyback, it won't work on listview where we can't add a custom timer | 15:49 |
| greyback | dandrader: Agreed. But we need something now that's hopefully good enough when used carefully. | 15:49 |
| Cimi | the duration worked for me with waits | 15:50 |
| Cimi | what we could do to make it more robust | 15:50 |
| Cimi | is getting the initial time when the flick starts | 15:50 |
| greyback | dandrader: I'd also suspect that QAnimationDriver is only related to Animation{} component and their subclasses. I worry they're not used in things like Flickables | 15:50 |
| Cimi | and instead always waiting maxDurationOfFlick / flickSteps | 15:50 |
| dandrader | greyback, I don't know. that's why said "study" :) | 15:51 |
| greyback | dandrader: yep :) | 15:51 |
| Cimi | each time we check where we are in the steps and use an adaptive wait | 15:51 |
| greyback | Cimi: that could help, yes | 15:51 |
| Cimi | to guerantee that the flick will last exactly the duration we wanted (or in good approximation), being less precises in the middle | 15:52 |
| greyback | dandrader: 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/consumption | 15:53 |
| greyback | not perfection, but it could be safe enough? | 15:53 |
| cyphermox | no lunch for me yet it seems | 15:55 |
| cyphermox | didrocks: it's not quite building yet, but soon :) | 15:55 |
| cyphermox | slowly fixing the issues | 15:55 |
| dandrader | greyback, yeah, could be | 15:55 |
| greyback | Cimi: want to give it a go? | 15:55 |
| Cimi | greyback, I can give it a go, but I think dandrader would be better candidate | 15:56 |
| Cimi | greyback, because we have to remove the fakeTimers he added | 15:56 |
| Cimi | and I don't know how was before! | 15:56 |
| Cimi | I can write the adaptive waiting code and put on pastebin | 15:57 |
| Cimi | if that helps | 15:57 |
| greyback | Cimi: please write it up, and I'll see if it suits my work | 15:58 |
| Cimi | ok | 15:58 |
| greyback | Cimi: and if it works for me, I'll throw together a branch removing the fake timers and see what dandrader thinks | 15:59 |
| Cimi | ok good! | 15:59 |
| Cimi | greyback, deal :) | 15:59 |
| greyback | Cimi: cool, thanks | 15:59 |
| nic-doffay | mzanetti, 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 | ||
| Cimi | mzanetti, how do I see what's wrong here? https://code.launchpad.net/~unity-team/unity/phablet.test_IndicatorItem/+merge/157919 | 16:04 |
| mzanetti | Cimi: I think it was a temporary failure. Just reapproved. lets see if it merges | 16:21 |
| Cimi | mzanetti, ok | 16:21 |
| Cimi | thx | 16:21 |
| mzanetti | Cimi: can you review my tests. Nic doesn't have time any more | 16:22 |
| mzanetti | Cimi: that would be the link https://code.launchpad.net/~mzanetti/unity/phablet-test-people-preview/+merge/158129 | 16:22 |
| Cimi | mzanetti, tomo morning | 16:23 |
| mzanetti | Cimi: ok, cool | 16:23 |
| mzanetti | Cimi: hey, what about this one? https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/150847 | 16:27 |
| Cimi | mzanetti, it's outdated | 16:27 |
| Cimi | mzanetti, doesn't work | 16:28 |
| Cimi | mzanetti, that's why I was chatting before | 16:28 |
| mzanetti | too bad | 16:28 |
| Cimi | greyback, dandrader|lunch http://paste.ubuntu.com/5695881/ | 16:29 |
| Cimi | greyback, only thing I didn't cover is if finalTime is less than getCurrentTimeMs() | 16:30 |
| Cimi | can be done with a Math.max or a clamp | 16:31 |
| Cimi | dunno what js does for negative wait | 16:31 |
| Cimi | greyback, 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 |
| greyback | Cimi: yes message received | 16:38 |
| Cimi | great! | 16:38 |
| Cimi | greyback, I didn't test it, cause my branch is broken, but should work | 16:38 |
| greyback | Cimi: okay | 16:39 |
| Cimi | greyback, because the last wait is guaranteed to be exactly the remaining time | 16:39 |
| Cimi | greyback, we could move the wait at the end of the for, not sure how will change | 16:39 |
| Cimi | it makes sense to me have it before | 16:40 |
| Cimi | I usually click then move the mouse, instead click and move, wait, release | 16:40 |
| Cimi | which works for iteration 0 | 16:40 |
| Cimi | at the price of possibly going after finalTime | 16:41 |
| greyback | Cimi: 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 one | 16:43 |
| greyback | s/it's/if/ | 16:43 |
| greyback | Cimi: but go to the gym, we can chat later/tomorrow | 16:43 |
| Cimi | greyback, yeah | 16:44 |
| Cimi | greyback, you prefer to just changing one? | 16:44 |
| Cimi | why? | 16:44 |
| Cimi | imagine the average wait is 200ms | 16:45 |
| greyback | Cimi: 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 again | 16:45 |
| Cimi | and the CPU misses 400ms | 16:45 |
| Cimi | what will happen to future steps? | 16:45 |
| Cimi | ah ok | 16:45 |
| Cimi | greyback, and if the delay was 400? | 16:46 |
| greyback | then we add additional logic for that case | 16:46 |
| Cimi | ok | 16:46 |
| greyback | probably just extending the duration to compensate | 16:46 |
| Cimi | your does 100, 120, 80, 100, 100 | 16:46 |
| greyback | because we want to maintain the speed | 16:46 |
| greyback | as much as possible | 16:46 |
| greyback | yep | 16:47 |
| Cimi | mine 100, 120, 93, 93, 93 | 16:47 |
| greyback | that was my thinking. As it maintains an average speed | 16:47 |
| Cimi | ok | 16:47 |
| Cimi | makes sense | 16:47 |
| Saviq | mzanetti, someone stole our coverage graphs! | 16:47 |
| mzanetti | Saviq: yes, I did | 16:47 |
| mzanetti | mistake in the automatik jenkins coverage | 16:48 |
| mzanetti | they'll come back soon | 16:48 |
| Saviq | mzanetti, ;) | 16:48 |
| Cimi | greyback, btw exdenting suration doesn't work, because we would like to preserve finalTime | 16:48 |
| greyback | Cimi: 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 |
| greyback | Cimi: when I say API, I mean you supply mouseFlick starting & end points and speed. That's it | 16:50 |
| Cimi | greyback, I'm wondering whether extending will change average speed | 16:50 |
| Cimi | average speed is distance / time | 16:50 |
| greyback | Cimi: it will. | 16:50 |
| Cimi | we set speed 100 | 16:50 |
| Cimi | if we decide to extend time speed will be reduced no? | 16:51 |
| greyback | Cimi: but your case was pretty extreme, so I think something has to be sacrificed to maintain sane behaviour | 16:51 |
| Cimi | gotcha | 16:51 |
| greyback | Cimi: mind, dandrader|lunch 's __dateTime stuff is at least very reliable, so that's what we need to compete with. | 16:52 |
| greyback | so I'm interested to see how this goes | 16:52 |
| cyphermox | didrocks: it's alive! | 16:54 |
| didrocks | \o/ | 16:54 |
| cyphermox | hud builds so far, running through tests | 16:54 |
| didrocks | cyphermox: phablet or desktop? | 16:54 |
| cyphermox | phablet | 16:54 |
| didrocks | ok :-) | 16:54 |
| cyphermox | I'll re-test desktop as soon as that's done | 16:54 |
| cyphermox | had to apply a few changes | 16:55 |
| didrocks | great ;) | 16:56 |
| didrocks | nice work cyphermox | 16:56 |
| cyphermox | waiting : 11/20 Test #11: test-indicator-source ............ Passed 1.72 sec | 16:56 |
| cyphermox | Start 12: test-application-list | 16:56 |
| cyphermox | the changes I did are specifically to make phablet a build-time switch | 16:56 |
| === dandrader|lunch is now known as dandrader | ||
| mzanetti | Saviq: they're back. and better than ever :D | 17:02 |
| didrocks | fginther: hey, if you have a sec, do you mind deploying that: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/167 | 17:23 |
| fginther | didrocks, done (not that you are here to notice :-) ) | 17:24 |
| Saviq | mzanetti, \o/ | 17:26 |
| === dandrader is now known as dandrader|afk | ||
| Saviq | mzanetti, is something still in flux with the coverage jobs? | 18:08 |
| Saviq | mzanetti, https://jenkins.qa.ubuntu.com/job/unity-phablet-quantal-armhf-autolanding/173/console | 18:08 |
| mzanetti | Saviq: yeah | 18:08 |
| Saviq | ok | 18:08 |
| mzanetti | Saviq: fix is on the way | 18:08 |
| Saviq | mzanetti, thanks | 18:08 |
| mzanetti | Saviq: its the first time I use the new jenkins config so I messed up in 2 places | 18:08 |
| Saviq | bad mzanetti | 18:08 |
| === dandrader|afk is now known as dandrader | ||
| mzanetti | dandrader: heh... just read your mail. tapped into the same mistake myself earlier this week | 18:39 |
| dandrader | mzanetti, :) | 18:40 |
| mzanetti | Saviq: jenkins is fixed. | 18:54 |
| * mzanetti is off | 18:54 | |
| Saviq | mzanetti, \o/ | 18:54 |
| Saviq | mzanetti, take care | 18:54 |
| mzanetti | Saviq: do'h! | 18:59 |
| mzanetti | its not *grrrr* | 18:59 |
| === jhodapp is now known as jhodapp|afk | ||
| Saviq | mzanetti, you really shouldn't do that close to EOD ;) | 19:04 |
| mzanetti | Saviq: so true... | 19:04 |
| fginther | cyphermox, not sure if daily-release is ready for this, but: https://code.launchpad.net/~fginther/cupstream2distro-config/qa-stack-update/+merge/158197 | 19:15 |
| jussi | I wonder if this "Jussi" guy has an irc nick... perhaps we can educate people to use it :) (loving all the pings...) | 19:22 |
| cyphermox | Hahaha :-) | 19:23 |
| cyphermox | fginther looks fine except the unstable branches which should not be necessary. Trunk is for that | 19:24 |
| fginther | cyphermox, do you mean the use of ppa:autopilot/unstable? | 19:26 |
| cyphermox | Ah that's a ppa yeah, never mind me then, I just don't understand that change | 19:27 |
| mzanetti | Saviq: now its really fixed. | 19:33 |
| Saviq | mzanetti, really? ;P | 19:33 |
| mzanetti | Saviq: I hope so :D | 19:33 |
| Saviq | the green dots at the top look promising indeed | 19:34 |
| mzanetti | Saviq: there is at least a green CI run now and clicking through the artifacts looks good | 19:34 |
| Saviq | but somehow test count fell down? | 19:34 |
| mzanetti | Saviq: yeah. thats why I've started to click through the artifacts | 19:34 |
| mzanetti | but can't find anything wrong so far | 19:34 |
| mzanetti | Saviq: hmm... but the fact that coverage is still up indicates something indeed | 19:35 |
| Saviq | mzanetti, http://s-jenkins:8080/job/unity-phablet-autolanding/176/testReport/ | 19:35 |
| Saviq | vs. http://s-jenkins:8080/job/unity-phablet-autolanding/166/testReport/ | 19:36 |
| Saviq | autopilot tests didn't get in? | 19:36 |
| mzanetti | Saviq: yep | 19:43 |
| mzanetti | Saviq: the file is in the artifacts though | 19:43 |
| === naee is now known as eean | ||
| cyphermox | sergiusens: fginther: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/hud-stack/+merge/158098 | 22:04 |
| cyphermox | updated the merge for the reviews you contributed. | 22:04 |
| fginther | cyphermox, thanks, approved | 22:10 |
| cyphermox | yay! | 22:30 |
| === jhodapp|afk is now known as jhodapp | ||
| === salem_ is now known as _salem | ||
| george_e | Quick 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_e | I've looked through launcher.h/.cpp and wasn't able to find anything. | 23:29 |
| bschaefer | george_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 drag | 23:30 |
| bschaefer | and Xdndmanager calls Launcher::DndStart (i think) | 23:30 |
| george_e | Ah, okay. | 23:30 |
| bschaefer | george_e, soo I would look at: void Launcher::DndStarted(std::string const& data) | 23:30 |
| bschaefer | as thats what Xdnd manager calls, which should move the launcher out of auto hide if its hidden | 23:31 |
| george_e | Okay, I've got that up here: http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/launcher/Launcher.cpp#L2777 | 23:31 |
| george_e | So I should be looking through the source code for Nux then? | 23:32 |
| bschaefer | george_e, well what are you looking for? | 23:32 |
| bschaefer | george_e, or rather whats your end goal? | 23:32 |
| george_e | I'd like to implement something similar in a Qt app. | 23:32 |
| george_e | I'd like to be able to execute code when the user starts dragging something. | 23:33 |
| bschaefer | george_e, ooo, hmm yeah you'll have to get it through the X event loop | 23:33 |
| george_e | Oh, okay. | 23:33 |
| * bschaefer thinks... | 23:33 | |
| george_e | Well, thanks for pointing me in the right direction. | 23:33 |
| bschaefer | its been a while...though you'll have to look at lp:nux | 23:33 |
| bschaefer | under nux/NuxGraphics/GraphicsDisplayX11.cpp | 23:33 |
| bschaefer | george_e, possibly under: void GraphicsDisplay::HandleDndDragSourceEvent(XEvent xevent) | 23:34 |
| george_e | Okay, I'll take a peek at that. | 23:35 |
| bschaefer | george_e, but its been a while since i've dug through the DND event handling in nux.. | 23:35 |
| bschaefer | note that file is huge and a bit hard to read :( | 23:35 |
| * george_e gasps at the size of the file :P | 23:35 | |
| bschaefer | haha...yeeah its never fun to dig through that one.... | 23:36 |
| bschaefer | george_e, err..umm you are trying to get stuff from your Qt app to be able to drag it onto the launcher? | 23:36 |
| bschaefer | or are you trying to detect DND stuff for your Qt app? | 23:37 |
| george_e | No, 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 |
| bschaefer | err nm, as i re-read your comment above :) | 23:37 |
| bschaefer | pretty 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 dragged | 23:38 |
| bschaefer | std::list<char *> GraphicsDisplay::GetDndMimeTypes() | 23:38 |
| bschaefer | george_e, some more info: http://www.newplanetsoftware.com/xdnd/ | 23:39 |
| bschaefer | hope that helps! | 23:39 |
| george_e | Thanks! | 23:40 |
| === slangase` is now known as slangasek | ||
| bschaefer | np! | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!