[14:10] <brendand> elopio, did you see that problem?
[14:13] <elopio> brendand: can you write a test that does global rect in a loop and checks that it's always the same?
[14:13] <elopio> this definitely has nothing to do with the sdk.
[14:14] <elopio> the problem has to be between autopilot and the shell. gerry did a hack on globalRect to take into account the indicators bar. That might be related too.
[14:16] <elopio> brendand: also, I didn't bring a mako. Can you reproduce that on krillin?
[14:17] <brendand> elopio, haven't tried on krillin yet. will do
[14:17] <elopio> brendand: if you make a branch with the test, I can debug on krillin here.
[14:33] <brendand> elopio, yeah i'll aim to do that by eod
[14:43] <elopio> pitti: do you have a link to the snappy specs you mentioned?
[14:44] <pitti> elopio: https://docs.google.com/document/d/1oNYSBInP9CW1tJNnixiddPnPEah0_XMOTPaaLzltoVc/edit
[14:44] <brendand> elopio, indeed it doesn't fail on krillin
[14:44] <elopio> brendand: crazy shit.
[14:44] <brendand> elopio, maybe i'll go take some drugs, see if it makes sense then
[14:44] <elopio> I should have brought my mako.
[14:44] <elopio> brendand: drugs are always the way!
[14:45] <pitti> elopio: under "snappy security for snaps"
[14:45] <brendand> elopio, i know but i keep getting in trouble when i put them on my expense report :/
[14:46] <brendand> elopio, i'll go back to mako now and see what i can figure out
[14:51] <elopio> brendand: if you get that loop failing reliably, please send an email to veebers and gerry.
[15:04] <brendand> elopio, i'm thinking now it's to do with the indicator bar
[15:08] <elopio> brendand: what gerry did was basicaly to patch the globalRect so it adds up the bar size in case it's visible.
[15:08] <flexiondotorg> elfy, Are you available?
[15:08] <brendand> elopio, something is wrong with that
[15:08] <elfy> flexiondotorg: I am
[15:09] <brendand> elopio, some assumptions were made based on krillin i guess
[15:10] <brendand> elopio, i need to investigate more before i can explain it properly
[15:10] <elopio> brendand: this sounds interesting. Thanks for taking care of it, I would have never imagined globalRect being wrong.
[15:10] <brendand> elopio, it looks like in some circumstances the test runs with a different gu setting?
[15:10] <brendand> elopio, and then it works
[15:10] <elopio> brendand: ohhh
[15:11] <elopio> brendand: we are patching the gu for the test.
[15:11] <brendand> elopio, oooooh
[15:11] <brendand> :o
[15:11] <elopio> but the gu used to get the size of the globalRect shouldn't be patched.
[15:11] <elopio> hum
[15:12] <elopio> brendand: ok, if you are sure that's the problem, then it makes sense to do the test at a lower level.
[15:12] <elopio> don't use autopilot at all.
[15:12] <brendand> elopio, you're using the InitCtlEnv fixture to set that?
[15:12] <elopio> brendand: yes.
[15:13] <elopio> or an alternative would be to restart unity so it takes the new GU.
[15:13] <brendand> elopio, yeah it works if unity restarts
[15:15] <brendand> elopio, ubuntu-ui-toolkit so far doesn't have any python unit tests right?
[15:15] <brendand> elopio, was trying to find a place to put a unit test but didn't see any
[15:16] <elopio> brendand: I would put it in the same place, just not inherit from autopilot.
[15:16] <brendand> elopio, ok
[15:16] <elopio> I knew I was doing something stupid.
[15:23] <brendand> elopio, but it seems we have uncovered a problem though so maybe working around it isn't ideal?
[15:23] <brendand> elopio, doesn't this show an issue with gerrys code?
[15:23] <elopio> brendand: yes, it's a known hack that they need to remove.
[15:23] <elopio> brendand: let me try to find more information.
[15:24] <brendand> elopio, i mean i can easily write a unit test and get this landed but it seems like it's not the whole story
[15:24] <elopio> if I remember correctly, this will miserably fail when we have non-maximized windows.
[15:25] <elopio> brendand: for now, this is not going to bite us. But maybe it raises the priority for them to remove the hack.
[15:26] <elopio> brendand: https://bugs.launchpad.net/qtmir/+bug/1422523
[15:27] <elopio> https://bugs.launchpad.net/autopilot/+bug/1346633
[15:38] <brendand> elopio, have a look at http://bazaar.launchpad.net/~brendan-donegan/ubuntu-ui-toolkit/grid_units_unit_test/revision/1422 and tell me if you think it's adequate...
[15:39] <elopio> brendand: it's good.
[15:41] <brendand> elopio, ok to overwrite your branch?
[15:41] <elopio> brendand: my branch is owned by the team. It means you can do with it anything you like.
[15:42] <brendand> elopio, well yes. but #courtesy :)
[15:42] <brendand> ok now to wait for jenkins results
[15:43] <brendand> hopefully it won't be too difficult to land the other two branches from here
[15:43] <brendand> elopio, this problem won't impact the other merge proposals?
[15:44] <elopio> brendand: no. This only means that we will be able to express the y from the bottom in gu.
[15:45] <elopio> in the tests with a gu env var change, we restart unity.
[15:56] <brendand> elopio, would be good to get your review for https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/grid_units/+merge/248980 again
[16:01] <elopio> brendand: +1. You can ping timp to get a review.
[16:01] <elopio> he's the one who requested this.
[16:14] <t1mp> brendand, elopio: I'll check it
[16:26] <t1mp> brendand: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/grid_units/+merge/248980 looks good
[16:26] <t1mp> brendand: if it is done like this, I'll top-approve
[18:33] <brendand> t1mp, there were some flake8 issues in https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/grid_units/+merge/248980, fixed now, if you can re top-approve
[18:40] <jodh> elopio: hi - no idea what errors you are referring to, but have you read the snappy test doc yet? https://docs.google.com/a/canonical.com/document/d/1R_Tw0N0QbEpjFeYf9XnVV8Gp8ldT2Ig0PO6MfR-kuSM/edit#heading=h.axacykx0hozl
[18:46] <elopio> jodh: I haven't. Thanks for the pointer.
[18:46] <elopio> jodh: I was just wondering what kind of errors have you encountered while running tests manually. Like links to a couple of bugs you have reported would be nice.
[18:54] <balloons> elfy, wow, so the images are still having issues? This is what you get for going away
[18:59] <elopio> nuclearbob: do you have a link to the current sprint's backlog? I can't find it.
[18:59] <nuclearbob> elopio: there's the sprint backlog lane here: https://trello.com/b/8dD0UPNl/qa-stakeholders-backlog
[18:59] <nuclearbob> that's the one I have
[19:03] <elopio> nuclearbob: found it https://trello.com/b/YDGg3VF0/sprint-2015-qa-6
[19:04] <nuclearbob> elopio: oh, thanks. That's useful
[19:04] <jodh> elopio: take a look at http://paste.ubuntu.com/10817742/. I'll add some more details to the gdoc above on the upgrader as it may be useful to you...
[19:04] <elopio> jodh: that's perfect, thanks.
[19:07] <elopio> jfunk: I'm going to add to the CI backlog a card for running the ubuntu-ota-tests.
[19:07] <jfunk> sure ping when it's ready
[19:07] <jfunk> let's talk about it
[19:07] <elopio> Ursinha: can you please remind me of the process? Should I just add a card, or tell you and ev first?
[19:08] <jfunk> elopio: I'd also like to talk about how to run them regularly until they are up and running in CI
[19:09] <elopio> jfunk: should be the same as the sanity. But probably it becomes too much for only one person to run it all, so we might need to rotate.
[19:09] <elopio> nuclearbob: how much time is it taking for you to run the sanity daily?
[19:09] <jfunk> and where are the results
[19:09] <jfunk> nuclearbob: ^
[19:11] <nuclearbob> elopio: I've been running it while I'm running power stuff on another device. Right now the results are just stored locally, but one of my tasks today is creating a spreadsheet to upload that. My existing results are formatted to go into it, and I'll link it before I EOD
[19:16] <jodh> elopio: see "Further Information" at the end of https://docs.google.com/a/canonical.com/document/d/1R_Tw0N0QbEpjFeYf9XnVV8Gp8ldT2Ig0PO6MfR-kuSM/edit#
[19:17] <elopio> sorry, wrong button.
[19:17] <elopio> jodh: got it. Thanks!
[19:34] <t1mp> brendand: okay. I happroved https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/grid_units/+merge/248980 again
[19:46] <jodh> elopio: fyi: https://bugs.launchpad.net/snappy-ubuntu/+bug/1424586
[21:26] <Ursinha> elopio: send us an email and we'll get to you asap :)
[22:20] <veebers> hey, re: the provisioning in the doc, for the sanity tests it's expected that the networking is setup before being run, but the notes say the opposite
[22:24] <elopio> veebers: the sanity is able to provision the network.
[22:24] <elopio> what we discussed here after looking the provisioning script for boottest is that the least CI does during provisioning, the better for us.
[22:25] <elopio> because on that script they are disabling the wizard, which we want to test. And they are making the image writable, which we don't want to do.
[22:26] <veebers> elopio: the readme in the sanity suite states: The test suite requires that a network is available to download the test
[22:26] <veebers> dependencies (see `Setup the network using phablet-network`_).
[22:28] <elopio> veebers: there must be a network for the phone to connect to. But if the phone is not connected to that network, we can call the sanity with --network so it connects.
[22:29] <elopio> veebers: actually, lets roll back. Do you think setting up the phone network should be a task of the provisioning tool, or a task for the test?
[22:30] <veebers> elopio: there needs to be a network connection before the tests right, for adb to d/l all the req. deps.
[22:30] <elopio> veebers: it depends on how you define a test. When does the test start, when we run ubuntu-sanity-test, or when we run adt-run?
[22:30] <elopio> we need the network to be set up before adt-run. But not before calling ubuntu-sanity-test --network.
[22:31] <veebers> elopio: well, I would say that the tests are called 'test_<blah>' anything else is the wrapper :-) So maybe the wrapper should provision the network before adt-run gets called
[22:32] <veebers> I had failed to realise that there was the --network option
[22:32] <elopio> veebers: right.
[22:32] <elopio> so we have two types of provisioning.
[22:32] <elopio> there are three steps:
[22:32] <veebers> so ultimately either phablet-netowrk or --network needs to get called
[22:33] <elopio> 1. get me a free device, mako, devel, image #
[22:33] <elopio> 2. set up the job: set up the network, create the config file.
[22:34] <elopio> 3. run the test.
[22:34] <elopio> what we discussed was that step 1 is CIs job.
[22:34] <elopio> steps 2 and 3 are our job.
[22:35] <veebers> elopio: when you say "set up the job" is that the header for the next 2 steps or are you saying that we'll create the jenkins/whatever job config and have to maintain that?
[22:36] <elopio> but there are many other ways to split the three steps. So your input here is useful.
[22:36] <elopio> veebers: hum, yes, I guess taking care of step #2 will also mean that we maintain the jenkins job
[22:38] <elopio> at least now it's clear that this section in the document needs to be cleared :)
[22:38] <veebers> elopio: that makes me a little nervous as that's outside our normal operations (creating, maintaining jenkins job) but perhaps that's just because we haven't needed to yet
[22:38] <veebers> yeah :-)
[22:38] <elopio> veebers: what I would like to know is where do you think that the line between CI and QA should be.
[22:39] <veebers> a suggestion would be for us to provide a mechanism (a script I guess) that generates a config file and you pass it the serial, the wifi details.
[22:39] <veebers> so then CI could create a job that does 1. then calls this script passing the details needed, then runs the test
[22:40] <veebers> I'm not sure if either team as a 'decree' or whatever, but my (possibly incorrect) understanding is that CI is tasked with automating established test suites (among other things of course)
[22:42] <elopio> veebers: that sounds ok. We give CI all the commands needed to run the test.
[22:42] <elopio> and they put it in a job.
[22:43] <veebers> elopio: right, we should work closely with them though, I don't like the idea of throwing this stuff over the wall and expecting them to sort it out (and vice versa)
[22:44] <elopio> veebers: yes, I agree with everything you have said.
[22:45] <elopio> veebers: the problem we found was that steps 1 and 2 were in the same script, not easy to modify.
[22:47] <veebers> right, we should be able to resolve that easily though
[22:47] <elopio> so we didn't actually discussed how step 2 should be. Just that they should be separated.
[22:49] <elopio> veebers: on the case of boottest, it's actually not that easy. The script they have is pretty big.
[22:51] <veebers> elopio: remind which the boottest is?
[23:03] <elopio> veebers: the boottest flashes a device, and uses adt-run to execute "ls" in the device.
[23:03] <veebers> elopio: ah right, I was a little confused which test it was (still thinking of the sanity tests)