| pitti | Good morning | 04:23 |
|---|---|---|
| === om26er is now known as om26er|afk | ||
| === om26er|afk is now known as om26er | ||
| 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 |
| ubot5 | bug 1366206 in lightdm (Ubuntu) "Graphical desktop not starting from livesession" [Undecided,Confirmed] https://launchpad.net/bugs/1366206 | 13:15 |
| balloons | elfy, I did see and was going to ask thanks | 13:15 |
| 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:16 |
| balloons | Ilm syncing today's iso to see what remains for me | 13:20 |
| elfy | :) | 13:21 |
| elfy | have fun | 13:21 |
| elfy | I did those tests with synced iso's 30 minutes ago | 13:21 |
| === om26er is now known as om26er|doc | ||
| elfy | balloons: any luck with it? | 14:22 |
| balloons | synced, but haven't yet been able to try | 14:23 |
| === chihchun_afk is now known as chihchun | ||
| === _salem is now known as salem_ | ||
| === chihchun is now known as chihchun_afk | ||
| balloons | elfy, I get the same issue | 15:06 |
| balloons | I can confirm | 15:06 |
| elfy | balloons: thanks - though I wish not ;) | 15:09 |
| === Ursinha is now known as Ursinha-afk | ||
| balloons | knome, elfy did you meet yesterday to discuss the tracker? | 16:49 |
| knome | yes | 16:50 |
| knome | http://pad.ubuntu.com/trackers | 16:50 |
| knome | see that | 16:50 |
| 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:52 |
| 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:54 |
| elfy | and with I'm wandering off for a bit | 16:55 |
| 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:56 |
| === Ursinha-afk is now known as Ursinha | ||
| elfy | balloons: ok - I'll be about an hour or so | 16:57 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| elfy | balloons: about when you are | 18:10 |
| 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:15 |
| 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:16 |
| balloons | elfy, I suspect this is still a vm driver thing | 18:18 |
| elfy | yea - I'd agree with that | 18:18 |
| balloons | so actually I'm not sure there's much more to go after here | 18:19 |
| elfy | you can try with qemu? | 18:19 |
| 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:21 |
| elfy | but sometimes get xfce session instead of xubuntu | 18:22 |
| elfy | balloons: but prior to starting manually you get the CanGraphic=no? | 18:23 |
| balloons | elfy, yep | 18:24 |
| 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:25 |
| elfy | not sure what to report this against - I couldn't report it against vbox - use the prop. one :) | 18:27 |
| balloons | elfy, I assume on boot we're getting xserver-xorg-video-vesa | 18:32 |
| balloons | so that's where I would place the bug | 18:33 |
| 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:34 |
| balloons | excellent | 18:35 |
| elfy | there done :) | 18:35 |
| 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:36 |
| * 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 |
| ubot5 | Ubuntu bug 1365336 in fglrx-installer-updates (Ubuntu) "Lightdm update=No desktop" [Critical,In progress] | 18:37 |
| elfy | oh actually I could apport-cli ubuntu-bug foo-vesa I guess | 18:37 |
| elfy | dupe it ? | 18:38 |
| 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:39 |
| elfy | not sure I can add -vesa to that bug | 18:40 |
| balloons | done | 18:41 |
| elfy | ta - to do that is it the Also affects distribution/package button? | 18:42 |
| balloons | yes, and I duped your bug | 18:42 |
| elfy | ok cheers - just getting the logs from a vbox boot to add to it | 18:43 |
| === Ursinha-afk is now known as Ursinha | ||
| elfy | balloons: attached as many logs as I could think of to 1365336 :) | 19:04 |
| === roadmr is now known as roadmr_afk | ||
| === salem_ is now known as _salem | ||
| 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 | 19:35 |
| ubot5 | Ubuntu bug 1366949 in Autopilot "press_duration is ignored on phablet devices" [Undecided,New] | 19:35 |
| === chihchun_afk is now known as chihchun | ||
| elfy | balloons: seems that Laércio is on the case again - I shall wait to get a .rule to try somehow :p | 20:20 |
| === roadmr_afk is now known as roadmr | ||
| balloons | knome, I don't see any proposed branches? | 20:37 |
| balloons | knome, lol, I see them now.. You just committed them | 20:37 |
| elopio | balloons: that is https://bugs.launchpad.net/autopilot/+bug/1268782 | 21:01 |
| elopio | fixed but not yet released. | 21:01 |
| ubot5 | Ubuntu bug 1268782 in Autopilot "tap method of Touch device doesn't have press_duration arg" [Undecided,Fix committed] | 21:01 |
| balloons | elopio, you are ALWAYS one step ahead of me.. | 21:01 |
| balloons | superherp | 21:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| balloons | elopio, you think checking for the keypress is a workaround? | 21:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| veebers | balloons: ah cool, was just loading the MP | 21:16 |
| balloons | this has been the longest mp I've my life | 21:16 |
| elopio | balloons: I'm happy you took that autopilot branch instead of me :) | 21:18 |
| elopio | ballons taking the bullet for the team | 21:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| elopio | balloons, thomi, veebers: I'll report a bug on autopilot for the missing sleep after click argument. | 21:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:35 |
| 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:37 |
| balloons | veebers, ok, :-) | 21:38 |
| 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:31 |
| elopio | thomi: that works for me. My only concern would be how to define the right delay. | 22:32 |
| 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:33 |
| 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:34 | |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:50 |
| 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:54 |
| 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.. | 22:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| veebers | elopio: ack | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!