[03:56] <pitti> Good morning
[06:47] <jibel> Good morning
[06:48] <DanChapman> Good Morning all
[06:55] <elfy> morning jibel DanChapman
[06:55] <DanChapman> elfy, o/
[06:57] <smartboyhw> Hello DanChapman, elfy
[07:05] <jibel> Good morning elfy
[07:05] <jibel> Good morning DanChapman
[07:47] <pitti> jibel: while travelling on the weekend, and now I'm working on autopkgtest
[07:48] <pitti> jibel: I trimmed the output format, added realtime watching of the tests, added a test suite, etc.; is there anything which you want me to look at while I'm at it?
[07:48] <pitti> jibel: or adding tests for stuff that you often see fail?
[07:51] <jibel> pitti, not really. We've got bug 1227610 with upstart tests but it is not reproducible. This is annoying because it happens after the timeout has been reset, so autopkgtest never times out. But it happens rarely.
[07:52] <jibel> pitti, and also the behaviour with an empty Depends field is undefined, currently adt-run fails. This is a common mistake, do you think it should fail with a clear message, or expand dependencies like @ or not install any depends at all?
[07:53] <jibel> pitti, on my side, I'm adding support for private PPAs to auto-package-testing
[07:53] <pitti> jibel: I think it shouldn't install any depends at all
[07:53] <pitti> jibel: good point, I'll add a test for that and fix this
[07:53] <jibel> pitti, +1, that's what I think too
[07:54] <pitti> jibel: I'd also like to add a test for the mode that we call adt-run with, in particular with a permament output directory; what do we use for that again?
[07:55] <pitti> jibel: --output-dir?
[07:56] <jibel> pitti, --output-dir and --tmp-dir
[07:57] <pitti> jibel: oh, why --tmp-dir?
[07:57] <jibel> pitti, to collect all the artifacts generated by adt
[07:58] <jibel> pitti, oh, talking about tmp-dir, we should probably add a safeguard, if you run with --tmp-dir=/ (which can happen if a variable is undefined in shell) then it deletes /
[07:58] <pitti> jibel: hmm, wouldn't that be --tmpdir= then?
[07:58] <pitti> that just ought to fail with "missing argument" indeed
[08:14] <pitti> jibel: oh, and --output-dir alone doesn't even seem to work
[08:15] <jibel> pitti, yes, I don't remember exactly why I had to use tmp-dir instead originally
[08:16] <jibel> pitti, I fixed the missing distro-info in the testbed, a dependency has changed at some point and it is not installed by default
[10:01] <davmor2_> Morning all
[10:04] <slickymaster> good morning all
[10:45] <rvr> pitti: ping
[10:46] <pitti> please don't ping, just ask :)
[10:46] <pitti> hey rvr
[10:47] <rvr> pitti: So, maybe dumb question, but, the dependency for Unity in the phone is unity8-autopilot? (re: python-gi dependency)
[10:47] <pitti> rvr: not sure what you mean with "dependency for Unity", but if you want to run the unity8-autopilot tests you need to install that, yes; and that ought to pull in python-gi
[10:49] <rvr> pitti: Well, so unity-webapps-qml  autopilot tests were programmed for the desktop and needs to run on the phone
[10:49] <rvr> in the desktop, it imports unity-autopilot emulators
[10:49] <rvr> in the phone, must import unity8-autopilot?
[10:54] <pitti> rvr: depends, unity and unity8 are completely different codebases
[10:55] <pitti> rvr: but unity (7) certainly doesn't run on the phone, so I guess you want unity8
[10:56] <rvr> pitti: Right, should be obvious ...
[13:19] <cgoldberg> thomi, hi.. you back in NZ??
[13:36] <cgoldberg> pitti, thomi.. hey.  I'm setting up an autopilot dev environment on a new machine.  I'm documenting the steps so I can add to the docs at /autopilot/faq/contribute.rst   ... question...
[13:37] <pitti> cgoldberg: what  is there to be done other than calling bin/autopilot and setting PYTHONPATH in the source tree?
[13:37] <pitti> that's what I do, seems to work quite well
[13:37] <cgoldberg> pitti, dependencies
[13:37] <cgoldberg> sudo mk-build-deps -i
[13:37] <cgoldberg> but that doesn;t get everything you need to run the functional self tests
[13:38] <pitti> that should be the dependencies of python-autopilot-tests, indeed
[13:38] <cgoldberg> so basically I mk-build-deps.... then run tests.. then install every paxckage it complains about missing
[13:39] <cgoldberg> would be nice to have that documented or scripted
[13:40] <cgoldberg> pitti, so my question is.. is there a way to setup the selftest dependencies automagically?  or should I just list them in the doc?
[13:40] <pitti> cgoldberg: TBH I'd just apt-get install python-autopilot-tests, that will give them all and we wouldn't need to duplicate them
[13:40] <pitti> (in documentation)
[13:41] <cgoldberg> ahh.. didn't know such existed... so does python-autopilot-tests give you everything (recordmydesktop, python-junit, etc)?
[13:41] <pitti> yes, it should; if not, it's a bug
[13:42] <cgoldberg> pitti, perfect.. then that's what I'm looking for
[13:42] <cgoldberg> i'll make the docs clear
[13:42] <pitti> and if there will be new ones, you'll automatically get them on upgrade
[13:44] <cgoldberg> pitti, hmm... does python-autopilot-tests also give you all build-deps?  ... is there a need to run mk-build-deps?
[13:45] <pitti> no, not the build deps
[13:45] <cgoldberg> k
[13:45] <pitti> cgoldberg: are there any extra ones?
[13:45] <pitti> liblttng-ust-dev probably
[13:45] <cgoldberg> extra what?
[13:46] <pitti> cgoldberg: build deps which are not already deps of p-a or p-a-tests
[13:46] <cgoldberg> not sure.. im verifying p-a-tests now that I know it exists :P
[13:47] <cgoldberg> pitti, also.. should python-tox be part of p-a-tests?
[13:48] <pitti> cgoldberg: I don't think so; the tests don't call tox, nor do you need it
[13:49] <cgoldberg> ok.  I will just document it's use a s a convenience in the docs
[13:51] <cgoldberg> pitti, btw... the way autopilot doesn't show any progress during tests is killing me :)  I need to get it to stream results.. it would be sooo much better (IMHO)
[13:51] <pitti> cgoldberg: something like -⅓v ? :-)
[13:52] <pitti> -v is rather verbose
[13:52] <pitti> cgoldberg: yeah, it takes a while, and during that time your computer is pretty much blocked
[13:53] <pitti> cgoldberg: we actually created autopilot-sandbox-run to run the autopilot tests for some app in xvfb/dbus-launch, so that it doesn't block your computer
[13:53] <pitti> cgoldberg: that reminds me that we haven't actually tried running autopilot's own tests in autopilot-sandbox-run
[13:53] <pitti> if that works, it would already improve the situation quite a bit
[13:53] <cgoldberg> pitti, right.. i just want progress... normal mode should be test case name..... then pass/fail and exceptions on failures
[13:54] <pitti> cgoldberg: but then again, if you work on something particular, you'd usually only run a single test case/suite, which is much quicker
[13:54] <pitti> cgoldberg: right, I'd like that too
[13:55] <cgoldberg> pitti, i was going to add a TextTestRunner from unittest.. but thomi sai it might not play nice with verbose output.  any idea why?   I think I can make it work fine and give us much better output
[13:55] <balloons> DanChapman, I think you've made all the changes I asked about in https://code.launchpad.net/~dpniel/autopilot-gtk/autopilotgtkemulators/+merge/185786 ;-)
[13:56] <pitti> cgoldberg: i guess he meant that you shouldn't mix -v with the TestTextRunner, but I don't see why the latter wouldn't work without -v
[13:56] <pitti> cgoldberg: (yay for triple negatives!)
[13:56] <cgoldberg> pitti, i'm gonna spend a few mins working on it... i think it will make it a much better experience for test running
[13:57] <pitti> jibel: landed new autopkgtest FYI; just in case something blows up
[13:57] <pitti> jibel: we should now be able to see the realtime test output in the jenkins console, which might be interesting for stuff that takes long (to see whther it hangs)
[13:59] <jibel> pitti, \o/
[13:59] <pitti> does anyone know how to run app autopilot tests on the phone?
[13:59] <pitti> e. g. gallery-app-autopilot isn't installed by default; i tried apt-get download gallery-app-autopilot, and running out of lp:gallery-app
[14:00] <pitti> but in all those cases it just breaks on Command '['which', '../../src/gallery-app']' returned non-zero exit status 1
[14:00] <pitti> this might need a built source tree?
[14:01] <jibel> pitti, apt-get install gallery-app-autopilot then "autopilot run gallery_app" as user phablet
[14:01] <pitti> jibel: our CI machiner actually does that?
[14:01] <jibel> that's not from a source tree though
[14:01] <pitti> I had assumed it was using the readonly images
[14:01] <jibel> pitti, tha's how the daily release does
[14:01] <jibel> that's
[14:02] <pitti> ok, I'll try that, and to install build deps and run from a built tree
[14:02] <pitti> I do this to learn how existing tests works, before I start creating new ones
[14:11] <pitti> meh, you can't even install half of the build deps of dialer-apps
[14:11] <pitti> seems I need to go back to the cdimage images
[14:21] <elopio> good morning!
[14:27] <balloons> morning elopio :-)
[14:27] <smartboyhw> Hey balloons
[14:29] <balloons> hey smartboyhw
[14:34] <elopio> hey balloons. Want to review this one? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/toogles_emulator/+merge/186922
[14:34] <balloons> elopio, ohh nice.. toggles :-)
[14:38] <balloons> so smartboyhw how's things?
[14:38] <balloons> getting some kubuntu stuff going?
[14:38] <elfy> afternoon balloons
[14:39] <smartboyhw> balloons, great
[14:39] <DanChapman> balloons: Hey :-) How are you? Yeah i made the changes you mentioned and all tests are still passing, so all good just waiting on the other reviews now :-)
[14:45] <balloons> afternoon elfy
[16:05] <jfunk> ping elopio
[16:06] <elopio> jfunk: pong.
[16:06] <jfunk> elopio, PM
[16:53] <elopio> iahmad: can you please review this one? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/toogles_emulator/+merge/186922
[17:08] <iahmad> elopio, ok
[17:10] <iahmad> elopio, meanwhile would you please do the same as I fixed your comments https://code.launchpad.net/~iahmad/ubuntu-ui-toolkit/textfield_tests/+merge/186737
[17:10] <elopio> iahmad: of course.
[17:11] <elopio> iahmad: a comment for the future, we discussed about removing self.getObject
[17:12] <iahmad> elopio, replacing with what?
[17:13] <elopio> instead of that, I think it's better to call self.app.select_single(ObjectType, objectName='object_name')
[17:13] <elopio> a lot more verbose, but makes it clearer what you are selecting. A little more future proof too.
[17:14] <slickymaster> \quit
[17:14] <iahmad> elopio, ok
[17:16] <elopio> iahmad: about your test_textfield_numbers, I would split it in two. Using test scenarios it would be a lot nicer, IMO. But I'm not sure if that's something you plan to do on the future branch that you mentioned on the reply to my comment.
[17:17] <elopio> it would be nice to have an EnterNumbersTestCase, with some scenarios with parameters like input and expected_output.
[17:18] <elopio> input '123' -> expected_output '123', input '12.3' -> expected output '123', input '-123' -> expected output '123'.
[17:19] <iahmad> elopio, there are lot more test cases in my mind for input fields but I am at the moment just trying to do some smoke testing and cover as many features as possible in short time. otherwise all Boundary and Equavalence partitions test cases would have added.
[17:21] <elopio> iahmad: yes, that's what I thought. Just sayin' :) I left my approval on your branch.
[17:22] <elopio> iahmad: I was thinking of writing the textfields emulators next. Does that interfere with the things you are doing, or should I proceed?
[17:22] <iahmad> elopio, all suggestions are welcome ... thanks...:)
[17:22] <iahmad> elopio, go ahead, I think it should be fine
[17:34] <jfunk> elopio, are you able to see the "More Suggestions" in the applications scope on current?
[17:35] <elopio> jfunk: I am. Try performing a search.
[17:42] <elopio> jfunk: I suspect you are seeing bug #1225388.
[17:44] <jfunk> elopio, tx