[00:03] <Noskcaj> phillw, for my classroom session, i would assume it's best practice to link the wiki page and my previous session then ask for questions or should i try and run through what to do like i did last time
[00:03] <Noskcaj> and i need someone to get the screenshots
[00:07] <phillw> Noskcaj: I used a lot of one of my previous sessions in the intro to bugs, updated with some stuff I'd learned since. As you'd lost your notes just before your session, use the last one as a template and ensure it is up to date and includes any questions you were asked then and have seen asked since.
[00:08] <Noskcaj> ok. now if only howard had time to code and the two testdrive devs would run a hackfest...
[00:08] <phillw> people can read faster than we can type, so having it all prepped up and just copying the lines in from a pre-prepared document is fine.
[00:09] <Noskcaj> ok
[00:10] <phillw> well, you have the newer Vbox available, along with various other bug-fixes.
[00:14] <phillw> catch you later, I'm tired this morning! (01:13 AM)
[04:59] <pitti> Good morning
[08:27] <pitti> balloons: are you aware of any autopilot-gtk issues which block test case writing or make it unnecessarily hard, but haven't been reported at https://bugs.launchpad.net/autopilot-gtk/+bugs ?
[08:36] <smartboyhw> Hey Noskcaj
[08:36] <Noskcaj> good evening smartboyhw
[08:37] <pitti> smartboyhw, Noskcaj: hey -- I seem to remember that one of you talked to me about autopilot-gtk the other day?
[08:37] <Noskcaj> wouldn't have been me. I'm terrible at coding
[08:38] <smartboyhw> pitti, maybe me, but I thought I contacted popey and balloons instead.
[08:38] <pitti> smartboyhw: ah, ok; I'm mostly interested in what I asked a handful of lines up about ap-gtk blockers
[08:38] <pitti> I'm currently triaging bugs, and starting to fix some
[08:39] <pitti> and I now have a testsuite to reproduce bugs, etc.
[08:39] <popey> news to me
[08:39] <smartboyhw> pitti, but I'm sure I'm not talking about autopilot-gtk, I am focusing on autopilot-qml...
[08:39] <pitti> smartboyhw: ah, ok; nevermind then
[08:40]  * Noskcaj resumes applying $100 worth of fabric to his computer
[08:49] <smartboyhw> Noskcaj, heh
[08:50] <Noskcaj> i'd explain, but people would get angry
[09:30] <smartboyhw> Noskcaj, ?
[09:36] <Noskcaj>  i'm sleeving all the cable sin my power supply.
[10:01] <smartboyhw> I think chilicuil has to update his slides, it still has #ubuntu-testing :O
[10:48] <DanChapman> Good Morning :-)
[12:17] <jibel> pitti, in a container dev/uinput is not created by udev, should I do it manually or is there a better way?
[12:21] <pitti> jibel: hm, TBH I don't know what creates it in the first place; I guess some kernel driver, but its properties don't really tell which
[12:21] <pitti> jibel: mknod ought to work for now, indeed
[12:25] <jibel> pitti, okay, that's the workaround I used. The second problem is that python-autopilot changes ownership and mode of this device with another udev rule which is not executed either. I changed it in the test setup for now.
[12:25] <jibel> pitti, thanks
[12:26] <pitti> jibel: oh, it might actually be /lib/udev/rules.d/61-autopilot-uinput.rules which creates this
[12:26] <pitti> jibel: that one is invalid, NAME="..." hasn't been supported in ages
[12:27] <pitti> ah no, it doesn't create it
[12:27] <jibel> this rule just changes group and mode isn't it?
[12:28] <pitti> yes
[12:56] <smartboyhw> popey, balloons I want to call off the autopilot tutorial session till one week later. Next Tuesday, same time, is that OK?
[12:56] <DanChapman> hey smartboyhw, how's it going?
[12:57] <smartboyhw> DanChapman, hey
[12:57] <DanChapman> so your gonna get into some autopilot smartboyhw
[12:57] <smartboyhw> DanChapman, yes.
[12:57] <DanChapman> nice one :-)
[13:19] <asac> gema: doanac: pgraner: so can you confirm that the test suites we have been given will be added to daily phablet tests this week?
[13:20] <asac> plars: ^^
[13:22] <gema> asac: do you mean the qrt tests?
[13:23] <asac> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGR3c1NUM2RnYkNBYjVMTkMxVjFqb2c#gid=0
[13:23] <asac> gema: ^^
[13:24] <gema> asac: you and pgraner agreed that we would be adding the three test cases from the qrt one (security) and we are also adding whilst at it the one test case in the sdk one, yes
[13:24] <gema> asac: with the big warning that they are not testing much
[13:24] <asac> gema: thast ok
[13:24] <asac> :)
[13:24] <asac> gema: just add them ... and would like QA team then to report about how crappy our tests are :)
[13:24] <asac> and yes, i know they dont test much, but its the first step :)
[13:24] <gema> asac: they are not testing much, do you want me to raise a bug?
[13:24] <gema> :)
[13:25] <asac> gema: i dont read bugs. I think the most effective way would be to send a newsletter or something about "mohthly review of daily team tests suites"
[13:25] <gema> asac: go back to holidays, things will be up and running when you are back, I will point you to the tests for you to be able to identify them
[13:25] <gema> asac: as soon as they are there
[13:25] <asac> gema: ok ... this week :)
[13:25] <gema> yep
[13:25] <asac> awesome
[13:26] <gema> asac: np!
[13:26] <asac> gema: oh ... so one line in the dashboard for each line in the spreadsheet is what we want :)
[13:26] <asac> but guess that wasnt clear
[13:26] <gema> asac: if you are going to control QA, you are going to have to start reading bugs
[13:26] <gema> asac: we will link them in the dashboard so taht it is easy to keep track of them
[13:26] <asac> gema: oh ... tvoss promissed to give us the platform api and the mir testsuite as well.. so pull from him
[13:27] <gema> asac: ok, will query those
[13:27] <asac> gema: ok... thats fine. as i said i am happy to monitor for test errors :)
[13:27] <asac> and do the dispatching...
[13:27] <asac> if you feel the ttestsuites have a general bug feel free to link them there as well ... i will see them
[13:27] <gema> asac: yep, the thing is, we work with bugs, developers fix bugs and that's how we track problems to completion
[13:27] <gema> so you tell me what's the best way for you to be able to deal with them
[13:28] <gema> asac: but I think the dash makes it easy nowadays
[13:28] <asac> gema: right. but nothing is more powerful than a good revew report send to lazy managers :)
[13:28] <asac> but its ok
[13:28] <asac> lets get started and get from there
[13:28] <asac> gema: thanks a bunch!!! I certainly owe you a beer (if you like that)
[13:28] <asac> ttyt
[13:28] <gema> asac
[13:29] <gema> I am being told that pgraner and you agreed we were going to add them to the desktop
[13:29] <gema> and take it from there
[13:29] <plars> asac: I'm ready to add them, they've been wrapped into our test runner, just sent a merge proposal last night to get an ack to add them to the daily desktop smoke test runs
[13:29] <asac> gema: desktop?
[13:29] <gema> asac: yep
[13:29] <asac> gema: i want them on phablet and desktop :)
[13:29] <gema> plars: what's the problem with the phablet image and those tests?
[13:29] <plars> asac: they will be on desktop x86 runs for now, at some point the packages they require will be added to touch images, and they bugs that prevent them from working on touch will be fixed and we can just as easily add them to the runlist for touch
[13:30] <asac> plars: test first
[13:30] <asac> dont try to be too smart
[13:30] <asac> please add them to phablet
[13:30] <asac> and desktop
[13:30] <gema> asac: you want the phablet images to be red every day and to test for packages that are not there?
[13:30] <asac> yes
[13:30] <gema> why?
[13:30] <asac> discussed it with jamie
[13:30] <plars> gema, asac: there are a few known problems. 1. the touch images lack the dependencies to run them, so the very first thing that just uses apt to check if the packages are there will fail
[13:31] <asac> plars: we didnt add any apt checks
[13:31] <plars> second, there are a couple of open bugs that would prevent them from passing anyway
[13:31] <asac> plars: also note that phablet images have no packages
[13:31] <asac> in the near term
[13:31] <asac> just run them
[13:31] <plars> asac: yes, they're in the tests
[13:31] <plars> asac: I beg to differ
[13:31] <asac> if they are red, we track them and once it lands its going green
[13:32] <asac> well, you will never agree on all things.
[13:32] <gema> asac: neither will you
[13:32] <gema> you seem to be refusing to see how much of a waste is to add tests that check for dependancies that are not there
[13:32] <gema> it is paul and psivaa who need to look at those failures every day
[13:32] <gema> and make sure it is nothing new
[13:33] <gema> asac: if things are in the image and failing, I am all for it
[13:33] <gema> asac: if things are not even there, not so sure
[13:33] <asac> it is a CRITICAL BUG that those things are not in image
[13:33] <asac> at least from Jul 1 it will be
[13:33] <asac> so i want this to be red
[13:33] <plars> asac: the very first test in this uses apt-cache to check for packages
[13:33] <gema> asac: ok, that's not so bad then
[13:34] <gema> plars: let's add them and make sure that bug becomes critical
[13:34] <gema> pester developers
[13:34] <asac> right
[13:34] <plars> which, yes, will surely fail all the time on the flipped images
[13:34] <gema> plars: we've got green light from asac
[13:34] <asac> btw, i will track and push folks
[13:34] <plars> but even on the non-flipped ones will fail because the packages aren't there
[13:35] <asac> as i said, if the security tests are not succeeding we have a problem for our big July goals
[13:36] <asac> the big July goal is to have a working, confined click package story
[13:36] <asac> and demo it in Isle of Man
[13:38] <asac> thanks a bunch!
[13:38] <asac> lets chat later the week and see
[13:38]  * asac goes to beach!!
[13:38] <asac> :)
[13:38] <asac> and tells tvoss that you guys will pull for his tests suites
 hello
 I am trying to write autopilot test cases for empathy.http://paste.ubuntu.com/5799099/. but its showing ran 0 tests.I'm a beginner in autopilot. so I am just trying to launch the app
