[01:19] <smartboyhw> Good morning Noskcaj
[01:19] <Noskcaj> hey smartboyhw
[01:20] <Noskcaj> any progress on testdrive? your version has permanently broke any testdrive i install
[01:20] <smartboyhw> Noskcaj, no.
[01:21] <Noskcaj> :(
[01:21] <smartboyhw> And I will depart for London tmr, so don't ask me anything until 31st July.
[01:21] <Noskcaj> ok
[01:21] <Noskcaj> wait. london?
[01:21] <smartboyhw> Noskcaj, yeah.
[01:21] <smartboyhw> Study tour
[01:22] <Noskcaj> wow
[07:02] <DanChapman> Good Morning all :-)
[07:07] <smartboyhw> Hey DanChapman
[07:08] <DanChapman> smartboyhw, hey. How are you?
[07:08] <smartboyhw> DanChapman, good, packing for London
[07:10] <elfy> good day DanChapman
[07:10] <DanChapman> smartboyhw, cool, well the weather is pretty good for us at the moment. How long is the journey?
[07:10] <DanChapman> elfy hey :-)
[07:11]  * elfy can't think of a worse place ... 
[07:11] <elfy> /wore wellies so they didn't mistake me for a local
[07:11] <DanChapman> elfy I have a few autopilot tests together now for xubuntu, but wasn't sure where they are going.....
[07:12] <elfy> going?
[07:13] <DanChapman> elfy the ubuntu-autopilot-tests branch is now running on jenkins so putting xubuntu tests in there would just cause loads of failed tests. I ment to speak to balloons about it yesterday but i forgot
[07:14] <elfy> oic - no idea :)
[07:14] <DanChapman> not sure if its a good idea to create a seperate xubuntu-autopilot-tests project
[07:14] <elfy> that's probably a conversation for when more than I'm about - just about to wander off for work too
[07:16] <DanChapman> elfy no worries. I will stick what i do in a +junk branch until its decided on a plan of action when everyones about. Have fun at work :-)
[07:16] <elfy> knome: ^^ re xubuntu-autopilot-tests project
[07:16] <elfy> DanChapman: cheers :)
[07:45] <smartboyhw> Hey elfy
[07:54] <Noskcaj> smartboyhw, you just missed hum
[07:54] <Noskcaj> *him
[07:54] <smartboyhw> Noskcaj, ouch
[08:32] <knome> forestpiskie, ok, got that
[09:33] <chrisccoulson> does anyone have any idea what is going on with https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/ARCH=amd64,label=adt/83/ ?
[09:33] <chrisccoulson> jibel ^^ :)
[09:36] <jibel> chrisccoulson, this is a test timeout, now why it times out, I have no idea. I'll run the test again and log into the system
[09:36] <chrisccoulson> jibel, thanks
[12:17] <asac> gema_: ho
[12:17] <asac> gema_: do you know why "default" is not run on http://reports.qa.ubuntu.com/smokeng/saucy/image/2898/
[12:17] <asac> ?
[12:18] <gema_> asac: looking
[12:24] <asac> gema_: oh ... i think it might be dashboard screwage
[12:24] <asac> i found "default" here: http://reports.qa.ubuntu.com/smokeng/saucy/image/2871/
[12:25] <asac> e.g. ended up in the entry before
[12:25] <gema_> asac: no, I don't think so
[12:25] <asac> hmm. y0ou are right
[12:25] <asac> its the "when its run" vs. "what image it ran on"
[12:25] <gema_> those runs are for yesterday, we made two for some reason
[12:25] <asac> so that one just ran late
[12:26] <asac> yeah but if yo ulook there, the default has the time of Jul 9
[12:26] <gema_> asac: they are grouped by image they run on, not by what time they run
[12:26] <asac> right
[12:26] <gema_> if we run twice on a particular image
[12:26] <gema_> they get grouped together
[12:26] <asac> ack. makes sense
[12:26] <asac> gema_: so maybe default for todays image is still running?
[12:26] <gema_> asac: I have found results for sdk and security but not for default
[12:26] <asac> right
[12:26] <gema_> asac: I am trying to determine that in the internal instance
[12:26] <asac> kk
[12:26] <gema_> asac: but I didn't expect the other ones to run until default is successful
[12:27] <gema_> so I will talk to plars about that tomorrow (he is off today)
[12:27] <asac> sure
[12:27] <asac> gema_: here... on the autopilot stuff... is the infrastructure ready and you wait for someone giving you a list of what to run?
[12:28] <gema_> asac: not sure what autopilot stuff we are talking about , the normal test cases?
[12:28] <gema_> the integration autopilot test suite?
[12:29] <asac> autopilot tests for daily image runs
[12:29] <asac> so seems noone told you which ones
[12:29] <asac> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGR3c1NUM2RnYkNBYjVMTkMxVjFqb2c#gid=0
[12:29] <asac> related to that
[12:29] <asac> let me get the list then
[12:29] <gema_> asac: we haven't got to the autopilot ones yet, I'd like to know which ones are the right ones for us to start adding
[12:30] <gema_> asac: i.e. the most stable ones
[12:30] <asac> right
[12:30] <gema_> asac: I am going to get lost in the intranet for a bit, bb as soon as I figure out what happened to default jobs
[12:30] <asac> gema_: kk
[12:36] <gema_> asac: I am rerunning grouper, see if we get some default result for today
[12:37] <gema_> asac: it looks like the phablet tools got the wrong image for that job, but the right one for the other ones (makes no sense)
[12:37] <gema_> anyway, if that works I will rerun the others as well
[12:37] <gema_> and talk to plars about it tomorrow
[12:38] <asac> gema_: http://pad.ubuntu.com/jlIeQVyP8X
[12:38] <asac> the canonical: ones are the goal
[12:39] <asac> i would like to group them by team/unity (so we dont have so many jobs)
[12:39] <asac> e.g. one job for all applications ... one job for all shell
[12:39] <asac> one job for sdk
[12:43] <asac> gema_: maybe phablet tools does too much implicit magic and you rather want and explicit "list available images" and "download exact image by id"?
[12:44] <asac> i can imagine if you just pull "current" that there might be interesting races
[13:04] <gema_> asac: that'd be good, but since there are so many moving pieces atm, we didn't want to reinvent any wheel
[13:04] <gema_> asac: we go with the flow and test phablet tools as well
[13:13] <gema_> asac: got a result there , it should be in the dashboard soon (within an hour)
[13:13] <gema_> https://jenkins.qa.ubuntu.com/view/All/job/saucy-touch-grouper-smoke-default/33/
[13:13] <gema_> asac: I will rerun the others as well
[13:13] <gema_> asac: thanks for spotting that problem
[13:29] <gema_> asac: we have a theory, we think that the md5 file changed before the image itself in cdimage
[13:29] <gema_> asac: so our jobs started thinking that the new build was already there
[13:29] <gema_> and the default jobs installed the previous one, rather
[13:30] <gema_> asac: by the time we got to the other two, the new image was fully copied and was picked up properly
[13:30] <gema_> asac: I will discuss with plars tomorrow
[13:40] <balloons> DanChapman, elfy it's ok to push stuff to the ubuntu-autopilot-tests branch.. only the "prod" branch is being run in jenkins -- hence the reason it exists
[13:47] <smartboyhw> Good evening balloons
[13:47] <balloons> evening sm0x
[13:47] <balloons> bah.. evening smartboyhw
[13:47] <smartboyhw> balloons, :) Well, maybe you should give us a non-production Jenkins instance to test things;P
[13:48] <balloons> that's your local box eh? :-p
[13:48] <smartboyhw> balloons, whoa? No, buy one yourself:P
[14:17] <gema_> asac: results are published for the default jobs already
[14:18] <gema_> smartboyhw: if I get you a jenkins instance, how many test cases are you going to give me in return?
[14:18] <gema_> :)
[14:18] <smartboyhw> gema_, well ask elfy and DanChapman
[14:18] <gema_> smartboyhw: you asked for it, so I am asking you :P
[14:18] <smartboyhw> They are the ones who will push things to ubuntu-autopilot-tests branch, I might add few though
[14:18] <smartboyhw> Still learning
[14:18] <gema_> smartboyhw: ok
[14:19] <smartboyhw> gema_, expect that elfy and DanChapman will try to utilize Xfce autopilot testcases:)
[14:19] <smartboyhw> Which will be a lot;P
[14:20] <gema_> balloons: keep an eye on these guys and let me know whenever you think they are ready to tame a jenkins
[14:20]  * balloons is silently watching :-p
[14:20] <smartboyhw> balloons, lol
[14:23] <gema_> smartboyhw: he is watching you get caught on the spider web I am preparing :P
[14:24] <gema_> smartboyhw: having a jenkins is a daily task and it takes time
[14:24] <gema_> smartboyhw: and keeping it running happily requires a lot of dedication
[14:24] <gema_> smartboyhw: we'll start running your tests in ours
[14:24] <gema_> and eventually we may get to a point where it makes sense for you guys to have yours
[14:26] <smartboyhw> gema_, well what, I am not that sticky (at least, not to spider webs)
[14:26] <smartboyhw> gema_, it would be a great idea if we can run tests at your Jenkins instances
[14:27] <smartboyhw> That will surely encourage more people to write autopilot tests
[14:27] <jibel> smartboyhw, we already run tests from the production branch, so if tests from the dev branch are good enough they'll surely be promoted to production and run daily
[14:28] <smartboyhw> jibel, oh great
[14:28] <smartboyhw> DanChapman, chilicuil add oil on making your autopilot tests stable;P
[14:29] <chilicuil> good morning smartboyhw o/
[14:29] <smartboyhw> hey chilicuil
[14:30] <jibel> smartboyhw, https://jenkins.qa.ubuntu.com/job/autopilot-ubuntu-applications/
[14:30] <balloons> smartboyhw, as jibel said.. the biggest piece with running unstable tests is you have to spend time fixing them when they break.. we're already stepping out by maintaining the set running in the production branch :-)
[14:30] <smartboyhw> balloons, jibel sure:)
[14:37] <asac> gema_: cool. guess we dont know the reasons?
[14:38] <gema_> asac: yep, if you read the log you'll see
[15:02] <asac> gema_: what will i see from the log? that we dont know the reason?
[15:03] <gema_> asac: this channel, I told you a while ago our problem with the jenkins trigger
[15:03] <gema_> asac: that's the reason why the jobs didn't run with today's image
[15:03] <gema_> asac: not the job's log, this channel's log :)
[15:16] <DanChapman> balloons, jibel, smartboyhw  hey o/
[15:17] <smartboyhw> DanChapman, make your autopilot tests stable and get us a specific Jenkins bot!:P
[15:19] <balloons> DanChapman, hello
[15:25] <DanChapman> balloons, just seen on scrollback about putting xubuntu tests in trunk. so should i put what i have in a seperate xubuntu_autopilot_tests directory rather than sticking it in with the ubuntu_autopilot_tests and them getting 'jumbled up' so to speak
[15:26] <balloons> DanChapman, we can if we wish. I'm not opposed to a separate project eitheir persay, but as we talked about having things in one place makes it nicer..
[15:27] <balloons> we can organize things however we wish. That said, there is debian packaging in the branch that will need to be adjusted. I don't know that we'll ever publish binaries again, but we did at one point
[15:27] <balloons> so similar to manual tests, make a folder and drop them in
[15:28] <balloons> I think that makes sense if they get xubuntu specific.. but gnumeric runs on ubuntu, lubuntu, etc too.. I run it for instance on unity alot :-)
[15:28]  * smartboyhw likes gedit or nano
[15:29] <DanChapman> i was thinking rather than have it in ubuntu-autopilot-tests/ubuntu_autopilot_tests/ stick them in ubuntu-autopilot-tests/xubuntu_autopilot_tests/ then the whole suite can be run from the top dir depending on distro. But they all still stay together
[15:32] <balloons> I think that makes fine sense
[15:40] <DanChapman> balloons, cool i will do that then.
[15:41] <smartboyhw> balloons, private message?
[16:09] <knome> hey balloons
[16:13] <balloons> hey knome
[16:14] <knome> balloons, what was the reason why upgrade tests had their own product again?
[16:14] <balloons> knome, lol.. you love to ask me questions I've forgotten answers to
[16:14] <knome> sure!
[16:14] <knome> you know, somebody has to
[16:14] <knome> there needs to be challenges for you
[16:20] <balloons> knome, lol..
[16:20] <balloons> knome, "That'd be because a respin of an image shouldn't reset the upgrade
[16:20] <balloons> results. The upgrade products are typically reset all at the same time
[16:20] <balloons> whenever a massive change happens that affects upgrades."
[16:20] <knome> okay
[16:20] <balloons> I quoted Stephane's answer from last time.. and indeed he's right
[16:23] <knome> yes, and that still makes sense
[16:39] <forestpiskie> thanks balloons - read that reply :)
[16:43] <knome> balloons, stgraber: it would be nice though if the xubuntu product filter would show the xubuntu upgrade tests as well though...
[16:43] <knome> balloons, stgraber: or alternatively, if the upgrade tests had more "weight" and always sunk to the bottom
[17:26] <dkessel> good evening :)
[17:27] <DanChapman> evening dkessel
[17:31] <balloons> dkessel, :-) I was going to ping you today to see how things were going
[17:32] <dkessel> balloons, well here i am :)
[17:37] <balloons> dkessel, indeed :-) You going to make the workshop today?
[17:39]  * DanChapman having a tough day with ALL virt solutions. 
[17:42] <dkessel> balloons, that's why i am here. i am starting with http://developer.ubuntu.com/resources/tutorials/quality/how-to-write-autopilot-tests/
[17:43] <balloons> perfect
[17:43] <balloons> I'll see everyone in 20 :-)
[18:00] <balloons> alrighty, time for our automated testing workshop to begin today :-)
[18:01] <balloons> Welcome to anyone who's joined us to learn more about autopilot test writing
[18:01] <balloons> What I'd like to do is have a brief introduction, then open it for questions from anyone who wants help. If your working on something and need specific help, let's work through it together
[18:02] <balloons> if you wish, g+ hangouts are also an option if needed. So without further ado, let me introduce things
[18:02] <AlanOD> I'm just starting out, so it's all new.
[18:02] <balloons> First I'll give a little introduction on what autopilot is, and what we're doing.
[18:02] <balloons>  Autopilot itself is a functional testing tool allowing us to interact with an application the same way a user would. it can click, swipe, touch, and type in an application by simulating a user
[18:03] <balloons> This allows us to use it to pretend we're a human using the application, and thus do functional testing
[18:03] <balloons>  So, we want to bring this tool to the core apps project. The core apps are written by community developers and represent the core applications for the ubuntu touch platform.
[18:03] <balloons> Apps like the calculator, calendar, terminal, weather, and games too like sudoku :-)
[18:04] <balloons> So, in order to help contribute tests there are a couple things you'll need
[18:04] <balloons> the first is an installation of ubuntu saucy or raring. It can be in a VM or installed on physical hardware
[18:04] <balloons> the second is an understanding of autopilot, which is what we're here today to help with :-0
[18:05] <balloons> Now to get started learning about autopilot, specifically for the core apps, go through the tutorial on developer.ubuntu.com,  http://developer.ubuntu.com/resources/cookbook/mobile/how-to-write-autopilot-tests/
[18:05] <balloons> if you haven't done that yet, that's your first stop ;-)
[18:05] <balloons> it has an example application you can run and see the tests, along with an introduction to how the tests work
[18:06] <balloons> Now, anyone who has gone through the tutorial, good :-) Let's talk about writing a test for a core app now
[18:07] <balloons> I'll be talking through similar things as the tutorial here:  https://wiki.ubuntu.com/Touch/CoreApps/Testing/ContributeAutopilotTestcase
[18:07] <balloons> In a nutshell, you'll want to pick a core app and feature to write a test for
[18:08] <balloons> fortunately, there is a handy list you can see on this page: https://wiki.ubuntu.com/Touch/CoreApps/Testing
[18:08] <balloons> here's the list of open tests needed: https://bugs.launchpad.net/ubuntu-phone-coreapps/+bugs?field.tag=needs-autopilot-test
[18:08] <balloons> that includes all the core apps :-) the page itself has them broken done for you by applicatio
[18:08] <balloons> ok, so you have your feature and core app. Next, grab the source code for the core application
[18:09] <balloons> you can find handy links to the launchpad project pages where you can find the source on the core apps wiki
[18:09] <balloons> so for instance, the weather app page is here: https://wiki.ubuntu.com/Touch/CoreApps/Weather
[18:10] <balloons> clicking through the launchpad page shows me the bzr branch is :  bzr branch lp:ubuntu-weather-app
[18:11] <balloons> So, you've branched the code, you've picked a test to add. The last step is to write it
[18:11] <balloons> I approach writing the testcase by running the application and exploring the feature first
[18:12] <balloons> once your ready, go through and test the feature. Write down each action you take, in english (that is plain words, not code), and not what happens as you perform each action
[18:12] <balloons> this forms the basis of what you will do in your test, and then what you will "assert" about those actions
[18:12] <balloons> So let's quickly look at the tutorial for an example of what I mean
[18:12] <balloons> http://developer.ubuntu.com/resources/tutorials/quality/how-to-write-autopilot-tests/
[18:13] <balloons> Inside the test_clear_button function we do a simple action, namely, clicking the clear button
[18:13] <balloons> from the user perspective the expected result is to see the fields have been cleared
[18:13] <balloons> armed with this knowledge we can write the autopilot test
[18:13] <balloons> this is how it looks:
[18:14] <balloons> #click the clear button
[18:14] <balloons> self.pointing_device.click_object(clearButton)
[18:14] <balloons> #confirm fields have been wiped
[18:14] <balloons> self.assertThat(fromField.text, Eventually(Equals('0.0')))
[18:14] <balloons> self.assertThat(toField.text, Eventually(Equals('0.0')))
[18:14] <balloons> So we click the button using autopilot, then we use asserts to make sure the screen is cleared afterwards
[18:15] <balloons> that is the basics of a good autopilot test. interact with the UI to expose the feature, then issue an assert(s) to ensure the feature reacted properly
[18:15] <balloons> Ok, enough of my rambling --  Let's talk about what questions you might have and help you get contributing ;-)
[18:16] <balloons> if you have a question or want help, it's an open channel so no need to raise your hand or anything.. type away :-)
[18:16] <knome> away :-)
[18:16] <knome> (ahahahahah!)
[18:16]  * knome bows
[18:16] <balloons> knome, we both know your behind any help I can give you :-p
[18:16] <balloons> *beyond
[18:16]  * balloons hides sheepishly
[18:17] <knome> i think you missed my joke... (you said "type away :-)")
[18:17] <balloons> knome, I very much enjoyed it.. well done
[18:17] <knome> thank you sir
[18:17] <knome> (now that i have broken the ice, i'll leave the floor to more serious questions)
[18:18] <AlanOD> This seems fairly straight forward, I need to read your links prior to starting to write any tests.
[18:18] <dkessel> strange... no matter what app i run, unity always shows the "clock" app's icon... :)
[18:19] <AlanOD> Do your links cover checking test cases in?
[18:19] <balloons> AlanOD, wonderful. Feel free to go through the tutorial now if you haven't and ping me as you have questions :-)
[18:19] <balloons> AlanOD, they do cover contributing things back. The bottom of the https://wiki.ubuntu.com/Touch/CoreApps/Testing/ContributeAutopilotTestcase covers using bzr, setting up your machine, etc
[18:19] <AlanOD> I think my machine is set up correctly, but I'll confirm that.
[18:20] <balloons> Still, if you get stuck, that's what we're here for. The first time committing can feel confusing or daunting, but we'll help you through it. You learn how it works quickly :-)
[18:20] <dkessel> anyway. balloons, I am going to try and fix bug 1188736
[18:20] <balloons> dkessel, ohh excellent
[18:21] <balloons> iBelieve is the other person writing file manager testcases, so there's a nice test structure already setup in the application source :-)
[18:22] <balloons> it's much easier if your going through things for the first time
[18:24] <balloons> dkessel, and AlanOD any feedback on the tutorial on developer.ubuntu.com feel free to toss my way.
[18:24] <AlanOD> I need to leave now. I'll start working through the tutorials tonight. I should be able to start writing a few cases tomorrow.
[18:25] <AlanOD> If/when I run into questions, I reach out to you, or the community.
[18:25] <balloons> AlanOD, no worries. I hope this helps you get started. See my pm if you would so I can keep in touch with you, if that's alright
[18:25] <dkessel> balloons, is it convention to put all tests in one .py file?
[18:25] <balloons> AlanOD, yes, #ubuntu-autopilot, #ubuntu-quality and #ubuntu-touch are all good places the community hangs out. core app decs in -touch, autopilot hackers in -autopilot, and well us here in -quality :-)
[18:26] <balloons> dkessel, you can split them out or group them depending. I know clock for instance has one file for each view containing all the tests in that view
[18:26] <balloons> that seems like a nice way to split things
[18:29] <adegoodyer> Hello everyone
[18:30] <balloons> adegoodyer, hello. how's today treating you? :-)
[18:30] <adegoodyer> balloons, Good as always, the sun is out and life is well! How about yourself?
[18:31] <balloons> much better today than last week.. The last couple weeks were crazy.. Now life is good again.. time to breathe and enjoy. And see some new tests get written and sharing the joys of automated testing.. It's good
[18:32] <xeranas> hi, I wonder which best way to debug autopilot tests/emulators?
[18:33] <adegoodyer> balloons, That's great to hear! Yes, we all like to be busy but not TOO busy - that's just no fun at all. Still could be worse :oP
[18:33] <balloons> xeranas, hello.. Always such good questions!
[18:33] <balloons> adegoodyer, indeed, it could ALWAYS be worse.. perspective eh?
[18:34] <adegoodyer> balloons, thats
[18:34] <adegoodyer> .. it, all in the perspective lol
[18:35] <adegoodyer> Right, I have decided I am not leaving this desk until I write an autopilot test this evening! I have chose bug #1199112 as my first... so wish me luck!
[18:35] <balloons> xeranas, so I don't use  a step through debugger or anything like that when I'm trying to figure out how to write or run a test. I will use the autopilot vis tool to examine the application and then just run my test to see if something is broken
[18:35] <balloons> xeranas, that said you can use dbus tools to examine the dbus stack if you think something is really broken.. say like d-feet
[18:35] <balloons> xeranas, does that answer your question or ?
[18:36] <balloons> adegoodyer, :-) That's the ticket! I'll be share to share it when you do as well! I'm going to highlight that app on friday, and you can be a part of the highlight ;-)
[18:37] <balloons> sure to share, not share to share
[18:37] <balloons> my typing is so bad recently
[18:38] <adegoodyer> balloons, Oh no don't say that! ... No pressure!! :-O
[18:38] <xeranas> balloons: what is autopilot vis tool?
[18:38] <balloons> adegoodyer, no no no.. of course not! The post is written, it would be more work for me to edit it now :-P
[18:38] <balloons> xeranas, ohh excellent. Let me share with you the tool and how it works
[18:39] <adegoodyer> balloons, Haha, that's good to hear... of course if my test is simply mind blowing then feel free to use... but I doubt that it will be very much lol
[18:40] <balloons> xeranas, so, lets say I wanted to see what the sudoku app made available to autopilot at runtime
[18:41] <balloons> I would do this: autopilot launch -i Qt sudoku-app
[18:41] <balloons> then, autopilot vis
[18:42] <balloons> after the vis tool laucnhes, select the QtQmlViewer connection from the dropdown and you'll be seeing what autopilot sees
[18:42] <balloons> would it help for me to show you via video?
[18:42] <adegoodyer> balloons, What does the -i parameter in the autopilot command do?
[18:43] <balloons> -i tells autopilot what introspection library to load. It tries to guess automatically and usually gets it just right so it's not needed
[18:43] <balloons> I like to be specific, lol, so I sometimes define it
[18:43] <adegoodyer> Ah, I am with you then... so Qt is the library right??
[18:43] <balloons> yes, exactly
[18:44] <balloons> you could also do -i Gtk
[18:44] <adegoodyer> balloons, cool, that's simple but really good to know
[18:44] <balloons> and you may not no if the app is Qt or Gtk.. hence it's not needed to use autopilot, but handy in case you need to help autopilot figure it out :-)
[18:44] <xeranas> balloons: yea video will be fine too. Maybe I do something wrong but in tool dropdown only Unity exist
[18:45] <balloons> xeranas, alright, let me try streaming quickly and I'll show you :-)
[18:47] <balloons> xeranas, so in just a moment, I'll be up here: http://youtu.be/lTBNOkrzEC4
[18:49] <balloons> ok you should see me now :-)
[18:49] <adegoodyer> So cool ^^ :-)
[18:50] <adegoodyer> Guess who was trying to test using the old version of autopilot... doh!
[18:53] <adegoodyer> balloons, My apoligies, what's the command to launch sudoku-app in QML viewer again?
[18:54] <adegoodyer> balloons, in autopilot of course..
[18:55] <adegoodyer> balloons, thank you! :o)
[18:56] <xeranas> this tool is so time saver!
[18:57] <xeranas> balloons: thanks for showing
[18:57] <dkessel> dang
[18:57] <dkessel> somebody already did my test
[18:58] <dkessel> but named it "test_file_actions_shows"... while it shows the directory context menu
[18:58] <adegoodyer> xeranas, I attempted autopilot tests a while ago without the 'vis' tool and it was absolutely impossible.
[18:58] <dkessel> hm. they seem identical anyway
[18:58] <adegoodyer> dkessel, if there identical then you definitely are on the right track at least :o)
[19:00] <balloons> did that help?
[19:00] <balloons> the plugin crash so the stream ended, lol
[19:01] <adegoodyer> balloons, Yes definitely helped me. It's the silly small things that take time sorting out so when  you watch someone else breeze through, you learn a lot quicker.
[19:03] <balloons> cool..  I can share more if you have more questions :-)
[19:04] <balloons> dkessel, ahh.. sorry mate!
[19:04] <balloons> but yes, if they are identical, well you've done well in writing it!
[19:04] <balloons> was the bug not updated to say it was done?
[19:05] <balloons> we should do that if so :)
[19:05] <dkessel> balloons, now anyway... i have written a test that also tests for the context menu on files....
[19:05] <balloons> ohh nice.. I was just playing with the file manager app today
[19:05] <balloons> it's come along quite far
[19:05] <dkessel> i guess there must have been a bug for the context menu on files... for which the author built a test for the context menu on FOLDERS
[19:06] <dkessel> now i have written the one for the file and renamed the old test
[19:06] <dkessel> hm, i get an error when trying to list the tests... let me paste it
[19:06] <balloons> ahh that makes sense.. the functionality might not have been implemented
[19:07] <dkessel> what am i doing wrong here? http://paste.ubuntu.com/5859314/
[19:08] <dkessel> ah, the test has a dependency on the mock module.... meh
[19:10] <balloons> heh.. I was just going to mention that
[19:10] <balloons> python import yelling at you
[19:10] <adegoodyer> balloons, Before writing a test, would you recommend running apt-get update to update the apps? Is this the best way to keep them updated??
[19:11] <balloons> adegoodyer, since you messing with the code directly, I would run them from the branch you've checked out and are messing with
[19:11] <dkessel> balloons, how do i know that module is available when the test is run i.e. on jenkins?
[19:11] <adegoodyer> balloons, Yep, cool
[19:11] <balloons> you might have modifications to the qml files for instance adegoodyer
[19:12] <balloons> dkessel, fginther has been adding modules as needed to run on jenkins, and yes we've already had some surprises
[19:12] <balloons> ideally packaging and adding dependencies in debian control file is the right way to go
[19:13] <balloons> for now, we just work through it dkessel
[19:15] <balloons> Letozaf_, are you still about/
[19:16] <fginther> dkessel, jenkins builds in a very minimal chroot environment, so any missing build dependencies should be discovered during build. Test dependencies are a little harder as the autopilot environment is not quite as minimal. So if a test has a package dependency, it should be in the control file, catching these is a little difficult.
[19:17] <fginther> dkessel, ideally we don't want to add packages to the build environment, we want the packages themselves to pull them in.
[19:18] <dkessel> fginther, that's what I guessed you would want. Thanks for clarifying
[19:18] <fginther> dkessel, you're welcome
[19:19] <balloons> fginther, since I've called you in as well, should the missing dependency for rssreader be fixed?
[19:20] <fginther> balloons, are you referring to this? https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/ubuntu-rssreader-test-add-view-feeds/+merge/173316
[19:22] <fginther> balloons, If so, I did add the missing ubuntu-sdk-team/ppa, but ran into different errors.
[19:22]  * fginther needs to clone self
[19:23] <balloons> fginther, indeed I am
[19:24] <dkessel> balloons, I am done. I have run the test to check that it works, and I have pushed into a lp branch. Is there anything else to do before suggesting a merge?
[19:24] <balloons> dkessel, that should be it. Propose the merge and the devs will review.. since I'm here and your proposing I can just review :-0
[19:25] <balloons> once approved jenkins will try running it and if all the existing tests pass, aka, you didn't break anything jenkins will merge it
[19:25] <balloons> so issue an MP, I'll have a look and we'll see if we can't get it merged :-0
[19:26] <dkessel> done :)
[19:26] <Letozaf_> balloons, sorry was away for a while :)
[19:26] <Letozaf_> balloons, I'm back
[19:26] <dkessel> balloons, https://code.launchpad.net/~d-kessel/ubuntu-autopilot-tests/test_opening_context_menu_on_directory
[19:26] <fginther> balloons, Letozaf_, I'm taking another look at https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/ubuntu-rssreader-test-add-view-feeds/+merge/173316
[19:27] <Letozaf_> fginther, thank you :)
[19:27] <balloons> Letozaf_,  no worries, see fginther response above. basically I tried again to merge things, but yea, still working on it ;-)
[19:27] <Letozaf_> thank you to both :) then
[19:27] <balloons> Letozaf_, are you working on more tests then now?
[19:27] <Letozaf_> balloons, I am looking at the stock ticker
[19:27] <Letozaf_> balloons, app
[19:28] <balloons> dkessel, I'm on it! Ohh one thing.. Unlike the desktop apps, we push these tests directly into there source trees and not the autopilot project
[19:28] <balloons> so you should push that merge to lp:ubuntu-filemanager-app
[19:33] <adegoodyer> balloons, Disaster! All the object names in dropping-letters are black according to vis??
[19:33] <adegoodyer> *blank even
[19:33] <dkessel> balloons, i fixed the target branch
[19:33] <balloons> adegoodyer, let's rollback a moment so I understand :-)
[19:33] <balloons> dkessel, :-)
[19:34] <adegoodyer> balloons, My apologies! I have chosen the 'test to start game' testcase for the dropping letters game...
[19:34] <balloons> adegoodyer, right, so you've figured out how to click the start button eh?
[19:35] <balloons> but you want to assert the screen is cleared of letters new and the score reset or ?
[19:35] <adegoodyer> balloons, Well not exactly, I don;t seem to be able to refer to the play button directly as when I introspect with vis, all the objectName values are blank?
[19:35] <balloons> I guess the english version first is good :-)
[19:35] <balloons> adegoodyer, ohh, heh.. ok,
[19:36] <balloons> let me try launching vis and seeing what you see
[19:36] <adegoodyer> balloons, ok
[19:36] <adegoodyer> balloons, You ok with the command? :oP
[19:37] <balloons> :-
[19:38] <balloons> dkessel, I forgot the file manager app kind of dislikes me
[19:39] <balloons> adegoodyer, ok all loaded up
[19:39] <balloons> ahh so I understand now what your saying :-)
[19:39] <balloons> you get to define the objectName in the qml yourself
[19:39] <adegoodyer> balloons, You see?
[19:39] <balloons> so literally whatever object you want, go add a name for it so you can select it during runtime :-)
[19:40] <adegoodyer> balloons, Oh, how do I do that? Sound cool
[19:40] <balloons> so yes, we get to edit the qml to add that property as needed :-)
[19:40] <balloons> right so dropping letters has only 1 qml file I think
[19:40] <balloons> let's see
[19:41] <balloons> yep
[19:41] <balloons> dropping-letters.qml
[19:41] <adegoodyer> balloons, That's right
[19:41] <balloons> open it up and have a look.. go ahead an add the objectName property to anything you want to get at :-)
[19:42] <adegoodyer> balloons, So it's ok to edit the actual qml file to get the relevant objectNames and then update this upon committing?
[19:42] <balloons> dkessel, so let me set it to approved and jenkins should merge it
[19:42] <balloons> I see some toolbar buttons for new game
[19:43] <dkessel> balloons, thanks :)
[19:43] <balloons> your most welcome :-) so, you have background on gtk vs qml.. what are your thoughts comparing the 2?
[19:44] <balloons> adegoodyer, so I would make names for the play button and the newgame button
[19:45] <balloons> then you'll need to figure out how to assert properly that the screen clears and game resets when you click it
[19:45] <adegoodyer> balloons, Yep am totally on it now, for some reason I didn't think we could edit the source like that
[19:45] <balloons> so there is a Timer you see in the qml with a tickCount that gets reset.. add an object name to it too
[19:45] <balloons> adegoodyer, if you don't specify the way it works is it's given a random name at runtime
[19:45] <balloons> which doesn't help us :-)
[19:46] <adegoodyer> balloons, Ah, didn;t realise that at all, which is also helpful. C'mon developers - it's only one line of code for each object and would sure help us folks out :oP
[19:48] <balloons> dkessel, jenkins bot slapped you :-) https://code.launchpad.net/~d-kessel/ubuntu-filemanager-app/test_opening_context_menu_on_directory/+merge/173802
[19:48] <adegoodyer> balloons, Can we not introsospect using id??
[19:48] <balloons> pretty cool though eh? you can thank fginther and team for putting it together..
[19:49] <balloons> adegoodyer, sadly afaik no.. I'm not a qml guru, so I'm unsure why the distinction between the too, but ;-)
[19:49] <dkessel> balloons, funny how it requires input into a field that is marked as optional on the website...
[19:51] <balloons> hmm indeed, that is odd.. seeing as the site too says it should be used for merging
[19:51] <balloons> why the (optional)?
[19:52] <balloons> I suppose to not force things upon anyone.. it *should* be used
[19:53] <fginther> dkessel, balloons, launchpad allows for a more flexible workflow. When we started building the jenkins environemnt, we wanted a distinction between the commit message and the description. So we can enforce this in the jenkins tools, but we can't change launchpad.
[19:54] <dkessel> fginther, and what i just did is that i enterend the exact same text into both fields ;)
[19:55] <fginther> dkessel, yeah, that's usually how it goes. Some people like to put testing notes or other info in the description. So it's not always the same...
[19:55] <fginther> but we all use the tools differently
[20:06] <dkessel> fginther, will the lp bug be closed automatically once a new package with my changes is released?
[20:07] <fginther> dkessel, I think it will be marked as 'fix committed'
[20:08] <balloons> yes it will mark as fix committed
[20:08] <fginther> dkessel, correction. It is marked 'fix committed' when the merge proposal is merged in. I also think that it will go to 'fix-released' when the package is released to distro.
[20:09] <fginther> balloons, can you correct me on that ^^
[20:09] <balloons> fginther, you've got it correct
[20:09] <balloons> for these apps, I don't think you'll ever see the fix-released because they are going into the ppa :-)
[20:10] <dkessel> boo ;)
[20:10] <balloons> :-p\
[20:12] <thomi> morning
[20:12] <balloons> aloha thomi
[20:43] <SergioMeneses> hi guys!
[20:43] <SergioMeneses> balloons, take a look when you have time enough https://code.launchpad.net/~sergiomeneses/ubuntu-manual-tests/ubuntu-manual-tests/+merge/173811
[20:43] <balloons> SergioMeneses, sure thing. I owe Noskcaj merged too :-)
[20:44] <balloons> I'll do a big ball of them tonight :-)
[20:44] <SergioMeneses> balloons, it is a big testcase, maybe 2 reviews will be necessary
[20:44] <SergioMeneses> balloons, perfect
[20:45] <Noskcaj> SergioMeneses, i'll have a look at it, first issue is the line "<dd>you should be redirect to the manual page in your browser <a href="http://apps.ubuntu.com/cat/tos/">http://apps.ubuntu.com/cat/tos/</a>, do you?</dd>"
[20:46] <SergioMeneses> Noskcaj, lol
[20:46] <SergioMeneses> the wrong file
[20:47] <SergioMeneses> Noskcaj, but is ok... try to check the rest
[20:47] <Noskcaj> ok
[20:47] <SergioMeneses> I didnt include the link in the final test
[20:47]  * SergioMeneses looking for it
[20:47] <Noskcaj> it's part of the diff for some reason
[20:49] <SergioMeneses> Noskcaj, because I merged the wrong file jeje
[20:49] <SergioMeneses> that's the reason :)
[20:49] <Noskcaj> lol
[20:49] <SergioMeneses> but it doesnt matter, please check ( and balloons ) the rest of the test
[20:49] <SergioMeneses> Noskcaj, that link was just a copy
[20:50] <Noskcaj> ok
[20:55] <Noskcaj> SergioMeneses, one thing to remember when writing testcases: use a spellchecker
[20:56] <Noskcaj> also, your <dd> and <dt> are done all wrong
[21:00] <SergioMeneses> Noskcaj, what happen with dd and dt? I've changed them
[21:00] <SergioMeneses> ?
[21:00] <Noskcaj> don't write them as <dd>does this happen?</dd> write them as <dd>This happens</dd>
[21:01] <SergioMeneses> Noskcaj, ok got it
[21:02] <Noskcaj> i also saw a few instruction in <dd> tags
[21:08] <dkessel> balloons, I got to go. I'm glad I could contribute something. Will try to do more stuff next week ;)
[21:08] <balloons> dkessel, thanks for hanging out and contributing ;-)
[21:09] <balloons> i'm sure we'll see more
[21:09] <balloons> adegoodyer, btw, how are you coming along?
[21:11] <adegoodyer> Got sidetracked a little and it's getting late here so I think i'll probably finish up early tomorrow whilst waiting for the Dev app hack day to start.
[21:11] <adegoodyer> Thank you very much for the tips and advice though, help me no end! :o)
[21:12] <balloons> adegoodyer, ;-)
[21:19] <kanliot> how do i see if MIR is running?
[21:20] <adegoodyer> kanliot, Good question? Plymouth crashed when I booted which told me it was probably running :o)
[21:21] <kanliot> i had good results, except for ubiqutiy in the daily for lubuntu desktop 64bit
[21:26] <adegoodyer> kanliot, apart from that issue I have to say I saw no real difference, which of course is a very good thing
[21:46] <SergioMeneses> Noskcaj, I'll upload the new test, thanks for your time :)
[21:47] <Noskcaj> no problem