[07:20] <pitti> hello
[07:20] <pitti> I'm teaching unity about logind, and wrote some new test cases
[07:20] <pitti> right now, they only say "fail" on "make check", which isn't particularly helpful
[07:20] <pitti> is there a way to make them more verbose? like showing the particular assertion that failed, plus unity's  log output?
[07:21] <pitti> and can I run an individual test case?
[07:31] <tvoss> pitti, just running ctest should help
[07:33] <tvoss> pitti, does that help?
[07:36] <pitti> tvoss: it says "No test configuration file found!", in both the source root and in obj-x86_64-linux-gn
[07:36] <pitti> ...u
[07:36] <pitti> (back in 10)
[07:37] <tvoss> pitti, ack, branching unity :)
[07:57] <pitti> ./obj-x86_64-linux-gnu/CMakeCache.txt:CMAKE_CTEST_COMMAND:INTERNAL=/usr/bin/ctest
[07:57] <pitti> that's the only hit
[07:59] <pitti> but no hit for CMAKE_CTEST_COMMAND, so apparently it doesn't use ctest?
[08:02] <tvoss> pitti, might well be for unity current
[08:03] <tvoss> Saviq, ping
[08:03] <pitti> ah, obj-x86_64-linux-gnu/tests/CMakeFiles/check.dir/build.make has some clues
[08:03]  * pitti can't believe that he's the first guy wanting to debug a failed test case
[08:04] <tvoss> pitti, the unity cmake setup redefines the make test iirc
[08:04] <pitti> right, see above build.make comment, I think that's it
[08:04] <pitti> it calls gtest and dbus-test-runner
[08:05] <pitti> hm, calling gtester manually like this fails all over the place
[08:07] <pitti> and calling dbus-test-runner as build.make specifies is invalid: option parsing failed: Unknown option --gtest_output=xml:./
[08:07] <pitti> so perhaps that's some old stuff
[08:07] <tvoss> pitti, yup, think so
[08:07] <tvoss> Trevinho, ping
[08:09] <Saviq> tvoss, here
[08:09] <pitti> ah, I did find the verbose output, it just scrolled way off the screen
[08:09] <tvoss> pitti, \o/
[08:09] <pitti> so I guess my question reduces to "how can I run a single test case"?
[08:53] <tsdgeos> mzanetti: do we want the -v1 here? https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868 or is it a "typo"
[08:53] <tsdgeos> s/typo/leftover
[09:03] <pg_pt> Hi guys
[09:04] <pg_pt> does anyone here uses gnome3/unity with a double screen?
[09:05] <pg_pt> men, this really sucks sometimes, I'm sorry but its true :)
[09:07] <tsdgeos> Saviq: should we kill ./Components/QuitResetDialog.qml ?
[09:07] <MacSlow> I'm still getting this build-error on quantal... http://pastebin.ubuntu.com/5627627/ (used ./build -s ; ./build) any ideas what's missing?
[09:07] <Saviq> tsdgeos, yes
[09:07]  * tsdgeos kills
[09:08] <Saviq> MacSlow, that means UnityCore didn't build/install properly
[09:08] <veebers> pg_pt: I do sometimes, are you having issues with it?
[09:08] <Saviq> MacSlow, go into ../unity_build/unity/UnityCore
[09:08] <MacSlow> Saviq, what checks are recommended in that case?
[09:08] <Saviq> MacSlow, go make; make install;
[09:08] <tsdgeos> MacSlow: or you have an old CMakeCache, try removing it
[09:09] <Saviq> yeah, that too
[09:09] <Saviq> MacSlow, go ./build_unity 2>&1 | tee unity.log
[09:09] <Saviq> MacSlow, and paste unity.log somewhere
[09:10] <pg_pt> veebers: some issues yes, but the most hateful is that when you remove the large screen and everything just "Insert random position"
[09:10] <veebers> pg_pt: ah, yeah. I hate that too :-)
[09:11] <pg_pt> veebers: gnome shell didn't had that issue, but gnome shell is for fedora users it seems...
[09:12] <pg_pt> veebers: other issues are folders going to the black, unacessible part of the screen (when you have two monitors with diferent sizes)
[09:13] <pg_pt> veebers: and I cant see all my spaces in the bigger (on my case on the rigth) screen, because it puts a balck space at the rigth of the monitor. WHY???
[09:14] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity/killQuitResetDialog/+merge/154012
[09:14] <veebers> pg_pt: that is odd, I haven't seen them before
[09:14] <Saviq> tsdgeos, shall we kill Notifications already
[09:14] <Saviq> tsdgeos, now that we're cleaning things up
[09:15] <tsdgeos> Saviq: my grep showed that it was used somewhere, but maybe not really used :D
[09:15] <tsdgeos> ah, in the CMakeListst.txt ^_^
[09:15] <Saviq> tsdgeos, ;)
[09:16] <tsdgeos> ok, will put it in the same MR
[09:18] <MacSlow> Saviq, tsdgeos: there you go http://people.canonical.com/~mmueller/unity.log
[09:19] <tsdgeos> MacSlow: looks fine, did you try clearing the CMakeCache?
[09:19] <Saviq> MacSlow, rm CMakeCache*; ./build
[09:20] <MacSlow> Saviq, tsdgeos: doing that now
[09:20] <MacSlow> cache wasn't wiped yet
[09:23] <Saviq> mzanetti, can you comment on https://code.launchpad.net/~mzanetti/unity/phablet-verbose-ctest/+merge/152213 please?
[09:23] <pg_pt> veebers: http://imgur.com/kuHIqJo
[09:23] <Saviq> mzanetti, also, can you try generating coverage?
[09:25] <tsdgeos> my build suddenly doesn't find hud-client.h anymore :-S
[09:25]  * tsdgeos cleans everything
[09:28] <tsdgeos> and it works again :D
[09:31] <MacSlow> tsdgeos, Saviq: you want to wipe the Notifications directory from unity/phablet?! I intended to use that for the new stuff.
[09:31] <Saviq> MacSlow, well, you'll add it then, won't you ;)
[09:32] <Saviq> MacSlow, or will there be common history between the "old" and the "new"?
[09:32] <MacSlow> tsdgeos, Saviq: sure... just wanted to hint you this :)
[09:32] <Saviq> MacSlow, I actually wanted to clean it to prevent any conflicts between your work and the old stuff
[09:32] <MacSlow> Saviq, not really... just wanting to keep the Notifications directory... everything else will change
[09:32] <Saviq> MacSlow, then yeah, it's best to just drop and re-add
[09:33] <MacSlow> Saviq, in a custom branch I wiped it already.
[09:33] <MacSlow> Saviq, ok
[09:38]  * tsdgeos doesn't know how to do a for loop :-/
[09:38] <tsdgeos> Saviq: MacSlow: mzanetti: https://code.launchpad.net/~aacid/unity/fixTestMouseFlick/+merge/154017
[09:39] <MacSlow> tsdgeos, taking a look...
[09:39] <MacSlow> Saviq, tsdgeos: btw... build runs now on my desktop... thx
[09:39] <tsdgeos> MacSlow: great :-)
[09:40] <Saviq> MacSlow, cool, the occasional `bzr clean-tree; bzr clean-tree --ignored` helps
[09:40] <MacSlow> Saviq, oh... ok
[09:41] <Saviq> MacSlow, especially when you get build failures
[09:42] <MacSlow> Saviq, tsdgeos: I'll try to get it also working on my raring-based laptop.. and then see how I can get my humble beginnings of nosd in
[09:42] <tsdgeos> MacSlow: i'm using raring so it should also "just work"
[09:42] <MacSlow> btw... "Number of leaked pixmaps: 82" anything to fix this? Wrong setting?
[09:46] <tsdgeos> that happens
[09:46] <tsdgeos> tbh not sure who's fault is it
[09:46] <tsdgeos> whose
[09:48] <MacSlow> tsdgeos, I even get that with a very simple stand-alone test-program exercising preliminary notification-drawing... so it might be a QML-issue/bug?!
[09:48] <tsdgeos> may be
[09:54] <mzanetti> Cimi: ping
[09:55] <mzanetti> Saviq: I think the MP can be deleted. Cimi will add this properly in as he requires the same functionality as we have in qmluitests...
[09:56] <Saviq> mzanetti, k
[09:56] <mzanetti> Saviq: if not, I'll fix the MP to not overwrite the file
[09:56] <Saviq> mzanetti, which one, then? ;)
[09:57] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-verbose-ctest/+merge/152213
[09:57] <Saviq> mzanetti, yeah, but delete or not? ;)
[09:57] <mzanetti> lets wait for Cimi to reply my ping. when I know if he already started I'll take care of this one
[09:57] <mzanetti> Saviq: ^
[09:57] <Saviq> k
[10:05] <didrocks> davidcalle: hey
[10:05] <didrocks> davidcalle: unity-scope-tomboy shouldn't dep on tomboy, I'm removing it
[10:05] <davidcalle> didrocks, suggests, I presume?
[10:06] <pitti> didrocks, all: When I change something in lp:unity and send a MP, I don't add debian/changelog, right? that'll be autogenerated from the commit logs
[10:07] <didrocks> davidcalle: yeah, fixing that
[10:07] <mzanetti> pitti: its not autogenerated for lp:unity/phablet  I don't know for lp:unity
[10:07] <didrocks> pitti: depends, if you linked to a bug, right
[10:07] <didrocks> pitti: if not and you think you should mention it, please add to debian/changelog
[10:08] <pitti> didrocks: I did link to a bug, yes; I can add debian/changelog if that's better, I just don't want to collide with the automatic changelog generation
[10:08] <didrocks> davidcalle: https://code.launchpad.net/~didrocks/ubuntu-scopes/suggest-tomboy/+merge/154027
[10:08] <davidcalle> didrocks, if you prefer, you can send me a list of these "invasive" deps, I'll make the mps
[10:08] <didrocks> pitti: well, if you add to debian/changelog and mention the same bug than the one you linked with, it will detect you already mentionned it (with your name), and so won't repeat it :)
[10:09] <pitti> didrocks: ah, great; manual changelog it is then
[10:09] <didrocks> pitti: if you think that the bug title is not enough for the description, you can go manual :)
[10:09] <pitti> oh, it takes the bug title, nice
[10:09] <didrocks> pitti: otherwise, let it automatic :)
[10:09] <didrocks> yeah
[10:09]  * pitti adjusts that then
[10:10] <pitti> thanks, sorry for my n00b questions
[10:10] <didrocks> no worry ;)
[10:10] <didrocks> pitti: basically, it should just do the right thing, if you mention it, it won't duplicate the mention. If you didn't, it will take the associated bug title
[10:10] <didrocks> davidcalle: it's the only one I noticed ^
[10:11] <didrocks> davidcalle: ensure when you send the 3 remaining ones (pypi, sshsearch and evolution) and that they are ready for you, that they don't drag evolution for instance :)
[10:11] <davidcalle> didrocks, all the music players :)
[10:11] <seb128> didrocks, not sure where you put the limit, the calculator scope depends on gnome-calculator
[10:11] <davidcalle> didrocks, hey, but that would be fun :)
[10:12] <seb128> didrocks, just wanting to avoid pulling stuff in the default install? or do you try to slim down what unity brings in?
[10:19] <mzanetti> Saviq: you know why the home lens is broken?
[10:19] <Saviq> mzanetti, broken how?
[10:19] <mzanetti> Saviq: empty
[10:19] <Saviq> mzanetti, isn't, here
[10:19]  * Saviq checks
[10:19] <mzanetti> Saviq: its here since yesterday evening
[10:19] <Saviq> mzanetti, indeed
[10:19] <mzanetti> Saviq: mterry was the first to mention it
[10:19] <mzanetti> yesterday morning or so
[10:19] <Saviq> mzanetti, raring?
[10:20] <Cimi> mzanetti, sorry had irc closed
[10:20] <Cimi> mzanetti, indeed
[10:20] <Cimi> mzanetti, I was just doing that
[10:20] <mzanetti> Cimi: ok. thanks. I'll delete the old one then.
[10:20] <Saviq> mzanetti, unity-lens-mock doesn't work in raring
[10:20] <didrocks> seb128: I think we should have the same policy for all scopes
[10:20] <didrocks> seb128: the scope is just a hook
[10:20] <didrocks> so a feature available
[10:20] <didrocks> then, if you install the apps you have a new functionality in the dash
[10:20] <didrocks> I don't think that's what should pull gnome-calculator in the distro
[10:20] <didrocks> davidcalle: I don't see the banshee scope anywhere
[10:20] <didrocks> davidcalle: not a rhythmbox one (called rhythmbox)
[10:20] <didrocks> davidcalle: any news on my trivial MP? :p
[10:20] <mzanetti> Saviq: yes... but I'm on raring since 2 weeks now and it broke only yesterday
[10:21] <Saviq> mzanetti, might've been the smart scopes update
[10:21]  * pitti sends his first unity MP, wohoo!
[10:21] <didrocks> heh pitti ;)
[10:22] <seb128> pitti, congrats ;-)
[10:22] <mzanetti> Saviq: hmpf... and it crashes when searching the music lens :/
[10:22] <pitti> seb128: belay that until it gets merged :)
[10:22] <Saviq> mzanetti, yeah, we need to run the mock lenses against the locally installed libunity
[10:22] <Saviq> crap
[10:23] <mhr3> Saviq, smart scopes aren't in R yet
[10:23] <Saviq> hmm
[10:23]  * Saviq drops the PPA
[10:24] <didrocks> mzanetti: Saviq: latest home scope update is in the ppa
[10:24] <didrocks> mhr3 fixed the home scope not working
[10:24] <didrocks> 6.8.0daily13.03.19.1ubuntu.unity.experimental.certified-0ubuntu1
[10:24] <didrocks> Saviq: mzanetti ^
[10:24]  * mzanetti checks
[10:24] <Saviq> didrocks, yeah, unrelated
[10:25] <Saviq> (I think)
[10:25] <didrocks> 11:19:47   mzanetti | Saviq: you know why the home lens is broken?
[10:25] <Saviq> didrocks, in lp:unity/phablet
[10:25] <didrocks> Saviq: the result is that no result in home scope ^
[10:25] <didrocks> why do you speak about the smart scopes ppa then?
[10:25] <Saviq> didrocks, we're not using the system-wide lenses
[10:25] <Saviq> didrocks, complicated ;)
[10:25] <didrocks> ok ;)
[10:25] <didrocks> believing you then :p
[10:26] <didrocks> seb128: merci!
[10:27] <seb128> didrocks, de rien (free karma \o/ :p)
[10:27] <didrocks> ;)
[10:28] <Saviq> mzanetti, everything works here with current raring
[10:29] <Saviq> mzanetti, but smart scopes from the PPA do break it
[10:29] <mzanetti> ah ok...
[10:31] <mzanetti> Saviq: next problem:
[10:31] <Cimi> mzanetti, how can I replace set_tests_properties(tst_QmlTests PROPERTIES ENVIRONMENT "QT_QPA_PLATFORM=minimal") in a similar cmakelist as the one in qmluitests?
[10:31] <mzanetti> I'm helping nic to test the PageHeader... Turns out we access shell all over the place in there
[10:32] <mzanetti> Saviq: ah... nvm... just came to the solution myself
[10:32] <Saviq> mzanetti, ;)
[10:33] <Saviq> mzanetti, ultimately we need a global object that we proxy stuff through
[10:33] <mzanetti> Saviq: I would define a SearchListModel that offers the addQuery() function
[10:33] <mzanetti> Saviq: when unset, every pageheader will have its own searchhistory
[10:33] <Saviq> mzanetti, ah this
[10:34] <mzanetti> Saviq: or, it can be set to be the one in Shell.qml to share the same searchHistory
[10:34] <Saviq> mzanetti, that's temporary code anyway (we need persistent storage there)
[10:34] <Saviq> preferably u1db
[10:34] <mzanetti> Saviq: yeah. that can be added in the SearchListModel at some point I'd say
[10:34] <Saviq> mzanetti, yup, works for me
[10:35] <mzanetti> ok
[10:35] <mzanetti> Cimi: so... your turn now :)
[10:35] <Cimi> haha
[10:35] <mzanetti> Cimi: whats the problem?
[10:35] <Cimi> mzanetti, a doc for cmake might be good :)
[10:35] <mzanetti> Cimi: well... its pretty easy actually
[10:36] <mzanetti> Cimi: every cmake's functions first argument is a free-form string: target
[10:36] <Cimi> mzanetti, https://pastebin.canonical.com/87100/ (for the records)
[10:37] <Cimi> doesn't work
[10:37] <mzanetti> Cimi: so you do "add_executable(myTarget binary)" or "add_library(myTarget libfile)"
[10:37] <mzanetti> Cimi: that defines a new myTarget
[10:37] <mzanetti> Cimi: after that you have a bunch of functions that can modify that target
[10:38] <mzanetti> like set_target_properties(myTarget ENV foo=bar) to export a env variable when running this target for example
[10:39] <Cimi> ah I see
[10:39] <mzanetti> Cimi: the paste looks good
[10:39] <mzanetti> Cimi: haven't ran it tho
[10:39] <Cimi> mzanetti, with target instead tests work
[10:40] <Cimi> actually not
[10:40] <Cimi> no tests were found
[10:41] <Cimi> http://paste.ubuntu.com/5627815/
[10:41] <mzanetti> Cimi: you can add "message(blabla)" to cmake
[10:41] <mzanetti> Cimi: to have some debug prints
[10:43] <mzanetti> all: autopilot tests are enabled in jenkins. every MP must have test passing now to be approved by Jenkins
[10:48] <Cimi> mzanetti, ah ok it does work, but requires calling make testCarousel etc etc
[10:49] <mzanetti> Cimi: then somethings wrong with "add_dependencies(unittests test${COMPONENT_NAME})"
[10:49] <Cimi> I guess I need to not use custom targets?
[10:49]  * tsdgeos realizes eh can't compare anchors in the tests
[10:49] <tsdgeos> :./
[10:49] <mzanetti> tsdgeos: there is a way...
[10:49] <mzanetti> tsdgeos: some special command I can't recall right now
[10:50] <tsdgeos> mzanetti: any clue where to find it besides google?
[10:50] <mzanetti> tsdgeos: hmm... no...
[10:53] <mzanetti> tsdgeos: hmm... maybe I'm wrong... this is the anchor test from qtdeclarative: http://www.qt.gitorious.org/qt/qt/trees/a7493235a70f9e60d5d25d84b0782ee0a2e5c5fd/tests/auto/declarative/anchors
[10:54] <tsdgeos> yeah, seen that one
[10:54] <tsdgeos> compares x, y
[10:54] <mzanetti> yeah :/
[10:54] <tsdgeos> can do the same i guess
[10:54] <mzanetti> tsdgeos: probably... just make sure its flexible enough for different GU's and form factors
[10:55] <tsdgeos> my current idea is doing something like
[10:55] <tsdgeos> compare(hud.__searchBarContainer.x + hud.__searchBarContainer.height, hud.height, "AppStack is anchored at the top")
[10:55] <tsdgeos> so test the anchors by testing the x
[10:55] <tsdgeos> err
[10:55] <tsdgeos> obviously i need to change that to
[10:55] <tsdgeos> y
[10:55] <tsdgeos> but you get the idea :D
[10:58] <Cimi> mzanetti, so if I run make unittests cycles through all tests
[10:58] <Cimi> mzanetti, (I understood much more of cmake now)
[10:59] <mzanetti> Cimi: all == tests/unittests/* or all == tests/* ?
[10:59] <Cimi> mzanetti, I was running from the dir
[10:59] <mzanetti> oh... that works?
[10:59] <Cimi> mzanetti, so from tests/unittests
[10:59] <Cimi> it always worked
[10:59] <Cimi> but before make test was enough
[10:59] <Cimi> now make unittests
[10:59] <mzanetti> Cimi: make check
[10:59] <mzanetti> thats for the unittests
[11:00] <Cimi> mzanetti, it doesn't
[11:00] <Cimi> mzanetti, shall I add a dependency to main cmakefile?
[11:00] <Cimi> or do you have a fix for the previous cmakelist?
[11:01] <mzanetti> Cimi: yes please, add that
[11:01] <mzanetti> no. I don't have a fix here
[11:02] <Cimi> ok works
[11:03] <mzanetti> Saviq: what is smartscopes (the package that breaks stuff)?
[11:04] <Saviq> mzanetti, unity*
[11:04] <Saviq> mzanetti, http://www.omgubuntu.co.uk/2013/01/unity-to-ship-with-smarter-scope-searching-in-13-04
[11:06] <mzanetti> Saviq: I need to remove unity* ? that doesn't sound right
[11:09] <Saviq> mzanetti, what PPAs do you have installed?
[11:09] <mzanetti> Saviq: yeah... I have the phablet-team/ppa
[11:10] <Saviq> mzanetti, well, that wouldn't break the phablet shell - it would break your desktop one
[11:10] <mzanetti> Saviq: don't care about that
[11:11] <Saviq> mzanetti, then nothing in raring does break the phablet shell (yet)
[11:11] <mzanetti> still it doesn't work here :D
[11:12] <Saviq> mzanetti, is your home completely empty or just the favorites / recently contacted are empty?
[11:13] <mzanetti> Saviq: completely
[11:13] <Saviq> mzanetti, not even Apps??
[11:13] <mzanetti> Saviq: nothing
[11:13] <mzanetti> Saviq: it doesn't even switch to the home lens any more
[11:13] <mzanetti> Saviq: stays on the music lens at startup
[11:13] <Saviq> mzanetti, console output please
[11:14] <mzanetti> Saviq: I removed all sorts of stuff and am reinstalling right now
[11:16] <mzanetti> Saviq: haha... now all my lens are empty... seem we're not pulling needed deps
[11:17] <Saviq> mzanetti, yes we are (at least since yesterday) ;)
[11:17] <Saviq> mzanetti, demo-assets; unity-lens-mock
[11:17] <mzanetti> Saviq: ah ok... but not the package in the ppa
[11:17] <mzanetti> yeah, already installing
[11:17] <Saviq> mzanetti, no, they're not deps
[11:18] <Cimi> mzanetti, so :D what's the difference between unittests dir and qmluitests?
[11:18] <mzanetti> Cimi: try running them and find out :D
[11:18] <Saviq> Cimi, unittests can run without GL
[11:18] <Cimi> :D ok boys
[11:19] <Cimi> Saviq, DraggingArea requires gl??
[11:19] <Saviq> Cimi, QML requires GL, remember? ;)
[11:20] <Cimi> Saviq, so the Carousel is in unittests
[11:20] <Saviq> Cimi, 'cause it's only doing JS tests
[11:20] <Cimi> and uses QML
[11:20] <mzanetti> Cimi: yes
[11:20] <Saviq> Cimi, if you need to draw anything
[11:20] <Cimi> indeed
[11:20] <Cimi> ok guys
[11:20] <Cimi> I blame myself
[11:20] <mzanetti> Cimi: rule of thumb: do you use the line "when: windowShown" somewhere?
[11:21] <Cimi> Saviq, crossfadeimage? :D
[11:21] <Cimi> ratingstars as well
[11:22] <mzanetti> Cimi: whats with those?
[11:23] <Cimi> mzanetti, they are in unittests
[11:23] <mzanetti> Saviq: https://pastebin.canonical.com/87104/ <-- I removed everything unity* installed qml-phone-shell from the ppa and unity-lens-mock and demo-assets
[11:23] <Cimi> mzanetti, but they are qml, not js
[11:23] <mzanetti> Cimi: so?
[11:24] <Cimi> mzanetti, so I don't understand why draggingarea is in qmluitests
[11:24] <mzanetti> [12:20] <mzanetti> Cimi: rule of thumb: do you use the line "when: windowShown" somewhere?
[11:24] <Cimi> only that? ok
[11:25] <mzanetti> Cimi: that causes a window to be openend wich requires openGL
[11:25] <mzanetti> Cimi: you can also compile QML without opening a window
[11:25] <Cimi> dragging area doesn't
[11:25] <Cimi> I really don't understand why draggingarea should be in qmluitests
[11:27] <Cimi> unless mousearea requires opening a window
[11:27] <Cimi> for events
[11:28] <Saviq> mzanetti, your system is b0rked :P
[11:29] <mzanetti> Saviq: seem sso
[11:30] <mzanetti> Cimi: draggingarea does open a window
[11:30] <mzanetti> Cimi: try running the test
[11:31] <tsdgeos> mzanetti: what you think of https://code.launchpad.net/~aacid/unity/test_hud_element_positions/+merge/154048 ?
[11:32] <mzanetti> Saviq: actually our packages are too... installing qml-phone-shell on a system with absolutely nothing unity related should give you a working binary :/
[11:32] <mzanetti> no?
[11:32] <Saviq> mzanetti, working binary, yes, but not stuff like demo-assets or unity-lens-mock
[11:32] <mzanetti> tsdgeos: don't export all those __ properties
[11:33] <mzanetti> Saviq: I think it should pull in unity-lens-mock. but anyways, I've installed those two myself which causes the shell to crash
[11:33] <tsdgeos> mzanetti: so  how do i get to them? want me to do child[1].child[2].child[]?
[11:34] <Saviq> mzanetti, no, I don't think it should pull in unity-lens*, maybe recommend, but not depend for sure - you should have a working shell without any lenses installed
[11:34] <mzanetti> tsdgeos: review this and you'll have findChild(obj, objectName) https://code.launchpad.net/~mzanetti/unity/phablet-greeter-tests/+merge/153963
[11:34] <Saviq> mzanetti, did you install the *unity* packages from phablet-team/ppa?
[11:34] <tsdgeos> that was in needs work this morning :D
[11:34] <Saviq> i.e. did you apt-get upgrade from phablet-team/ppa
[11:34] <mzanetti> Saviq: I have... just no lens... if I install the mock-lens and demo-assets it crashes
[11:35] <mzanetti> Saviq: yes
[11:35] <Saviq> mzanetti, well, it doesn't crash on the devices, does it ;)
[11:35] <tsdgeos> mzanetti: ah the evil crash of demo-assets `mock-lens
[11:35] <tsdgeos> it happened here when i was in quantal
[11:35] <tsdgeos> the update to raring fixed me
[11:35] <tsdgeos> probably some crap lying around?¿
[11:35] <Saviq> yeah, the mock lens story is problematic
[11:36] <Saviq> it will use the system-wide GI for lenses/scopes
[11:36] <Saviq> we need to build them locally asap :/
[11:37]  * mzanetti tries ./build -s for the first time :D
[11:38] <tsdgeos> mzanetti: that keyClick looks baaaaaaaaaad
[11:38] <mzanetti> tsdgeos: you mean the typeString() function?
[11:38] <tsdgeos> mzanetti: in c++ you can do  QTest::keyClick(myWidget, 'a');
[11:38] <tsdgeos> that doesn't work in qml?
[11:39] <mzanetti> tsdgeos: tbh I didn't try it, but all the "docs" I could find sad, no, its an integer
[11:40] <tsdgeos> mzanetti: right, they only export the Qt::key version to qml :-/
[11:40] <tsdgeos> mzanetti: i think we should add the patch to support the char version
[11:40] <tsdgeos> it's a 5 line patch
[11:40] <tsdgeos> because your typeString will break once i try to write "Barça"
[11:40] <mzanetti> tsdgeos: yeah... but until that's in upstream can we haz this?
[11:41] <mzanetti> tsdgeos: yes, I know... it doesn't support special chars
[11:42] <Saviq> biab
[11:43] <tsdgeos> mzanetti: i guess, if there's nothing better :D
[11:43] <mzanetti> tsdgeos: I'll add a todo
[11:43] <tsdgeos> plz
[11:47] <mzanetti> tsdgeos: pushed
[11:48] <tsdgeos> mzanetti: tryCompare(pathview.currentIndex, data.uid)
[11:48] <tsdgeos> that's wrong syntax, no?
[11:48] <mzanetti> tsdgeos: do'h
[11:48]  * mzanetti wonders why it passes
[11:49] <tsdgeos> because it does
[11:49] <tsdgeos> compare(obj[prop], value)
[11:49] <tsdgeos> obj is pathview.currentIndex
[11:49] <tsdgeos> prop is data.uid
[11:49] <tsdgeos> and value is undefined
[11:49] <tsdgeos> so pathview.currentIndex[data.uid] is probably undefined too
[11:50] <tsdgeos> and undefined and undefined match
[11:50] <tsdgeos> :D
[11:53] <mzanetti> damn java script
[11:53] <mzanetti> anyways... pushed the fix
[11:53] <mzanetti> tsdgeos: ^
[11:54] <mzanetti> tsdgeos: ^
[11:54] <tsdgeos> yep
[11:54] <mzanetti> ooops...
[11:54] <mzanetti> was rerunning qml-phone-shell
[11:54] <tsdgeos> wrong window for ↑+Enter ;-)
[11:54] <mzanetti> and lost focus to the terminal
[11:55] <tsdgeos> mzanetti: so you think that the findObj thing is better than aliasing? why?
[11:55] <dandrader> tsdgeos, I've replied to your comments: https://code.launchpad.net/~dandrader/unity/phablet_tst_Revealer/+merge/153937
[11:55] <mzanetti> tsdgeos: because it does not pollute the public api of a copmonent
[11:56] <tsdgeos> mzanetti: ok, fair enough :-)
[11:56] <tsdgeos> dandrader: cool, i'll check asap
[11:57] <tsdgeos> mzanetti: why is the background always grey in the tests?
[11:57] <tsdgeos> because Graphics/ is not there?
[11:57] <dandrader> tsdgeos, ah, the mouseFlick fix was already merged. I'll have to modify my merge proposal them. wait a minute
[11:57] <mzanetti> tsdgeos: yes.
[11:58] <mzanetti> tsdgeos: but there is a branch from mterry in the works that integrates with lightdm
[11:58] <mzanetti> tsdgeos: that will fix this issue
[11:58] <tsdgeos> mzanetti: should we care? it makes me think "it's not working!" when seeing the test
[11:58] <tsdgeos> ok
[11:58] <tsdgeos> mzanetti: objectName: "wallpaper" we don't really use, but i guess mterry's branch will?
[11:59] <mzanetti> tsdgeos: nope... I added it and then decided not to use in the tests... will remove
[11:59] <tsdgeos> okidoki
[12:00] <mzanetti> done
[12:14] <Cimi> Saviq, so I still have the same issues as yesterday, I do import "../../plugins/Unity"
[12:14] <Cimi> in my test file
[12:14] <Cimi> and I don't have the right library imported I believe
[12:15] <Cimi> http://paste.ubuntu.com/5628002/
[12:16] <Cimi> mzanetti, or you know?
[12:16] <Cimi> some cmake magic required here?
[12:18] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity/test_hud_element_positions/+merge/154059 fixed to use findChild
[12:19] <Cimi> tsdgeos, can you help me? :)
[12:19] <mzanetti> Cimi: seems you have the wrong libunity-core
[12:20] <Cimi> mzanetti, yes exactly
[12:20] <Cimi> mzanetti, but this is from qmluitests dir
[12:20] <tsdgeos> Cimi: that's when running your test?
[12:20] <Cimi> tsdgeos, yes
[12:20] <Cimi> I might need to add something to the cmakelist I believe
[12:20] <tsdgeos> Cimi: i guess you should LD_PREFIX_PATH like run does
[12:21] <tsdgeos> but don't think it makes sense adding it to the CMakeLists.txt
[12:21] <mzanetti> isn't it LD_LIBRARY_PATH?
[12:21] <mzanetti> anyways, yes, this is the issue
[12:21] <tsdgeos> mzanetti: yeah that :D
[12:21] <tsdgeos> this is needed because our sucky system in which we install stuff in ../unity_build
[12:21] <tsdgeos> in a "proper" system where we would have the dependencies correctly installed this wouldn't happen
[12:22] <mzanetti> maybe we should extend ./run with a argument
[12:22] <mzanetti> ./run tests
[12:22] <tsdgeos> +1
[12:22] <Cimi> mzanetti, tried, doesn't work
[12:22] <mzanetti> and that will export paths to local installed stuff and call make whatever
[12:22] <mzanetti> Cimi: has to :D
[12:22] <tsdgeos> Cimi: what did you run exactly?
[12:23] <dandrader> tsdgeos, ok, https://code.launchpad.net/~dandrader/unity/phablet_tst_Revealer/+merge/153937 is ready now
[12:23] <Cimi> mzanetti, http://paste.ubuntu.com/5628017/
[12:23] <Cimi> LD_LIBRARY_PATH=$UNITY_CORE_BUILD_DIR/lib make testDashBar
[12:23] <Cimi> also tried exporting and re-running
[12:24] <tsdgeos> Cimi: did you export $UNITY_CORE_BUILD_DIR ?
[12:24] <tsdgeos> i mean $UNITY_CORE_BUILD_DIR is set in run
[12:24] <Cimi> oh god
[12:24] <tsdgeos> you should
[12:24] <tsdgeos> LD_LIBRARY_PATH=../../unity_build/build/lib make testDashBar
[12:24] <tsdgeos> or something like that
[12:24] <tsdgeos> correct amount of .. and paths
[12:25] <Cimi> I see indeed
[12:25] <Cimi> must work
[12:25] <Cimi> well, I'm back in 10 mins
[12:25] <Cimi> walking from bus to the office
[12:29] <mzanetti> tsdgeos: updated comments: https://code.launchpad.net/~mzanetti/unity/phablet-cleaner-pageheader/+merge/154056
[12:30] <tsdgeos> ok
[12:30] <tsdgeos> mzanetti: comments?
[12:30] <mzanetti> description + commit message
[12:30] <tsdgeos> ok
[12:30] <mzanetti> tsdgeos: didn't you ask for that?
[12:30] <tsdgeos> yes
[12:32] <tsdgeos> mzanetti: can you have a quick look at https://code.launchpad.net/~dandrader/unity/phablet_tst_Revealer/+merge/153937 i'm a bit concerned about the __dateTime thing but don't see other way to do it
[12:34] <dandrader> tsdgeos, mzanetti  well, it's dependency injection. perferctly fine IMHO
[12:34] <mzanetti> tsdgeos: dandrader: how about moving that time function to Time.js? Should be easier to replace it and keep the api clean
[12:35] <tsdgeos> dandrader: i'm not saying it's bad, i'm just saying it's a bit ugly since it complicates the api a bit :-)
[12:35]  * mzanetti wonders why a drag area needs a time anyways
[12:35] <tsdgeos> mzanetti: to know the speed you are dragging
[12:35] <mzanetti> right... and freeze the shell if you're too fast?
[12:35] <mzanetti> at least that happens frequently here :D
[12:36] <tsdgeos> mzanetti: not sure your idea is good, we want to replace it here to calculate the spped better, but in the general case we don't want to change the "current time"
[12:36] <dandrader> mzanetti, and how would that replacement take place in practice?
[12:37] <mzanetti> import path or something... was just an idea... In general I agree with tsdgeos that we should try to avoid such stuff in public component api
[12:37] <mzanetti> tsdgeos: dandrader: but we could use the findChild() to replace it somewhere inside the component, no?
[12:37] <mzanetti> so we keep this solution but don't pollute the API
[12:38] <tsdgeos> hmmm
[12:38] <tsdgeos> can we?
[12:39] <dandrader> mzanetti, I think it's cleaner to have it in the API than to have the test meddling with a component internals
[12:40] <dandrader> mzanetti, because that would be in practice a subtle, undocumented, API
[12:40] <dandrader> easier to break
[12:53] <Cimi> how do I import the unity plugin from tests/qmluitests?
[12:55] <tsdgeos> Cimi: see the cmakelists
[12:55] <tsdgeos> second parameter path
[12:55] <tsdgeos> is that what you want?
[12:56] <Cimi> tsdgeos, yes I added add_qml_test(DashBar ${CMAKE_SOURCE_DIR}/plugins/Unity)
[12:56] <davidcalle> didrocks, hey. I think I'll probably drop the PyPi scope, it's just too slow and I don't have the time to speed it up.
[12:56] <Cimi> maybe without Unity at last
[12:56] <didrocks> davidcalle: who was the upstream for it?
[12:56] <didrocks> davidcalle: so the he's warned that we are dropping his lens on upgrade :)
[12:56] <Cimi> indeed!
[12:57] <Cimi> ok I can finally write tests xD
[12:57] <tsdgeos> :-)
[12:57] <tsdgeos> lunch
[12:57] <davidcalle> didrocks, Chris Wayne
[12:59] <didrocks> davidcalle: is he aware about the change?
[12:59] <didrocks> davidcalle: we should probably mail him, do you mind checking with thomas?
[13:04] <didrocks> davidcalle: then, the only thing that needs ensuring it's working is evolution, from your side, right?
[13:04] <didrocks> davidcalle: (do you mind updating the packaging? I can review that)
[13:07] <davidcalle> didrocks, yes, he is aware (it's Chris Wayne from Canonical) and I can mail him about that. I've already talked to Thomas about that possibility, but I'll ask him for confirmation.
[13:08] <davidcalle> didrocks, yes, packaging update for Evo in a moment
[13:08] <didrocks> davidcalle: excellent, keep me posted!
[13:09] <didrocks> mmrazik: rev 88 of the config to add sshsearch
[13:10] <didrocks> mzanetti: https://code.launchpad.net/~submarine/ubuntu-scopes/sshsearch-to-deprecatedscope-api/+merge/153882 if you want to track.
[13:10] <didrocks> oupss
[13:10] <didrocks> mmrazik: ^
[13:14] <mmrazik> didrocks: done
[13:14] <didrocks> thanks :)
[13:14] <mmrazik> didrocks: btw. can you add the release/stack to which the change is related to your commit messages?
[13:14] <mmrazik> I start to get lost in all of them
[13:14] <didrocks> mmrazik: oh sure, will do then
[13:14] <mmrazik> thx
[13:31] <mzanetti> Cimi: will "make check" still work when you land your stuff?
[13:37] <mzanetti> tsdgeos: updated https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868
[13:48] <Saviq> mzanetti, nic-doffay, tsdgeos, why no tests in https://code.launchpad.net/~mzanetti/unity/phablet-cleaner-pageheader/+merge/154056 ?
[13:48] <mzanetti> Saviq: because nic-doffay writes the tests
[13:48] <Saviq> k
[13:48] <mzanetti> Saviq: I just helped him with making them compile
[13:55] <MacSlow> When using ./run_on_device is there a way to revert what way copied over afterwards (either via a script or manually via adb shell)?
[13:56] <mzanetti> MacSlow: it rsyncs your code to /data/ubuntu/home/phablet/shell
[13:57] <mzanetti> MacSlow: including bzr stuff
[13:57] <mzanetti> MacSlow: so in theory, ssh into the device, do a "cd shell" and bzr whatever you want in there
[14:03] <MacSlow> mzanetti, hm... there's no shell-directory in (/data/ubuntu)/home/phablet ... hm... maybe something went wrong with run_on_device
[14:04] <mzanetti> MacSlow: you did a ./run_on_device -s previously, right?
[14:04] <MacSlow> mzanetti, not with -s just plain
[14:04] <mzanetti> MacSlow: need to call -s (setup) once
[14:04] <MacSlow> what does the -s option... ah ok
[14:04] <mzanetti> MacSlow: just like all the other scripts
[14:05] <tsdgeos> mzanetti: so do https://code.launchpad.net/~aacid/unity/test_hud_element_positions/+merge/154059 and https://code.launchpad.net/~aacid/unity/cleanHudApiWithFindChild/+merge/154067 look better?
[14:05] <mzanetti> MacSlow: requirement for -s to succeed is to have successfully ran phablet-setup-network
[14:06] <MacSlow> mzanetti, yeah... I have that in place... also manually installed openssh-server etc
[14:06] <mzanetti> tsdgeos: yes, definitely. Just wanted for my branch to be merged and doing a test-run on yours before approving
[14:06] <MacSlow> mzanetti, still not used to all the convenience :)
[14:06] <mzanetti> MacSlow: run_on_device -s will install openssh on its own if not there
[14:06] <tsdgeos> dandrader: you're late ;-) https://code.launchpad.net/~aacid/unity/killQuitResetDialog/+merge/154012
[14:06] <mzanetti> MacSlow: also, phablet-setup-network -i would install ssh too
[14:07] <dandrader> tsdgeos, ah well. at least I can approve yours
[14:07]  * mzanetti actually needs to create test_on_device :D
[14:09] <dandrader> tsdgeos, so this whole Notifications dir (containing mocks I suppose) will be replaced by a real impl form MacSlow, right?
[14:10] <tsdgeos> dandrader: yep
[14:10] <MacSlow> dandrader, yup
[14:10] <dandrader> ok
[14:10] <tsdgeos> dandrader: besides we are not using it at all
[14:10] <tsdgeos> grep for Notifications
[14:10] <tsdgeos> and you'll see there's nothing
[14:12] <kgunn> paulliu: note MacSlow & mzanetti conversation ^
[14:12] <mzanetti> mterry: hey
[14:12] <mterry> mzanetti, hi!
[14:12] <mzanetti> mterry: great job on the greeter stuff!
[14:13] <mzanetti> mterry: not fully through with reviewing though...
[14:13] <nic-doffay> Saviq, I can confirm that branch works with the current tests I'm writing.
[14:13] <mzanetti> but looks promising
[14:13] <mterry> mzanetti, awesome, thanks
[14:13] <mzanetti> mterry: I started writing some tests. they should be merged to trunk
[14:13] <mterry> mzanetti, I'm going to send out an email for you and Robert so we can brainstorm how we're going to do the actual process separation of the greeter
[14:14] <mzanetti> mterry: depending on your plans you can either start to merge them and adapt for your changes - or I will do it tonight
[14:14] <Saviq> nic-doffay, yup, thanks
[14:14] <mterry> mzanetti, I'm feeling ill today, so I may not work much
[14:14] <Saviq> mterry, please include me
[14:14] <mterry> Saviq, OK!
[14:15] <mzanetti> mterry: sure. no problem... sould hopefully fit together well as I wrote the tests after reading through your branch
[14:15] <mzanetti> if not, I'll take care of it
[14:15] <Saviq> mzanetti, btw, is (will) the test run between -ci and -autolanding different?
[14:15] <mzanetti> Saviq: nope... both jobs are generated with the same template
[14:16] <Saviq> mzanetti, so if autolanding fails for whatever reason, there's no need to trigger -ci first, it's enough to reapprove?
[14:16] <mzanetti> Saviq: yeah, that shouldn't have changed
[14:17] <pg_pt> hi everyone, can somoene tell me how to integrate pidgin and unity on 12.10? I keep googling but all that appears is thing about a bug that is already solved
[14:17] <mzanetti> Saviq: I always re-trigger failed jobs directly in jenkins, so I can't tell for sure
[14:17] <Saviq> mzanetti, no, I rather meant that I always try to get into an all-green state for MPs before (re)approving
[14:17] <mzanetti> Saviq: ah... last week -autolanding was changed to also give votes
[14:17] <Saviq> mzanetti, and from what you say this shouldn't be necessary - if autolanding completes, ci would, too
[14:17] <Saviq> mzanetti, yeah, that I know
[14:18] <mzanetti> Saviq: yes... in theory
[14:18] <Saviq> mzanetti, just was under the impression that the autolanding test run would be lighter than ci
[14:18] <mzanetti> Saviq: nope... its not. exactly the same job (except the post-build steps of course)
[14:19] <Saviq> mterry, ^
[14:19] <Saviq> mterry, /me was overcautious with the CI vs. autolanding jobs
[14:19]  * Saviq spelling win
[14:19] <mterry> Saviq, ah OK, good to know
[14:20] <mzanetti> Saviq: you asked me to generate coverage statistics earlier today... Tried now.. it fails :/
[14:20]  * mzanetti will fix
[14:20] <Saviq> mzanetti, yeah, thanks
[14:20] <Saviq> mzanetti, btw, shouldn't we be getting graphs and stuff in jenkins? or does that require some more setup?
[14:21] <mzanetti> Saviq: the autopilot graph should start working as of today
[14:21] <mzanetti> Saviq: for QML I couldn't find a way to generate stats
[14:21] <pitti> Trevinho: do you know how to call a single test case in unity?
[14:21] <Saviq> mzanetti, yeah, I was mostly asking about gcov/lcov
[14:21] <mzanetti> Saviq: and for c++ we only have the QMLSortFilterProxyModel so I didn't bother too much so far
[14:22] <pitti> Trevinho: I'm reworking the logind branch according to your suggestion (thanks for the fast review BTW!)
[14:22] <Trevinho> pitti: use ./test-gtest --gtest_filter=*match*
[14:22] <mzanetti> Saviq: but yeah, I'll check it out - now that we have some real tests to be run
[14:22] <pitti> Trevinho: but I now need to restructure setup/teardown a bit so that I can kill the fake logind in a test case to check the CK/upower fallback
[14:22] <Trevinho> pitti: I was tracking it also before you asked for merge, so it was quick to do:)
[14:22] <pitti> Trevinho: oh, did you already start working on it? sorry
[14:23] <Trevinho> pitti: no, no,... I was checking your code
[14:23] <Saviq> mzanetti, cheers
[14:23] <Trevinho> pitti: I mean that I was loking at it even before you requested for merge :)
[14:23] <Trevinho> pitti: however, you don't need that... Just unset the methods handlers, this would lead to a dbus error  that would make the fall-back call to be used
[14:24] <pitti> Trevinho: right, but they are only set in SetUpTestCase(), we'll need to move that into setUp()
[14:24] <pitti> not a biggie
[14:24] <pitti> running a single (or few) test cases only is useful for many purposes, so thanks
[14:24] <Trevinho> pitti: mh, ah.. yeh probably they should be set on every test
[14:24] <kgunn> mzanetti: Saviq was just looking at what tests we have against all the components
[14:25] <pitti> ./test-gtest --gtest_filter='TestGnomeSessionManager.*'
[14:25] <pitti> Trevinho: ^ nice, that works, thanks!
[14:25] <Trevinho> pitti: yep
[14:25] <kgunn> mzanetti: Saviq does everything need a cooresponding unit test or are some actually tested via association?
[14:25] <Trevinho> pitti: you can also use stricter filters of course, but without them it's very annoying working on tests :)
[14:26] <pitti> Trevinho: WDYT about doing sth. like make check TEST_NAMES="TestGnomeSessionManager.* ThatOtherTest .." ?
[14:26] <pitti> (and adding that to HACKING)
[14:27] <mzanetti> kgunn: I'm more of the pragmatic person... I'd like to see tested most of the stuff separately to have better/more detailed reports. However, not doing it just for the sake of following the theory... so imho there can well be exceptions
[14:27] <Trevinho> pitti: yeah, it could be nice... I think we also should run these tests on builder btw... bregma was working on that... We've more than 1000 tests actually only manually-checked :/
[14:28] <kgunn> mzanetti: thanks....guess i was thinking when folks (like d'offay) were looking for something to write a test for
[14:28] <kgunn> do we have a priority list
[14:28] <kgunn> and is it just size/kb ?
[14:28] <kgunn> of the qml file :)
[14:28] <kgunn> bigger doesn't always mean more complex
[14:29] <kgunn> mzanetti: btw, i agree....practical approach is best
[14:30] <mzanetti> kgunn: true... regarding a priority list... no. But I think we're getting really close with the Components. Nic is currently writing tests for the PageHeader. After that the Components folder should be done (need to re-verify) and I need to create a list of the rest of the code
[14:31] <mzanetti> kgunn: however, we're reaching the area where code is still too much work in progress to be tested or will be replaced...
[14:31] <mzanetti> which is actually good news :)
[14:31] <kgunn> mzanetti: yeah...true, like fakeappwrapper
[14:31] <kgunn> and notifications rewrite
[14:32] <kgunn> mzanetti: and thanks for makin' a list and checkin' it twice....let me know if i can help in any way
[14:39] <pitti> Trevinho: do you know how I can temporarily make a mocked method fail? I tried calling logind_.reset() in the test case, but that just causes a segfault during cleanup
[14:40] <Trevinho> pitti: if you don't set the methods handler for that server it will fail by default...
[14:40] <Trevinho> so you can unset and then reset it
[14:42] <pitti> Trevinho: right, but previous test cases already set it
[14:42] <pitti> Trevinho: ah, I guess I need to move both the setup and the cleanup, nevermind
[14:42] <Trevinho> pitti: every test case is setup on SetUp, so on that method you can ensure what you want for all the tests..
[14:42] <Trevinho> TestSetUp is only executed once
[14:43] <pitti> Trevinho: so .reset() only resets the method call handlers, but not the entire object?
[14:44] <Trevinho> pitti: in TearDownTestCase it resets everything, but its done only once at the end of the whole tests
[14:44] <Trevinho> in TearDown we reset only the handlers
[14:44] <pitti> Trevinho: right, I know; I was wondering what reset() does
[14:45] <pitti> Trevinho: we don't right now, that's what I want to do :)
[14:45] <Trevinho> pitti: .reset removes deletes the pointed object from the smart ptr
[14:45] <Trevinho> so yes, deletes the server as well
[14:45] <pitti> oh, ok
[14:46] <pitti> Trevinho: is there a method to unset only the method handlers, i. e. to undo SetMethodsCallsHandler() ?
[14:47] <tsdgeos> mmrazik: mzanetti: https://code.launchpad.net/~dandrader/unity/phablet_tst_Revealer/+merge/153937 ?
[14:47] <Trevinho> pitti: yep, pass to it nullptr
[14:47] <pitti> Trevinho: excellent, thanks
[14:47] <Trevinho> pitti: i did it in some cases
[14:47] <Trevinho> pitti: for example it was in TEST_F(TestGnomeSessionManager, LogoutFallback) (see trunk version)
[14:47] <mzanetti> tsdgeos: ?
[14:47] <dandrader> tsdgeos, the bzr merge probably failed because trunk moved on in the mean time
[14:48] <mzanetti> tsdgeos: its a merge conflict
[14:48] <dandrader> checking that now
[14:48] <mzanetti> tsdgeos: dandrader
[14:48] <mzanetti> Text conflict in tests/qmluitests/CMakeLists.txt
[14:48] <mzanetti> 1 conflicts encountered.
[14:48] <dandrader> yes
[14:49] <dandrader> people are working too fast. trunk doesn't stay still for a minute :)
[14:49] <tsdgeos> mzanetti: where do i read that?
[14:49] <mzanetti> tsdgeos: click on one of the urls next to FAILURE:
[14:49] <tsdgeos> ah right
[14:49] <tsdgeos> sory :D
[14:53] <tsdgeos> mzanetti: commented in https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868
[14:56] <mzanetti> tsdgeos: lol... epic fail Nr 2 for today
[14:56] <mzanetti> tsdgeos: pushed
[14:56] <tsdgeos> mzanetti: i just found something ...
[14:57] <mzanetti> brb
[14:57] <tsdgeos> mzanetti: open ./src/testlib/qasciikey.cpp
[14:57] <tsdgeos> in qt5 code
[14:57] <tsdgeos> and you'll find yourself :D
[15:06] <mzanetti> tsdgeos: lol... the code is from a guy who sat next to me in nokia... I never knew what exactly he's doing
[15:06] <tsdgeos> mzanetti: but stil, if they have that switch, no need for us to have it again
[15:06] <tsdgeos> i'm almost done with the patch, it's really small
[15:08] <mzanetti> tsdgeos: what exactly are you patching?
[15:09] <tsdgeos> mzanetti: http://paste.ubuntu.com/5628385/
[15:09] <mzanetti> ah ok. cool
[15:12] <tsdgeos> mzanetti: https://codereview.qt-project.org/#change,51436
[15:16] <mzanetti> tsdgeos: awesome
[15:20] <kgunn> dednick: hey reading your "get started"
[15:20] <kgunn> wrt bzr branch lp:unity/phablet ~/phablet/unity-qml
[15:20] <kgunn> i just did bzr branch lp:unity/phablet
[15:20] <kgunn> w/o the ~/phablet/unity-qml
[15:21] <kgunn> it all seemed to work....what's the difference?
[15:21] <kgunn> dednick: sorry to pester...feel free to redirect me
[15:22] <dednick> kgunn: it only matters if you weren't in the ~/phablet directory already.
[15:22] <kgunn> dednick: thanks...just a dir designation
[15:23] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868
[15:23] <tsdgeos> mzanetti: yes
[15:23] <dednick> kgunn: yep. no prob
[15:23] <tsdgeos> mzanetti: maybe we should provide a make unsinstall?
[15:23] <tsdgeos> without the typo
[15:23] <mzanetti> hehe
[15:23] <mzanetti> makes sense probably
[15:24] <Cimi> mzanetti, tsdgeos I have an issue with my test (currently still no test, but writing the UI) lp:~unity-team/unity/phablet.dashBar_bottomswipe
[15:24] <Cimi> the DashBar is outside of the window, but this is weird if you see anchors for DashBar
[15:25] <mzanetti> tsdgeos: done
[15:26] <tsdgeos> Cimi: ok, let me see
[15:26] <mmrazik> seb128: not sure if you follow the bug. But it looks like max found what it is and is triggering the job now to check
[15:26] <mzanetti> I'm looking
[15:26] <tsdgeos> ok
[15:29] <seb128> mmrazik, I'm subscribed but didn't read that email yet, thanks
[15:29] <pitti> Trevinho: meh, I'm pulling my hair out; is test-gtest really what I need here (for the GnomeSessionManager tests), or perhaps test-gtest-dbus?
[15:30] <pitti> Trevinho: the call to logind.Suspend() still succeeds even if I never eve define that method anywhere, so it's either using a default implementation from the introspection template, or it's using the actual logind on the system bus (but test_mode_ == 1, I verified that)
[15:30] <Trevinho> pitti: well, I wanted to keep into test-gtest because test-gtest-dbus needs two processes...
[15:30] <Trevinho> pitti: I wanted to move everything into one, but some tests won't work, so I kept them separated
[15:31] <pitti> yeah, running test-gtest-dbus fails
[15:31] <Trevinho> pitti: you need test-gtest-server& before
[15:31] <tsdgeos> mzanetti: i can't get the commit hook to trigger, what am i supposed to do?
[15:31] <Trevinho> pitti: what I wanted is to make another test-gtest- for dbus where all is done into one process
[15:31] <mzanetti> tsdgeos: commit
[15:31] <pitti> Trevinho: would that make a difference here? or is the more likely explanation that my introspection template const std::string LOGIND is already defining those?
[15:32] <Trevinho> pitti: well, the introspection shouldn't define anything, a part the structure
[15:32] <pitti> Trevinho: if so, then just calling logind_->GetObjects().front()->SetMethodsCallsHandler(nullptr) isn't going to help, as the mock will still work; I'll rather have to set a mock method that fails, I guess
[15:32] <Trevinho> pitti: if you wait few minutes I can give a look to your branch
[15:33] <mzanetti> Cimi: got it
[15:33] <pitti> logind_->AddObjects(introspection::LOGIND, LOGIND_PATH)
[15:33] <pitti> Trevinho: ^ that sounds like it would actually add the Suspend() methods for me
[15:33] <Cimi> mzanetti, so what's the problem? :)
[15:33] <Trevinho> pitti: yes it adds
[15:33] <tsdgeos> mzanetti: ain't working https://codereview.qt-project.org/#change,51436
[15:33] <Trevinho> pitti: but it does not give them an implementation
[15:33] <tsdgeos> mzanetti: i mean http://paste.ubuntu.com/5628438/ :D
[15:33] <Cimi> because I might be stupid but I don't see what's wrong here
[15:33] <pitti> Trevinho: calling them still succeeds, though
[15:34] <pitti> so I either need to temporarily shut down the entire mock, or add a mock implementation of a failing Suspend() call (not sure how to do either)
[15:35] <mzanetti> Cimi: its not outside
[15:35] <mzanetti> Cimi: its just units.dp(2) height
[15:38] <Cimi> mzanetti, I can't see it
[15:38] <Cimi> mzanetti, it is black
[15:38] <Cimi> mzanetti, and at the end is 48 pixels
[15:39] <Cimi> end of the test
[15:39] <Cimi> you can see the log
[15:41] <Cimi> mmm
[15:41] <Cimi> maybe I got it
[15:41] <Cimi> but I'm wondering why is different on the Dash.qml
[15:42] <mzanetti> Cimi: in a meeting.. will come back to you in a bit
[15:43] <Cimi> ok
[15:58] <mzanetti> Cimi: back
[15:58] <mzanetti> sorry
[15:58] <Cimi> mzanetti, no worries
[15:58] <mzanetti> Cimi: so... afaics, the DashBar is anchored to the bottom of the screen
[15:58] <mzanetti> (and left and right)
[15:58] <Cimi> yes
[15:59] <mzanetti> Cimi: and the height is set to initialHeight which in turn is set to units.dp(2)
[15:59] <mzanetti> Cimi: which probably comes down to one pixel on a normal screen
[15:59] <Cimi> mzanetti, but it should be on screen
[15:59] <Cimi> mzanetti, no
[15:59] <Cimi> mzanetti, dp means 2 pixel
[15:59] <Cimi> anyway
[15:59] <mzanetti> Cimi: not agreeing here, but thats not the point... its a small bar at the bottom
[16:00] <Cimi> mzanetti, that anchors is exactly the one in dash.qml
[16:00] <Cimi> mzanetti, you're right with dp
[16:00] <mzanetti> Cimi: yes
[16:00] <Cimi> mzanetti,  = 2 is two pixels indeed
[16:00] <Cimi> got confused
[16:00] <Cimi> anyway
[16:00] <mzanetti> Cimi: depends on the screen
[16:00] <mzanetti> Cimi: and on GRID_UNITY_PX... but anyways
[16:00] <Cimi> it's the same anchors calls in dash.qml
[16:01] <mzanetti> Cimi: yes
[16:01] <Cimi> but here is not on screen
[16:01] <mzanetti> Cimi: I have a (lets say) 4 pixel tall black bar on the bottom
[16:01] <mzanetti> Cimi: don't you?
[16:01] <Cimi> mzanetti, no :\
[16:02] <Cimi> mzanetti, after that should expand
[16:02]  * mzanetti finds hard that to believe
[16:02] <Cimi> to 48
[16:02] <mzanetti> Cimi: when you're at the home lens you should have the orange bar exactly in the middle of the screen
[16:02] <Cimi> mzanetti, yes
[16:03] <Cimi> mzanetti, I have it on the shell
[16:03] <Cimi> mzanetti, not on the test
[16:03] <mzanetti> Cimi: oh... now I see the problem
[16:03] <mzanetti> sometimes I take bit long...
[16:06] <tsdgeos> mzanetti: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/87/console ?
[16:06] <mzanetti> tsdgeos: click on the #87 at the top of the page
[16:06] <mzanetti> tsdgeos: there is already a bug reported to make that more visible
[16:08] <tsdgeos> so the test is still unstable :-/
[16:08]  * tsdgeos kicks jenkins
[16:08] <tsdgeos> can i convert that to a qmluitest? :D
[16:08] <mzanetti> tsdgeos: but it doesn't look like a tough one
[16:08]  * tsdgeos hides
[16:09] <mzanetti> Cimi: dumb question... how do you launch it?
[16:09] <Cimi> mzanetti, make testDashBar
[16:09] <mzanetti> tsdgeos: yes... maybe even "should" is the right word
[16:09] <mzanetti> Cimi: yeah... I'd like to run it in qmlscene
[16:10] <tsdgeos> mzanetti: the question is who tells us that the qmluitests won't fail randomly like this ones in jenkins :D
[16:10] <mzanetti> tsdgeos: noone
[16:10] <pitti> Trevinho: ah, I figured it out; resubmitted, MP updated
[16:10] <pitti> Trevinho: thanks for your hints!
[16:10] <mzanetti> tsdgeos: but just the first impression is really a different one, isn't it?
[16:10] <Trevinho> pitti: no need to resubmit, just push to it... :)
[16:10] <Trevinho> pitti: np... I would have looked into it a little more, but I'm quite busy :/
[16:11] <tsdgeos> mzanetti: seems to be, somehow seems the grab+move up did not work
[16:11]  * tsdgeos watches the video again
[16:11] <mzanetti> tsdgeos: yeah... looks a bit like my greeter issues
[16:11] <pitti> Trevinho: I once again just have one failure (TestThumbnailGenerator.TestGetManyFileThumbnail), but that was there before me
[16:11] <Trevinho> pitti: let me check what i have here
[16:11] <Trevinho> pitti: yes, it fails here too
[16:12] <Trevinho> bschaefer: when you're here, can you check that please ^
[16:12] <pitti> Trevinho: it's actually quite nice with that indeed, the tests now cover all three stages of fallback (g-session -> logind -> CK)
[16:12] <Trevinho> pitti: cool :)
[16:12]  * bschaefer starts reading text
[16:12] <Cimi> mzanetti, qmlscene -I ../../plugins tst_DashBar.qml
[16:12] <Cimi> mzanetti, that works
[16:12] <Trevinho> pitti: for sure we test things that we were not before the unity-session-manager :)
[16:13] <bschaefer> pitti, hmm I thought that TestThumbnailGen was fixed a while ago
[16:13] <Trevinho> bschaefer: I've it failing on trunk as well
[16:13] <mzanetti> Cimi: lol... I tried "qmlscene tst_DashBar.qml -import ../../plugins/" and didn't get the idea to turn it around
[16:13] <bschaefer> Trevinho, IIRC andyrock fixed
[16:13] <mzanetti> thanks Cimi
[16:13] <Cimi> mzanetti, yours doesn't work because of -import
[16:13] <tsdgeos> mzanetti: seems it pulls "too little" to be honest
[16:13] <andyrock> bschaefer, what?
[16:13] <bschaefer> Trevinho, let me see if it fails for me :), but last time I checked it was a test error and not a regression
[16:13] <Cimi> mzanetti, it's -I
[16:13] <bschaefer> andyrock, the TestThumbnailGenerator.TestGetManyFileThumbnail unit test
[16:13] <tsdgeos> mzanetti: which resolution are we running in the fake XServer?
[16:14] <bschaefer> andyrock, you had fixed that right?
[16:14] <andyrock> bschaefer, not I did not fix it
[16:14] <Cimi> mzanetti, (qmlscene --help helped me, I did the same :-P)
[16:14] <bschaefer> andyrock, who fixed it haha?
[16:14]  * bschaefer now isn't sure if it was fixed
[16:14] <andyrock> bschaefer, nobody ;)
[16:14] <andyrock> it's still broken here
[16:14] <bschaefer> andyrock, Trevinho well shoot, Ill take a look at it
[16:16] <Cimi> mzanetti, the fact that works here is confusing :)
[16:16] <pitti> Trevinho: AFK for ~ 1 h
[16:16] <Cimi> mzanetti, (here = with qmlscene)
[16:16] <Trevinho> pitti: fine, I'll check your branch meanwhile...
[16:17] <mzanetti> Cimi: yes...
[16:18] <mzanetti> Cimi: but in the test, also when the DashBar should be fully opened, its still half covered
[16:18] <mzanetti> Cimi: maybe the window size is playing weird in the test run and you just can't see it
[16:18] <Cimi> mzanetti, no
[16:18] <Cimi> mzanetti, using qmlscene is fine here
[16:18] <Cimi> mzanetti, I press and drag from bottom, it expands
[16:19] <mzanetti> Cimi: yes thats it
[16:19] <mzanetti> Cimi: add a wait(30000) somewhere in your test
[16:19] <mzanetti> Cimi: then fire it up and while it waits, fire up qmlscene
[16:20] <mzanetti> Cimi: you will see that the qmlscene window is bigger
[16:20] <Cimi> what??
[16:20] <Cimi> so
[16:20] <mzanetti> Cimi: now don't ask me why
[16:21] <Cimi> qmlscene -I ../../plugins tst_DashBar.qml & make testDashBar
[16:21] <mzanetti> I bet its a bug in qmltestrunner and tsdgeos will fix it
[16:21] <Cimi> like that
[16:21] <mzanetti> :P
[16:21] <tsdgeos> mzanetti: ?
[16:21] <Cimi> tsdgeos, thanks mate :-P
[16:21] <mzanetti> Cimi: got it?
[16:21] <Cimi> mzanetti, YES
[16:21] <Cimi> qmlscene -I ../../plugins tst_DashBar.qml & make testDashBar
[16:21] <mzanetti> tsdgeos: qmltestrunner window seems slightly too small
[16:21] <tsdgeos> yes
[16:21] <tsdgeos> it's fixed in 5.1
[16:21] <mzanetti> see
[16:21] <mzanetti> Cimi: ^
[16:21] <mzanetti> :D
[16:22] <tsdgeos> or at least i saw it wrong in the hud tests
[16:22] <Cimi> so, no dashBar tests in the meanwhile? :)
[16:22] <tsdgeos> and when i ran them against the qmltestrunner i compiled from 5.1 it worked fine
[16:22] <mzanetti> Cimi: tests seem to pass nevertheless, no?
[16:22] <mzanetti> its just not that nice watching them
[16:22] <Cimi> mzanetti, well I can write them in a smaller window indeed
[16:22] <Cimi> yes
[16:22] <tsdgeos> Cimi: is there any problem besides you not seeing it?
[16:22] <Cimi> no
[16:22] <Cimi> sorry
[16:22] <Cimi> was just searching for an exscuse to skip this xD
[16:23] <Cimi> (joking)
[16:23] <tsdgeos> :D
[16:24] <hikiko> hi
[16:24] <tsdgeos> ho
[16:24] <Saviq> tsdgeos, Kaleo had a feeling that you might know something about measuring QML test coverage
[16:24] <Saviq> tsdgeos, how do you respond? ;)
[16:24] <tsdgeos> Saviq: running fast?
[16:24] <kaleo> lol
[16:25] <tsdgeos> Saviq: actually 5 minutes ago i had an idle thread in my brain that woke up and thought "how are we going to do that qml coverage thing? doesn't seem easy"
[16:25] <Saviq> lol
[16:25]  * tsdgeos gently points mzanetti to https://code.launchpad.net/~aacid/unity/test_hud_element_positions 
[16:26] <mzanetti> tsdgeos: don't do it gently
[16:29] <kgunn> lol to last 5 minutes of irc
[16:30] <tsdgeos> Saviq: boiko is going to need a release of the shell after me merge https://code.launchpad.net/~boiko/unity/phablet-rename_phoneapp/+merge/153812
[16:30] <tsdgeos> Saviq: shall we do one?
[16:35] <mzanetti> tsdgeos: finally approved
[16:35] <tsdgeos> goodie, let's see if CI likes the changes i did at https://code.launchpad.net/~aacid/unity/cleanHudApiWithFindChild/+merge/154067
[16:35] <tsdgeos> they don't belong there
[16:35] <tsdgeos> but oh well
[16:43] <didrocks> mmrazik: hey, is CI working for https://code.launchpad.net/~didrocks/ubuntu-wallpapers/raring/+merge/154070?
[16:43] <mmrazik> didrocks: let me check
[16:46] <mmrazik> didrocks: in the queue. There was some misconfiguration. alesage is guilty :)
[16:46] <mmrazik> but should be fixed
[16:47]  * mmrazik is now going to check why his watchdog didn't report it 
[16:47] <didrocks> mmrazik: ahah! excellent, thanks :)
[16:47] <didrocks> mmrazik: once deployed the new world way, fortunately, this won't happen agian!
[16:47] <didrocks> again*
[16:47]  * alesage tail between legs
[16:47] <mmrazik> didrocks: yeah. this particular error shouldn't happen
[16:48] <mmrazik> alesage: the problem was that ubuntu-...-wallpapers-daily was triggered as a ci job and locked the MP
[16:48] <alesage> o oops :/
[16:49] <didrocks> alesage: bouhhhh! :)
[16:49] <mmrazik> didrocks: mhm... don't know why the old watchdog didn't find it and I'm not too keen to debug something that is going to be irrelevant.
[16:49] <mmrazik> didrocks: can I use some stack and put ubuntu-wallpapers into it?
[16:49] <didrocks> mmrazik: indeed
[16:49] <mmrazik> or should I create a new one?
[16:49] <didrocks> mmrazik: it's in misc
[16:49] <mmrazik> if yes, which?
[16:49] <mmrazik> didrocks: oh.. its there?
[16:49] <mmrazik> then let me check
[16:50] <didrocks> so the new watchdog gets the same error?
[16:50] <mmrazik> mh... in that case the other watchdog should have found it
[16:50] <mmrazik> I'm checking
[16:51] <mmrazik> didrocks: sorry. THe new watchdog is reporting it correctly. I just didn't notice as there is one stalled for unity and didn't scroll all the way down
[16:51] <didrocks> ah ok :)
[16:51] <didrocks> well, better that than a bug :)
[16:51] <tsdgeos> mzanetti: since saviq is not here and we need to release to accomodate for the phone-app name change, can you have a look at https://code.launchpad.net/~aacid/unity/release163/+merge/154146 ?
[16:54] <mzanetti> tsdgeos: 2 comments
[16:55] <tsdgeos> yes?
[16:55]  * tsdgeos f5
[16:55] <tsdgeos> mzanetti: what do you mean "it also misses the tests in unittests" ? You want the "more reliable commit mentioned"?
[16:56] <mzanetti> tsdgeos: I think there are also some tests i there which are not mentioned in the changelog
[16:56] <mzanetti> tsdgeos: however... its a comment. I wouldn't reject the commit because of that
[16:56] <tsdgeos> let me recheck
[16:56] <mzanetti> tsdgeos: just noticed that you listed all the qmluitests
[16:56] <tsdgeos> well, the only test in unittest is the hud one
[16:56] <tsdgeos> so it's also list there
[16:57] <tsdgeos> :D
[16:57] <tsdgeos> no?
[16:57] <tsdgeos> and the greeter one
[16:57] <tsdgeos> but that's also listed
[16:58] <tsdgeos> mzanetti: fixed the typo
[17:04] <mzanetti> tsdgeos: done
[17:04] <tsdgeos> greetz
[17:10] <MacSlow> first humble personal milestone... http://people.canonical.com/~mmueller/notify-osd-ng-1.mp4 (note: that amount of notifications is not a new design... just a test :)
[17:10] <mzanetti> MacSlow: dead link
[17:11] <mzanetti> I guess it should be chinstrap
[17:11] <mzanetti> om26er: still around?
[17:11] <om26er> mzanetti, yes i am here
[17:11] <mzanetti> om26er: hey. so... about the notification tests
[17:12] <mzanetti> om26er: first of all, the notifications are in another project (indicators-client)
[17:12] <om26er> mzanetti, yes, i was looking at writing tests for the indicators but seems nothing much is present in them to test
[17:12] <mzanetti> om26er: which means the actual content of them should be tested in that project, not in the shell
[17:13] <om26er> mzanetti, that would mean testing the chewie-client ?
[17:13] <mzanetti> om26er: in the shell we need tests, that make sure it gets loaded and displayed but not the actual functionality
[17:13] <mzanetti> om26er: so yes. indicators-client is one thing. but also in the shell a bit
[17:13] <MacSlow> doh...
[17:13] <MacSlow> first humble personal milestone... http://people.canonical.com/~mmueller/notify-osd-ng-phone-1.mp4 (note: that amount of notifications is not a new design... just a test :)
[17:13] <mzanetti> om26er: just wanted to make sure that you're not testing indicators content within the shell
[17:14] <MacSlow> mzanetti, cut&paste isn't my personal strength today
[17:14] <om26er> mzanetti, that didn't work as well, i was looking at testing the indicator contents from shell but i guess nothing is exposed there
[17:14] <om26er> mzanetti, so what should i be writing tests for ?
[17:15] <mzanetti> om26er: so what we need in the shell is basically opening each indicator once and check if plugins are loaded.
[17:15] <om26er> plugins are not being loaded as of now, not sure how to load them though
[17:16] <mzanetti> om26er: if you install indicator-battery and indicators-client-plugin-power you should get the power thingie
[17:16] <mzanetti> om26er: same goes for the others
[17:16] <mzanetti> om26er: doh... just wanted to ask saviq if those packages should be dependencies
[17:17] <mzanetti> om26er: anyways, make them dependencies of the -autopilot package in case
[17:17] <mzanetti> om26er: does that clear things ub?
[17:17] <mzanetti> up?
[17:18] <mzanetti> MacSlow: nice!
[17:18] <om26er> mzanetti, it seems all of those is already installed
[17:18] <om26er> mzanetti, but still the issue is that nothing shows up in their menus
[17:18] <mzanetti> om26er: then you need to run them probably
[17:18] <mzanetti> om26er: it will show up once the necessary daemons are running
[17:18] <om26er> mzanetti, is everything known to work fine in raring? as I am on raring now
[17:19] <mzanetti> om26er: good question... I'm on raring too. but haven't seen/used the indicators since then
[17:20] <mzanetti> om26er: running chewie-client works here
[17:20] <tsdgeos> mzanetti: can you reapprove https://code.launchpad.net/~aacid/unity/test_hud_element_positions/+merge/154059 there was a merge conflict
[17:20] <om26er> mzanetti, except for battery and date time all indicators are empty
[17:21] <om26er> completely
[17:21] <mzanetti> om26er: yeah... I don't know exactly whats the issue
[17:21] <mzanetti> Saviq: do you perhaps have some hints for om26er?
[17:22] <mzanetti> tsdgeos: done
[17:22] <tsdgeos> mzanetti: okidoki
[17:22]  * tsdgeos eods
[17:22] <mzanetti> tsdgeos: o/
[17:23] <tsdgeos> btw https://codereview.qt-project.org/#change,51436 has been approved :-)
[17:23] <mzanetti> tsdgeos: \o/
[17:23] <tsdgeos> \o/
[17:23] <tsdgeos> tomorrow more
[17:23] <mzanetti> om26er: but you can start with one that works... once you have one test in place that makes sure the wifi plugin loads, it'll be easy to copy it to the other indicators once they work
[17:24] <om26er> mzanetti, yeah i am trying the battery menu
[17:24] <Saviq> sorry guys, my VPS (hence IRC bouncer) network is somewhat flaky
[17:25] <Cimi> mzanetti, do you know how can I do a slow mouse drag?
[17:25] <mzanetti> Cimi: inherit from UnityTestCase
[17:26] <mzanetti> Cimi: that will give you useful helpers
[17:26] <Cimi> mzanetti, there's only one here
[17:26] <mzanetti> Cimi: which should be dragMouse() or something like this
[17:26] <mzanetti> :)
[17:27] <mzanetti> Cimi: also, if you merge master there will be more
[17:28] <Cimi> mzanetti, indeed :)
[17:29] <Cimi> mzanetti, actually I believe I can add wait and that will slowdown speed
[17:29] <Cimi> mmm
[17:31] <mzanetti> Cimi: please don't slow down tests if not absolutely necessary
[17:31] <Cimi> mmm ok
[17:31] <mzanetti> Cimi: they should be as fast as possible
[17:31] <Cimi> I know
[17:31] <Cimi> mzanetti, every second we save on jenkins is precious :)
[17:33] <mzanetti> indeed
[17:33] <Cimi> mzanetti, anyway, I don't know (still) how to make a slow drag
[17:34] <Cimi> mzanetti, and unitytestcase doesn't do anything
[17:34] <mzanetti> Cimi: what exactly do you want to do?
[17:34] <Cimi> mzanetti, dashBar and Launcher
[17:35] <mzanetti> Cimi: also, albert merged a fix today for that drag function
[17:35] <Cimi> mzanetti, they don't reveal if the speed is low
[17:35] <mzanetti> Cimi: try merging trunk
[17:35] <Cimi> mzanetti, I have trunk merged
[17:35] <mzanetti> oh
[17:35] <Cimi> or well, they depend on where you release
[17:35] <Cimi> this is not tested at the moment
[17:35] <mzanetti> Cimi: yes. they depend on where you release... but not at the speed of dragging afaics
[17:36] <Cimi> no
[17:36] <Cimi> mzanetti,
[17:36] <Cimi> draggingArea.dragVelocity < -44
[17:36] <Cimi> or > 44
[17:36] <Cimi> else lookup position
[17:36] <mzanetti> oh... hmm... who wrote that code?
[17:37] <Cimi> mzanetti, vesa
[17:37] <Cimi> mzanetti, well, for dashbar I wrote
[17:38] <Cimi> mzanetti, because I was asked to copy toolbar in sdk
[17:38] <Cimi> mzanetti, and toolbar sdk was copied from vesa's code
[17:38] <mzanetti> hmm... ok... then you know best what to do...
[17:38] <Cimi> mzanetti, and vesa doesn't like that code at all
[17:38] <mzanetti> yeah... if you need to... make it slower
[17:38] <Cimi> mzanetti, don't do this and patch toolbar
[17:38] <Cimi> :)
[17:38] <Cimi> '44' is a static magic value
[17:39] <mzanetti> but then please add an optional parameter to the existing drag function
[17:39] <mzanetti> something like "duration"
[17:39] <mzanetti> which defaults to afap :D
[17:39] <mzanetti> as fast as possible
[17:40] <nic-doffay> Could someone who is running compiz test a branch for me?
[17:44] <Cimi> mzanetti, I tried adding a wait, how would you make it slower?
[17:44] <Cimi> mzanetti, a wait after mouseMove and before mouseRelease
[17:45] <mzanetti> Cimi: yeah... in that case you have to work with wait
[17:45] <Cimi> mzanetti, doing a for with wait?
[17:45] <mzanetti> Cimi: isn't there already a loop?
[17:45] <Cimi> mzanetti, there = where?
[17:45] <mzanetti> UnityTestCase::mouseFlick()
[17:46] <mzanetti> Cimi: yes, there is... extend that one with "wait(duration / nIterations)"
[17:46] <Cimi> ok
[17:46] <mzanetti> where duration is the new parameter you will add, defaulting to 0
[17:46] <Cimi> sure
[17:53] <Cimi> mzanetti, we have
[17:53] <Cimi>         pressMouse = ((pressMouse != null) ? pressMouse : true); // Default to true for pressMouse if not present
[17:53] <Cimi>         releaseMouse = ((releaseMouse != null) ? releaseMouse : true); // Default to true for releaseMouse if not present
[17:53] <Cimi> mzanetti, can't we do
[17:53] <Cimi> if (pressMouse [17:53] <Cimi> ?
[17:54] <mzanetti> Cimi: can't follow completely... but looks like nitpicking to me... feel free to decide yourself... and don't fix anything that isn't broken (unless it IS broken)
[17:55] <Cimi> Saviq, ^
[17:55] <Cimi> mzanetti, but we might want to fix weird code, no?
[17:56] <mzanetti> well yeah... If you're really sure it improves things and does not break them... change it
[17:56] <mzanetti> Cimi: ^
[17:57] <Cimi> mzanetti, it doesn't change, it's just more correct
[17:57] <Cimi> mzanetti, arguments not send are undefined, so you know immediately
[17:58] <mzanetti> Cimi: yeah... looks good
[18:07] <Cimi> mzanetti, ok the slow swipe works
[18:07] <mzanetti> cool
[18:12] <dandrader> mzanetti, the greeter test is failing for me http://pastebin.ubuntu.com/5628853/ should I make a bug report, fix it myself, send an e-mail to the author...
[18:12] <dandrader> what do you recommend?
[18:14] <dandrader> ah, you're the author.
[18:16] <nik90> cimi: are all these works for unity-next?
[18:17] <mzanetti> dandrader: I'll have a look
[18:45] <seb128> cyphermox, do you know how to give a retry to the unity autolanding daily job?
[18:45] <cyphermox> seb128: yep. what's up with it, do you mean because it hasn't landed in distro today?
[18:46] <seb128> cyphermox, there was some utah issues since yesterday
[18:46] <cyphermox> right
[18:46] <seb128> they apparently worked around those
[18:46] <seb128> so we could retry
[18:46] <cyphermox> sure, I'll have them re-tested
[18:46] <seb128> would be nice to give it a retry
[18:46] <seb128> thanks
[18:56] <seb128> Trevinho, good work on the unity dialog btw, and thanks for fixing those bugs ;-)
[18:57] <Trevinho> seb128: thanks
[18:57] <Trevinho> seb128: there's still the thing related to the updates, but I'm wondering if indicator-session was broken even before
[18:57] <Trevinho> (on not highlighting the item)
[18:57] <seb128> like?
[18:57] <seb128> well, it was turning red for pretty sure
[18:58] <seb128> but maybe that got broken this cycle before your work
[18:58] <seb128> I didn't see it red for a while now that you mention it
[18:59] <Trevinho> seb128: since I don't think I changed the code related to it
[18:59] <Trevinho> I only changed the callback action
[18:59] <seb128> could be a previous breakage
[18:59] <seb128> I will have a look tomorrow
[19:20] <boiko> hey guys, I have this MR renaming from telephony-app to phone-app, and it failed to land because a unit test is failing: https://code.launchpad.net/~boiko/unity/phablet-rename_phoneapp/+merge/153812
[19:21] <boiko> could anyone please take the test a look?
[19:43] <kgunn> mzanetti: you still on?
[19:44] <kgunn> ^ boiko above has jenkins failure, for tst-Qmltests error 8
[19:45] <boiko> kgunn: so, it seems the test itself failed as a signal that was expected never got emitted
[19:49] <kgunn> boiko: i'm learning too....so looks like one of the tests in the unittest dir failed
[19:49] <kgunn> (as opposed to the other directories...otherwise that statement is a little obvious :)
[19:54] <bschaefer> boiko, well whats strange is the i386 passed before, does it fail for you locally? If so, check if your branch is causing it vs trunk. (Though it looks like its a random failure)
[19:55]  * bschaefer doesn't know much about the phablet tests
[19:57] <kgunn> boiko: i just checked your MP code change as well....looks completely ok to me...strange
[20:09] <pg_pt> hi all
[20:09] <pg_pt> is this closed or not? https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259/
[20:09] <pg_pt> thank you bot
[20:13] <bschaefer> pg_pt, looks like it was approved for FFE, sooo it 'should' be getting fixed for 13.04
[20:14] <bschaefer> (approved by the release team)
[20:15] <pg_pt> does anyone know how to show the pidgin icon on system tray on multiple screens
[20:16] <pg_pt> I currently only see it in one
[20:37] <mzanetti> Saviq: did you already find out why the test was failing or just re-approved?
[20:37] <Saviq> mzanetti, it only failed on i386, reapproved to see if reproducible
[20:37] <Saviq> mzanetti, and you should not be here
[20:39] <mzanetti> Saviq: what if this is a channel where I would hang around in my spare time too?
[20:39] <Saviq> mzanetti, get a life ;D
[20:40] <Saviq> mzanetti, j/k, just don't want you to get overworked and bored/frustrated/whatever
[20:40] <Saviq> yay /we got graphs!
[20:41] <mzanetti> graphs?
[20:42] <Saviq> mzanetti, in jenkins ;)
[20:42] <Saviq> jeez we need to reduce spurious output...
[20:44] <Saviq> mzanetti, oh, we get .ogvs of the autopilot runs?
[20:45] <mzanetti> Saviq: yeah! the failed ones
[20:45] <mzanetti> Saviq: the most helpful feature in debugging them
[20:45] <Saviq> aweseme :D
[20:45] <Saviq> awesome, even
[20:45] <Saviq> that's going to grow
[20:47] <kgunn> mzanetti: Saviq awesome!!!
[20:47] <mzanetti> :)
[20:47] <Saviq> mzanetti, are they attached somewhere?
[20:47] <Saviq> I just saw the recordmydesktop call, not the file itself
[20:47] <mzanetti> Saviq: what, the videos?
[20:47] <mzanetti> ah yes
[20:47] <Saviq> mzanetti, yup
[20:47] <mzanetti> mom
[20:48] <mzanetti> kgunn: yeah. its pretty cool by now. but still a bit to go
[20:49] <Saviq> damn jenkins is crap
[20:49] <mzanetti> Saviq: just pick one of the yellow ones
[20:49] <mzanetti> Saviq: and see the archived artifacts
[20:49] <Saviq> mzanetti, yeah,
[20:50] <Saviq> mzanetti, but if you're interested in a particular job, difficult to find ;)
[20:50] <mzanetti> Saviq: I need to look into improve the output in the top-most job
[20:50] <mzanetti> if a test fails its posted in the appropriate MP. so the links is there immediately
[20:50] <om26er> mzanetti, you asked me to test if a certain service loads, so how do i check programatically if a service is started ?
[20:50] <mzanetti> but if you're just browsing the list of jobs its a bit cumbersome still
[20:52] <mzanetti> om26er: start the shell -testability and use autopilot vis to find an element that is not there when the backend is not leaded and is there when the backend is ready
[20:52] <mzanetti> om26er: then just try to access it in the test somehow.
[20:54] <bschaefer> mzanetti, Saviq IIRC you should be able to use this to fetch the videos: https://code.launchpad.net/~autopilot/+junk/apview
[20:55] <bschaefer> just out  unity-phablet-quantal-i386-autolanding in the name and load, though I think someone fixed it up in a different branch somewhere...
[20:55] <om26er> mzanetti, so i think none of those services is working on raring, i'll grab someone from chewie team to know more
[20:57] <bschaefer> yeah, sil2100 fixed it up here: https://code.launchpad.net/~sil2100/+junk/apview