[17:16] <senan> can someone help me
[17:21] <DanChapman> hey senan
[17:21] <senan> hi Dan
[17:21] <DanChapman> 2 secs i'll have a quick look at your paste
[17:23] <DanChapman> senan, you have your setup method looking good. So now you need to create a test method. a test method needs to start with test_ for example....
[17:23] <DanChapman> def test_empathy_window_title()
[17:24] <DanChapman> autopilot runs all tests beginning with test_
[17:24] <senan> but it is not launching the app
[17:25] <DanChapman> im just gonna test see if we can launch it with launc_test_application
[17:28] <senan> ok
[17:28] <hggdh> chilicui1: hey -- so that it will be public -- thank you for your work on bug 1088131
[17:29] <hggdh> chilicui1: but we do not need to patch it for 8.20, it is really a minor issue.
[17:29] <chilicui1> hggdh: that's what I though, alright =)
[17:29] <hggdh> :-)
[17:36] <DanChapman> senan, http://paste.ubuntu.com/5799166/ this launches the application. You need to use autopilot vis to find empathys properties but you need to have a test_ method there for it to launch
[17:37] <senan> yes It worked
[17:38] <senan> I just added an empty test method
[17:38] <senan> and it worked
[17:38] <senan> :)
[17:40] <senan> Dan :  Do we use http://packages.qa.ubuntu.com/qatracker/testcases/1415/info for automating test ?
[17:40] <senan> for empathy ?
[17:45] <DanChapman> You can certainly try to follow the manual test as much as possible, but you can also add what you think the test could do.
[17:46] <senan> ok
[17:47] <senan> I'm looking for some assignments so that I can automate some tests
[17:50] <senan> thanks Dan
[17:50] <DanChapman> if you do 'autopilot launch empathy' then in another terminal window do autopilot vis you can view all the properties of empathy and find stuff to test
[17:50] <senan> ok
[17:50] <senan> thanks Dan
[17:50] <senan> I'll take a look at it
[17:50] <DanChapman> no problem. GIve me a shout if you get stuck
[17:51] <senan> I'm new to QA. But have experience in coding
[17:52] <senan> so learning the qa stuffs now
[17:54] <DanChapman> Cool senan, nice to have you hacking at some tests. Autopilot-gtk can get a bit tricky at times so just fire your questions here and someone will try and help.
[17:55] <DanChapman> balloons hey :-) did you give ubiquity test a whirl yesterday?
[18:31] <balloons> Hey DanChapman
[18:31] <balloons> Hey senan :-)
[18:32] <DanChapman> hey balloons, quiet round here today
[18:32] <balloons> I was out for a bit heh :-)
[18:33] <balloons> ok, so I'm preparing a post about the ubiquity stuff now actually
[18:33] <balloons> DanChapman, are you on g+?
[18:34] <DanChapman> oh right cool... errr yeah I think so let me see if I can remember my login
[18:35] <balloons> hehe.. I'll mention you directly one way or another :-)
[18:39] <DanChapman> Remembered my login :-) cool sounds good. I totally forgot about the QA g+ page.
[18:41] <balloons> yea, trying to give more updates to that page that might not merit a full post to the ml
[18:46] <DanChapman> cool, i'll keep an eye on it from now on :-)
[20:43] <balloons> Noskcaj, you about mate?
[20:43] <Noskcaj> balloons, yeah
[20:43] <balloons> I was wondering if you could review and merge https://code.launchpad.net/~elfy/ubuntu-manual-tests/XFCEKbd_setti/+merge/170293
[20:44] <balloons> I didn't want it to sit out there forever
[20:44] <Noskcaj> i have no idea how to merge stuff
[20:44] <balloons> ohh, well got a sec for me to walk you through it? something good to learn
[20:44] <balloons> it's just using bzr merge command :-)
[20:45] <knome> (and commit/push)
[20:45] <Noskcaj> ok
[20:45] <balloons> so first pull the upstream source tree
[20:45] <balloons> bzr branch lp:ubuntu-manual-tests
[20:46] <balloons> then merge the change proposed
[20:46] <knome> what about reviewing? :P
[20:46] <balloons> bzr merge lp:~elfy/ubuntu-manual-tests/XFCEKbd_setti
[20:46] <balloons> knome, you have to merge it first.. you don't have to commit it :-)
[20:46] <balloons> after the change is merged review everything
[20:46] <knome> well you can review at the MP page, it has a diff too
[20:46] <knome> i always review before merging even locally
[20:47] <knome> but yeah, either way works
[20:47] <balloons> knome, true
[20:47] <balloons> anyways, once your happy with everything issue a commit
[20:47] <knome> (unless i need to test some code, but then i just pull the proposed branch
[20:47] <balloons> bzr commit
[20:47] <balloons> mind you when you do the review, check for spelling errors too
[20:47] <balloons> and also make sure it passes the testcase format script
[20:48] <balloons> those 2 always need to happen.. the other part of the review is reading and making sense of the testcase, which you already know how to do
[20:48] <knome> balloons, on a different note, should we work on a better guide to writing testcasese?
[20:48] <balloons> anyways, once committed, you bzr push and it goes into the trunk of the source tree
[20:48] <knome> -e
[20:49] <balloons> knome, improvements are always welcome. what did you have in mind?
[20:50] <Noskcaj> knome, Please add a part on the format of the info at the very start of each test. every person writes it differently so far
[20:51] <knome> balloons, well atm we're telling "this is the format you need to use", but with the proposed changes, people need to care less and less about that and more about "if you a user needs to run a command, use <code>command</code> to denote the command" or sth
[20:51] <knome> balloons, so basically dig deeper on how to mark up the actual testcase instructions
[20:51] <Noskcaj> knome, +1 to that idea
[20:52] <balloons> oh right .. yea a refresh once we make those changes is a great idea
[20:52] <balloons> it continues to get easier for folks to write them
[20:52] <balloons> not sure if you remember knome's first cleanup from the ul, li nonsense
[20:52] <knome> there are things we could add already
[20:52] <balloons> now THOSE were some crazy tests
[20:53] <knome> like the <code> stuff and the information format as Noskcaj suggested
[20:53] <knome> i'm wondering what the best way to format that information would be though
[20:54] <knome> i'm thinking something like <h2>Test name <span>test-number-001</span></h2>
[20:54] <knome> then with some css, align the test-number-span to the right hand side of the testcase
[20:54] <Noskcaj> knome, remember to include the positioning in relation to the <dl> tags as sometime this stuff is put inside them
[20:55] <knome> yes, i agree, it would need to be outside the dl list
[20:55] <knome> that way it would be semantic, which is probably something you've heard me say before
[20:56] <knome> also, https://wiki.ubuntu.com/Testing/TestCaseFormat still lists both normal and smoke testcases, while i think we could simply adjoin them
[20:57] <knome> somehow, somewhere along the line, somebody has made this look much more complicated than it is
[21:00] <Noskcaj> especially since there are some many pages linked
[21:01] <balloons> knome, Noskcaj :-) I like where this is going
[21:01] <balloons> this is the iterative process happening is all.. see something, improve it
[21:03] <Noskcaj> Is there a benefit to allowing translations?
[21:05] <knome> https://wiki.ubuntu.com/Testing/TestCaseFormat/NewGuide#preview
[21:05] <balloons> back in a few guys
[21:05] <knome> https://wiki.ubuntu.com/Testing/TestCaseFormat/NewGuide too
[21:06] <Noskcaj> knome, the contents box looks a bit strange
[21:06] <Noskcaj> and do we now use the <h2> and <p> tags?
[21:07] <knome> i'm proposing that
[21:07] <knome> it's not "official" yet
[21:07] <knome> but wrapping certain recurring parts inside specific elements is a good thing
[21:07] <Noskcaj> makes sense, ypu could possibly automate the test number that way rather than manually writing -001 -002 -003
[21:08] <knome> in that case the tracker should be aware of the prefic
[21:08] <knome> *prefix
[21:08] <Noskcaj> balloons, how do i get the testcase number for XFCE$ keyboard
[21:08] <knome> Noskcaj, just come up with one if you want to
[21:08] <knome> Noskcaj, or leave it out
[21:10] <balloons> Noskcaj, I'll have to do that piece. or you can do it manually by adding the test yourself to the admin page on the tracker
[21:10] <Noskcaj> balloons, i'll leave the trcker end for you. i've made the number 1571 as that seems to be the next one
[21:11] <knome> balloons, https://wiki.ubuntu.com/Testing/TestCaseFormat/NewGuide
[21:11] <balloons> Noskcaj, ty :-)
[21:13] <Noskcaj> knome, what is the tag for either something you click on or something in a menu e.g. "Click <tag1>Help</tag1>" and "Click <tag2>Menu --> Help</tag2>
[21:13] <Noskcaj> those might not be necessary though
[21:13] <knome> there is no obvious html tag for that
[21:14] <Noskcaj> ok
[21:14] <Noskcaj> And your contents box still says 1.  1.
[21:15] <Noskcaj> never mind, fixed
[21:16] <knome> if we want menu items to stand out, we can use <u> (underline) for example
[21:16] <knome> we can even style that a bit so it doesn't look as bad as the <u> tag normally looks
[21:17] <knome> (eg. soften the underline and make it dashed instead of solid)
[21:17] <knome> and by soften, i mean making the underline color brighter
[21:19] <Noskcaj> i'll update the shotwell test as it is used as an example in the wiki but it's out of date
[21:45] <balloons> whew, sorry Noskcaj and knome
[21:46] <balloons> knome, so my comments.. I'm not sure the test-case-number is a good idea anymore
[21:47] <balloons> we were just commenting on that :-) not all of them have it.. it's something that used to exist before we had a proper db with test ids :-)
[21:47] <knome> yup
[21:47] <knome> i was wondering about it as well
[21:47] <balloons> I like the simplification of the page.
[21:47] <knome> no problem to drop it