[04:23] <pitti> Good morning
[13:15] <elfy> balloons: hi - not sure if you caught the earlier ping, but ubuntu, xubuntu and lubuntu at least still have this seat0 issue, I have found that it appears to only be a vm issue - but an issue nonetheless, I did bug 1366206 against lightdm for the moment, but I think it is a vbox bug atm
[13:15] <balloons> elfy, I did see and was going to ask thanks
[13:16] <elfy> just added a screenshot to the bug of the 3 vt's
[13:16] <elfy> given that we push people to test in vm's it'll need looking at I suppose lol
[13:20] <balloons> Ilm syncing today's iso to see what remains for me
[13:21] <elfy> :)
[13:21] <elfy> have fun
[13:21] <elfy> I did those tests with synced iso's 30 minutes ago
[14:22] <elfy> balloons: any luck with it?
[14:23] <balloons> synced, but haven't yet been able to try
[15:06] <balloons> elfy, I get the same issue
[15:06] <balloons> I can confirm
[15:09] <elfy> balloons: thanks - though I wish not ;)
[16:49] <balloons> knome, elfy did you meet yesterday to discuss the tracker?
[16:50] <knome> yes
[16:50] <knome> http://pad.ubuntu.com/trackers
[16:50] <knome> see that
[16:52] <balloons> knome, I'm getting info from stephane today so I should be able to review and update things.. :-)
[16:52] <knome> yep
[16:52] <elfy> nice
[16:52] <balloons> so I'll try and get your stuff landed as my first exercise of power :-)
[16:54] <knome> that's a start...
[16:54] <elfy> balloons: you got any idea who to prod about this vm no graphic issue? if it doesn't get looked at soon we'll be all over final beta
[16:55] <elfy> and with I'm wandering off for a bit
[16:56] <balloons> elfy, when you get back let's look at the bug together a bit more and see if we can come to a conclusion on what's failing
[16:56] <elopio> hello ubuntu-qa. Can I get a review here please? https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/autopilot-upstart_local_modules/+merge/232650
[16:57] <elfy> balloons: ok - I'll be about an hour or so
[18:10] <elfy> balloons: about when you are
[18:15] <balloons> elfy, your timing is good. let's roll
[18:15] <elfy> not sure if you have seen the old lightdm bug - but seems that xserver-xorg-video-vmware is affected by it
[18:16] <elfy> not used vmware for ~6 years so no idea :p
[18:16] <balloons> elfy, we should try this on qemu
[18:16] <elfy> nor that - only virtualisation I bother with is vbox
[18:18] <balloons> elfy, I suspect this is still a vm driver thing
[18:18] <elfy> yea - I'd agree with that
[18:19] <balloons> so actually I'm not sure there's much more to go after here
[18:19] <elfy> you can try with qemu?
[18:21] <balloons> elfy, ok, so I can get the livesession to boot if I start it manually.. That's the same as you right?
[18:21] <elfy> yep
[18:22] <elfy> but sometimes get xfce session instead of xubuntu
[18:23] <elfy> balloons: but prior to starting manually you get the CanGraphic=no?
[18:24] <balloons> elfy, yep
[18:25] <elfy> ok - so vbox/vmware and qemu all fail the same - with I assume different xorg drivers
[18:25] <balloons> could just be a udev issue, which is messed up currently
[18:25] <elfy> yep
[18:27] <elfy> not sure what to report this against - I couldn't report it against vbox - use the prop. one :)
[18:32] <balloons> elfy, I assume on boot we're getting xserver-xorg-video-vesa
[18:33] <balloons> so that's where I would place the bug
[18:34] <elfy> aah yes - I did check the logs once I got in
[18:34] <elfy> I'll change the one I reported the other day to affecting that
[18:35] <balloons> excellent
[18:35] <elfy> there done :)
[18:36] <balloons> elfy, it would be useful to have the logs for that tho
[18:36] <elfy> I'll boot vm and attach anything I can think of :D
[18:37]  * balloons is checking what apport pulls now
[18:37] <elfy> doing that now or I will forget
[18:37] <balloons> you going to simply add the bug to https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1365336?
[18:37] <elfy> oh actually I could apport-cli ubuntu-bug foo-vesa I guess
[18:38] <elfy> dupe it ?
[18:39] <elfy> balloons: actually - add the -vesa package to that bug would be best perhaps
[18:39] <balloons> elfy, yes that's what I think
[18:40] <elfy> not sure I can add -vesa to that bug
[18:41] <balloons> done
[18:42] <elfy> ta - to do that is it the Also affects distribution/package button?
[18:42] <balloons> yes, and I duped your bug
[18:43] <elfy> ok cheers - just getting the logs from a vbox boot to add to it
[19:04] <elfy> balloons: attached as many logs as I could think of to 1365336 :)
[19:35] <balloons> elopio, re: https://code.launchpad.net/~nskaggs/ubuntu-calculator-app/ap-fix-missing-keypress/+merge/233534/comments/570815. I need to file a bug in autopilot as the click duration does not work on phablet devices.https://bugs.launchpad.net/autopilot/+bug/1366949. I also left a larger comment explaining my reasoning
[20:20] <elfy> balloons: seems that Laércio is on the case again - I shall wait to get a .rule to try somehow :p
[20:37] <balloons> knome, I don't see any proposed branches?
[20:37] <balloons> knome, lol, I see them now.. You just committed them
[21:01] <elopio>  balloons: that is https://bugs.launchpad.net/autopilot/+bug/1268782
[21:01] <elopio> fixed but not yet released.
[21:01] <balloons> elopio, you are ALWAYS one step ahead of me..
[21:01] <balloons> superherp
[21:02] <balloons> elopio, is the mp otherwise a-ok for you/
[21:02] <elopio> balloons: but why is the default click duration not enough for the calculator?
[21:03] <balloons> elopio, it's possible it's fine now that I fixed the issue with not waiting for the screen before pressing keys, but I think verifying the keypress is the better way to go
[21:03] <balloons> it seems to run faster now than before
[21:05] <elopio> balloons: the default on autopilot should simulate what a standard user does as close as possible. So if it doesn't work sometimes on the calculator it would mean either that it would fail for a default user or that the parameter needs and adjustment on autopilot.
[21:05] <elopio> that's why I don't like the workaround, it's not clear which one is happening.
[21:06] <balloons> elopio, you think checking for the keypress is a workaround?
[21:07] <elopio> balloons: I do. That must always happen when we call autopilot's click_object.
[21:07] <balloons> sadly we must also think about slow machines.. the tests run in an xvfb environment as well.. There is some input lag and the default is REALLY quick
[21:07] <balloons> elopio, click_object isn't going to check for any response, it's simply going to send a click
[21:08] <thomi> balloons: you think 100ms between key press and key release is 'really quick' ?
[21:08] <elopio> balloons: then I think it is a problem on autopilot.
[21:08] <elopio> and we need a combination of low level and autopilot tests to make sure that a mouse click fires the pressed signal.
[21:08] <elopio> if this is a standard button, that test must be on Qt upstream.
[21:09] <balloons> thomi, I think the issue is that we fire off 5 presses in 550 ms
[21:09] <balloons> it's possible to miss one in a quick fire sequence
[21:09] <thomi> balloons: so you're suggesting that there needs to be a pause _after_ the key press, which is a different issue to the touch_duration MP then
[21:10] <balloons> thomi, well I suppose I wouldn't argue that ap needs to change actually. But a real user certainly won't hit keys that fast. The test could stagger the key presses
[21:10] <elopio> balloons: yes, I didn't understand that. From your MP, that would mean to put a sleep after click_object, not between the press and release.
[21:11] <balloons> elopio, yes, that might be the issue.. I say might because I didn't try solving it that way
[21:11] <balloons> but I like my check much better than adding sleeps anywhere
[21:11] <thomi> otp - will get back to this when I'm done
[21:12] <veebers> elopio, balloons: Will getting elopios MP released (press_duration) help with this at all?
[21:12] <balloons> elopio, I do know the first keypress is lost because it fails to wait for the screen to come up. adding a wait_for.visible(True) fixed that.
[21:12] <veebers> (balloons I'm just taking a look at your MP now too :-) )
[21:13] <balloons> veebers, without his MP I have to press, sleep, release to get the press_duration, which was my original change
[21:13] <balloons> elopio, I think other keypresses get lost, but you could simply run trunk tests or check the dashboard to confirm or deny this
[21:13] <veebers> balloons: ok, well it should be a pretty simple release, if it will help I can get that in  motion
[21:14] <elopio> balloons: what I asked on your MP was for a clarification of why the default is not good enought. What you are doing actually corresponds more or less with what a user would do, that's taking into account the button UI feedback when it's pressed.
[21:14] <balloons> veebers, if I get my way however I don't need press_duration, lol :-) I'm checking the key state, but not sure I'll convince the others it's the way to go
[21:14] <elopio> that makes sense. I would be happy with that comment on the code. Just a little worried that it might be affecting users somehow.
[21:15] <balloons> does the comment do it justice? since you asked it's worth making sure the comment makes sense
[21:15] <veebers> balloons: ack, let me know if you need it urgently. It will be released in the near future but we can do it sooner if required
[21:15] <balloons> veebers, and yea, I finally got a free minute to fix that little functional test failure
[21:16] <veebers> balloons: ah cool, was just loading the MP
[21:16] <balloons> this has been the longest mp I've my life
[21:18] <elopio> balloons: I'm happy you took that autopilot branch instead of me :)
[21:18] <elopio> ballons taking the bullet for the team
[21:19] <balloons> lol.. it pushed me, all good stuff
[21:19] <elopio> balloons: about calc, yes, the comment makes sense. If you are not sure if it's needed or not, I would prefer to land the branch with a normal click_object and see how it goes.
[21:19] <veebers> balloons: yeah sorry part of that was me not reviewing in time :-P
[21:19] <elopio> balloons: but if you prefer to land it as is, I won't object.
[21:19] <elopio> the comment makes it clear in case somebody wants to go deeper and eventually remove it.
[21:20] <veebers> balloons: hey, put my mind at ease, what changes (if any) will need to happen within app acceptance tests with this change? i.e. have you tested against the cal. app?
[21:21] <balloons> elopio, there is a slowdown fix branch that is depending on this to land.. maybe it can be swapped back after. Still, I prefer this implementation for the reasons I mentioned above
[21:22] <elopio> balloons: then go forth and land.
[21:22] <balloons> I was somewhat forced into it because of the AP bug, but I prefer it to adding sleeps or tweaking press_duration
[21:22] <elopio> I'll leave my +1
[21:22] <balloons> elopio, ty sir
[21:23] <elopio> balloons, thomi, veebers: I'll report a bug on autopilot for the missing sleep after click argument.
[21:24] <balloons> elopio, well that's a bigger discussion I think. Do you think it should sleep by default after a click?
[21:24] <elopio> balloons: I think it should at least give you the option to do it. And ideally the default will be something close to what a user would do.
[21:24] <elopio> the second part is the hard one.
[21:24] <balloons> it might fix some of the random failures we see I suppose
[21:24] <veebers> elopio: perhaps I missed something, why should click have a sleep?
[21:25] <veebers> ah, this is between clicks?
[21:25] <balloons> but I'm not convinced AP should change for it
[21:25] <elopio> veebers: because if you call click_object two times in a row, it will do it a lot faster than a human could.
[21:25] <balloons> yes, we're discussing for instance the calc which started this. Currently the test can enter operations insanely fast compared to a human
[21:26] <veebers> hmmm
[21:26] <elopio> what do you think veebers? should it be autopilot's API, or the sleep should be added by a higher level loop?
[21:26] <balloons> but imho, the test should account for this and not the tool
[21:26] <balloons> I would argue you should check the UI for a response
[21:26] <balloons> no sleep
[21:27] <elopio> balloons: I think the response test is a low level QML test.
[21:27] <balloons> unless you wanted to stagger input to completely mimic a user's input speed
[21:27] <veebers> I don't think 'click_object' should have an pre/post sleep as it's a stand alone action, if it was 'click_objects' (i.e. plural) sure it would make sense
[21:27] <elopio> on autopilot you should just assume that if you click, the button receives the input and fires the signal.
[21:27] <veebers> elopio: I agree with you there
[21:28] <elopio> veebers: click objects makes sense only for calculator and osk, so I won't file the bug.
[21:28] <balloons> click_objects.. that's interesting
[21:28] <elopio> we can solve it on the higher level project.
[21:29] <veebers> right, if anything click_objects can start as a UUTK helper (as that's where it's used)
[21:29] <balloons> the osk is interesting thought
[21:29] <elopio> thanks for the review robotfuel
[21:35] <veebers> balloons: re: your datetime MP you'll need a packaging persons ack on the packaging changes (shouldn't be to hard, they're quite simple)
[21:37] <balloons> veebers, who do you suggest?
[21:37] <balloons> just anyone?
[21:37] <veebers> balloons: I've asked robru in the past, but any packaging person is fine (I'm not sure of that list of people off the top of my head though)
[21:38] <balloons> veebers, ok, :-)
[22:31] <thomi> hi guys - I'm back
[22:31] <knome> welcome back
[22:31] <thomi> what about having AP keep track of the last time it sent a click command, and delaying if that is < 100ms ago?
[22:31] <thomi> veebers: balloons, elopio ^^
[22:31] <thomi> that would keep the API clean, and mimic what a user would do
[22:32] <elopio> thomi: that works for me. My only concern would be how to define the right delay.
[22:33] <veebers> thomi: sounds nice and clean, I can't imagine it stepping on anyones toes either (i.e. I want a test that taps as fast as hell on this button)
[22:33] <thomi> elopio: 100ms seems reasonable. We can always land a conservative guess and tweak it if it causes problems
[22:33] <elopio> I agree.
[22:33] <thomi> we could even land a branch that just measures the gap and reports that statistic to a test attachment, but doens't do any sleeping
[22:34] <thomi> then, in phase 2, we could use that data to come up with a sensible value
[22:34] <thomi> but TBH, that sounds like a lot of work
[22:34] <thomi> I'd just land the first idea, myself
[22:34] <thomi> but I'll levae it in veebers hands.
[22:34]  * thomi needs coffee
[22:36] <veebers> elopio: do you mind filing the bug you mentioned earlier re between tap delays so we don't loose the conversation. The idea is sound, just needs to be scoped out and implemented
[22:36] <elopio> veebers: on it.
[22:36] <veebers> thanks :-)
[22:36] <balloons> interesting you all agree
[22:37] <elopio> veebers: you have some code to get information from click list --manifest
[22:37] <balloons> I guess I might be the lone dissenter on this
[22:37] <elopio> veebers: I need something similar. Is there a good place to put those helpers so we can all use them?
[22:38] <veebers> elopio: it depends on what you're needing :-) What are your requirements?
[22:38] <balloons> thomi, ofc you'll make it an optional arg. In theory it will have no effect on 99% of the running tests as they are rather unlikely to send taps that quickly
[22:38] <elopio> veebers: give the package id and receive the version number.
[22:39] <veebers> elopio: hmm, I thought that was there too, I'll take a look shortly and get back to you
[22:39] <elopio> veebers: oh, and I also need the directory
[22:50] <thomi> balloons: I wasn't going to make it optional - I missed some of the scrollback - want to tell me why you think that's a bad idea? I'm interested in dissenting opinions :)
[22:54] <balloons> thomi, so having a global wait on click if you will isn't nearly as concerning as a wait after each click. From elopio's perspective autopilot should clone the user as much as possible. That's an interesting thought, but I'm not sure autopilot as a tool has attempted to do that historically persay. That is to say, it's not tried to prevent you from shooting yourself in the foot
[22:59] <balloons> so I wouldn't dissent too much about a global wait on click; especially something so small as 100 ms. I suppose my concern there would be the inability to avoid having to wait 100 ms between each tap. No I don't have a use case for way, but I don't like arbitrary restrictions. And it's probably non-trivial to make the global wait be 0.. autopilot doesn't really have any global options..
[23:00] <elopio> balloons: I think that if you try to test something that requires you a really small amount of time between events and you use autopilot, you would be shooting yourself on the foot.
[23:00] <thomi> balloons: you are correct that we haven't tried very hard to stop people shooting themselves in the foot in the past, but I think that's a bad thing, and something I want to change
[23:01] <elopio> it has a lot of overhead, and you could do better with QML in that case.
[23:01] <thomi> I think that AP should, whenever possible, mimic the user - this is what sets us apart from squish, for example
[23:01] <elopio> and anyway, it wouldn't be hard to make the time between events configurable, if that's needed for a good reason.
[23:01] <balloons> elopio, thomi I'm in full agreement. Ok, so you recognize at least you are steering autopilot into that direction.
[23:01] <thomi> balloons: absolutely
[23:02] <thomi> balloons: and if someone every comes up with a use case for wanting faster clicks that fits in with the autopilot testing strategy, then we can look at making it configurable
[23:02] <elopio> +1. It should be user simulation. Not just task automation.
[23:02] <balloons> thomi, for my own sanity, if this was implemented at a method level, what's the harm in an optional arg?
[23:03] <elopio> having said that, selenium has a nice mode that runs the tests in cocaine mode.
[23:03] <balloons> elopio, lolololol
[23:03] <thomi> balloons: options are to be avoided at all costs. They make the API much harder to use, and introduce bugs
[23:03] <elopio> that's not really useful to get stable executions, but it's good to exercise the application and gather some interesting bugs.
[23:03] <balloons> I feel like python does them quite well.. althought in general I understand and agree conceptually
[23:03] <thomi> balloons: basically, it adds complexity where none is required
[23:05] <balloons> thanks for the discussion. . . +1 from me for the global wait
[23:05] <balloons> So elopio, when will we be tapping on the OSK for all input? :p
[23:06] <elopio> balloons: I hope to have all set by the sprint. Then we can hack an evening to make sure all apps are using it.
[23:07] <elopio> balloons: there's a big list of things to do. First, get the osk tests running on MPs and dashboard.
[23:07] <balloons> more UITK goodness
[23:07] <elopio> then, get the toolkit helpers working in a way that lets us enable the OSK one suite at a time.
[23:07] <balloons> yep, awesome. that aligns with my thoughts
[23:07] <elopio> and then enable them on all projects. I expect many troubles on this last step, because many tests assume too much.
[23:08] <balloons> we've gotten much better.. I feel like it won't be nearly as painful as you think
[23:08] <balloons> the helpers might be a bit
[23:08] <elopio> balloons: dios lo oiga.
[23:08] <veebers> elopio: out of interest, what's the haps with the OSK autopilot stuff, it used to work and there was work to get it in the dash + used by other tests
[23:08] <elopio> you see? I can use weird sayings too :)
[23:09] <elopio> veebers: the tests are not running on MPs, so I expect the helpers to be a little outdated.
[23:09] <elopio> then the problem was about restarting the keyboard with testability
[23:09] <elopio> we now have many ways of doing it. We just need to pick one, that's not a big problem.
[23:10] <elopio> and then, the helpers on the toolkit are not using osk, they are using uinput. So we need to extend that to use osk if it's available.
[23:11] <elopio> veebers: not a big deal in general. It just requires one or two weeks of work, and lately we haven't been able to duplicate the available weeks.
[23:11] <balloons> elopio, oie
[23:12] <veebers> elopio: ack