[04:23] Good morning === om26er is now known as om26er|afk === om26er|afk is now known as om26er [13:15] 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] bug 1366206 in lightdm (Ubuntu) "Graphical desktop not starting from livesession" [Undecided,Confirmed] https://launchpad.net/bugs/1366206 [13:15] elfy, I did see and was going to ask thanks [13:16] just added a screenshot to the bug of the 3 vt's [13:16] given that we push people to test in vm's it'll need looking at I suppose lol [13:20] Ilm syncing today's iso to see what remains for me [13:21] :) [13:21] have fun [13:21] I did those tests with synced iso's 30 minutes ago === om26er is now known as om26er|doc [14:22] balloons: any luck with it? [14:23] synced, but haven't yet been able to try === chihchun_afk is now known as chihchun === _salem is now known as salem_ === chihchun is now known as chihchun_afk [15:06] elfy, I get the same issue [15:06] I can confirm [15:09] balloons: thanks - though I wish not ;) === Ursinha is now known as Ursinha-afk [16:49] knome, elfy did you meet yesterday to discuss the tracker? [16:50] yes [16:50] http://pad.ubuntu.com/trackers [16:50] see that [16:52] knome, I'm getting info from stephane today so I should be able to review and update things.. :-) [16:52] yep [16:52] nice [16:52] so I'll try and get your stuff landed as my first exercise of power :-) [16:54] that's a start... [16:54] 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] and with I'm wandering off for a bit [16:56] 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] 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 === Ursinha-afk is now known as Ursinha [16:57] balloons: ok - I'll be about an hour or so === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [18:10] balloons: about when you are [18:15] elfy, your timing is good. let's roll [18:15] not sure if you have seen the old lightdm bug - but seems that xserver-xorg-video-vmware is affected by it [18:16] not used vmware for ~6 years so no idea :p [18:16] elfy, we should try this on qemu [18:16] nor that - only virtualisation I bother with is vbox [18:18] elfy, I suspect this is still a vm driver thing [18:18] yea - I'd agree with that [18:19] so actually I'm not sure there's much more to go after here [18:19] you can try with qemu? [18:21] elfy, ok, so I can get the livesession to boot if I start it manually.. That's the same as you right? [18:21] yep [18:22] but sometimes get xfce session instead of xubuntu [18:23] balloons: but prior to starting manually you get the CanGraphic=no? [18:24] elfy, yep [18:25] ok - so vbox/vmware and qemu all fail the same - with I assume different xorg drivers [18:25] could just be a udev issue, which is messed up currently [18:25] yep [18:27] not sure what to report this against - I couldn't report it against vbox - use the prop. one :) [18:32] elfy, I assume on boot we're getting xserver-xorg-video-vesa [18:33] so that's where I would place the bug [18:34] aah yes - I did check the logs once I got in [18:34] I'll change the one I reported the other day to affecting that [18:35] excellent [18:35] there done :) [18:36] elfy, it would be useful to have the logs for that tho [18:36] I'll boot vm and attach anything I can think of :D [18:37] * balloons is checking what apport pulls now [18:37] doing that now or I will forget [18:37] you going to simply add the bug to https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1365336? [18:37] Ubuntu bug 1365336 in fglrx-installer-updates (Ubuntu) "Lightdm update=No desktop" [Critical,In progress] [18:37] oh actually I could apport-cli ubuntu-bug foo-vesa I guess [18:38] dupe it ? [18:39] balloons: actually - add the -vesa package to that bug would be best perhaps [18:39] elfy, yes that's what I think [18:40] not sure I can add -vesa to that bug [18:41] done [18:42] ta - to do that is it the Also affects distribution/package button? [18:42] yes, and I duped your bug [18:43] ok cheers - just getting the logs from a vbox boot to add to it === Ursinha-afk is now known as Ursinha [19:04] balloons: attached as many logs as I could think of to 1365336 :) === roadmr is now known as roadmr_afk === salem_ is now known as _salem [19:35] 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] Ubuntu bug 1366949 in Autopilot "press_duration is ignored on phablet devices" [Undecided,New] === chihchun_afk is now known as chihchun [20:20] balloons: seems that Laércio is on the case again - I shall wait to get a .rule to try somehow :p === roadmr_afk is now known as roadmr [20:37] knome, I don't see any proposed branches? [20:37] knome, lol, I see them now.. You just committed them [21:01] balloons: that is https://bugs.launchpad.net/autopilot/+bug/1268782 [21:01] fixed but not yet released. [21:01] Ubuntu bug 1268782 in Autopilot "tap method of Touch device doesn't have press_duration arg" [Undecided,Fix committed] [21:01] elopio, you are ALWAYS one step ahead of me.. [21:01] superherp [21:02] elopio, is the mp otherwise a-ok for you/ [21:02] balloons: but why is the default click duration not enough for the calculator? [21:03] 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] it seems to run faster now than before [21:05] 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] that's why I don't like the workaround, it's not clear which one is happening. [21:06] elopio, you think checking for the keypress is a workaround? [21:07] balloons: I do. That must always happen when we call autopilot's click_object. [21:07] 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] elopio, click_object isn't going to check for any response, it's simply going to send a click [21:08] balloons: you think 100ms between key press and key release is 'really quick' ? [21:08] balloons: then I think it is a problem on autopilot. [21:08] and we need a combination of low level and autopilot tests to make sure that a mouse click fires the pressed signal. [21:08] if this is a standard button, that test must be on Qt upstream. [21:09] thomi, I think the issue is that we fire off 5 presses in 550 ms [21:09] it's possible to miss one in a quick fire sequence [21:09] 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] 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] 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] elopio, yes, that might be the issue.. I say might because I didn't try solving it that way [21:11] but I like my check much better than adding sleeps anywhere [21:11] otp - will get back to this when I'm done [21:12] elopio, balloons: Will getting elopios MP released (press_duration) help with this at all? [21:12] 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] (balloons I'm just taking a look at your MP now too :-) ) [21:13] veebers, without his MP I have to press, sleep, release to get the press_duration, which was my original change [21:13] 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] balloons: ok, well it should be a pretty simple release, if it will help I can get that in motion [21:14] 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] 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] 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] does the comment do it justice? since you asked it's worth making sure the comment makes sense [21:15] 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] veebers, and yea, I finally got a free minute to fix that little functional test failure [21:16] balloons: ah cool, was just loading the MP [21:16] this has been the longest mp I've my life [21:18] balloons: I'm happy you took that autopilot branch instead of me :) [21:18] ballons taking the bullet for the team [21:19] lol.. it pushed me, all good stuff [21:19] 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] balloons: yeah sorry part of that was me not reviewing in time :-P [21:19] balloons: but if you prefer to land it as is, I won't object. [21:19] the comment makes it clear in case somebody wants to go deeper and eventually remove it. [21:20] 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] 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] balloons: then go forth and land. [21:22] I was somewhat forced into it because of the AP bug, but I prefer it to adding sleeps or tweaking press_duration [21:22] I'll leave my +1 [21:22] elopio, ty sir [21:23] balloons, thomi, veebers: I'll report a bug on autopilot for the missing sleep after click argument. [21:24] elopio, well that's a bigger discussion I think. Do you think it should sleep by default after a click? [21:24] 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] the second part is the hard one. [21:24] it might fix some of the random failures we see I suppose [21:24] elopio: perhaps I missed something, why should click have a sleep? [21:25] ah, this is between clicks? [21:25] but I'm not convinced AP should change for it [21:25] 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] 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] hmmm [21:26] what do you think veebers? should it be autopilot's API, or the sleep should be added by a higher level loop? [21:26] but imho, the test should account for this and not the tool [21:26] I would argue you should check the UI for a response [21:26] no sleep [21:27] balloons: I think the response test is a low level QML test. [21:27] unless you wanted to stagger input to completely mimic a user's input speed [21:27] 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] on autopilot you should just assume that if you click, the button receives the input and fires the signal. [21:27] elopio: I agree with you there [21:28] veebers: click objects makes sense only for calculator and osk, so I won't file the bug. [21:28] click_objects.. that's interesting [21:28] we can solve it on the higher level project. [21:29] right, if anything click_objects can start as a UUTK helper (as that's where it's used) [21:29] the osk is interesting thought [21:29] thanks for the review robotfuel [21:35] 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] veebers, who do you suggest? [21:37] just anyone? [21:37] 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] veebers, ok, :-) [22:31] hi guys - I'm back [22:31] welcome back [22:31] what about having AP keep track of the last time it sent a click command, and delaying if that is < 100ms ago? [22:31] veebers: balloons, elopio ^^ [22:31] that would keep the API clean, and mimic what a user would do [22:32] thomi: that works for me. My only concern would be how to define the right delay. [22:33] 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] elopio: 100ms seems reasonable. We can always land a conservative guess and tweak it if it causes problems [22:33] I agree. [22:33] 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] then, in phase 2, we could use that data to come up with a sensible value [22:34] but TBH, that sounds like a lot of work [22:34] I'd just land the first idea, myself [22:34] but I'll levae it in veebers hands. [22:34] * thomi needs coffee [22:36] 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] veebers: on it. [22:36] thanks :-) [22:36] interesting you all agree [22:37] veebers: you have some code to get information from click list --manifest [22:37] I guess I might be the lone dissenter on this [22:37] veebers: I need something similar. Is there a good place to put those helpers so we can all use them? [22:38] elopio: it depends on what you're needing :-) What are your requirements? [22:38] 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] veebers: give the package id and receive the version number. [22:39] elopio: hmm, I thought that was there too, I'll take a look shortly and get back to you [22:39] veebers: oh, and I also need the directory [22:50] 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] 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] 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] 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] 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] it has a lot of overhead, and you could do better with QML in that case. [23:01] I think that AP should, whenever possible, mimic the user - this is what sets us apart from squish, for example [23:01] and anyway, it wouldn't be hard to make the time between events configurable, if that's needed for a good reason. [23:01] elopio, thomi I'm in full agreement. Ok, so you recognize at least you are steering autopilot into that direction. [23:01] balloons: absolutely [23:02] 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] +1. It should be user simulation. Not just task automation. [23:02] thomi, for my own sanity, if this was implemented at a method level, what's the harm in an optional arg? [23:03] having said that, selenium has a nice mode that runs the tests in cocaine mode. [23:03] elopio, lolololol [23:03] balloons: options are to be avoided at all costs. They make the API much harder to use, and introduce bugs [23:03] that's not really useful to get stable executions, but it's good to exercise the application and gather some interesting bugs. [23:03] I feel like python does them quite well.. althought in general I understand and agree conceptually [23:03] balloons: basically, it adds complexity where none is required [23:05] thanks for the discussion. . . +1 from me for the global wait [23:05] So elopio, when will we be tapping on the OSK for all input? :p [23:06] 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] balloons: there's a big list of things to do. First, get the osk tests running on MPs and dashboard. [23:07] more UITK goodness [23:07] then, get the toolkit helpers working in a way that lets us enable the OSK one suite at a time. [23:07] yep, awesome. that aligns with my thoughts [23:07] and then enable them on all projects. I expect many troubles on this last step, because many tests assume too much. [23:08] we've gotten much better.. I feel like it won't be nearly as painful as you think [23:08] the helpers might be a bit [23:08] balloons: dios lo oiga. [23:08] 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] you see? I can use weird sayings too :) [23:09] veebers: the tests are not running on MPs, so I expect the helpers to be a little outdated. [23:09] then the problem was about restarting the keyboard with testability [23:09] we now have many ways of doing it. We just need to pick one, that's not a big problem. [23:10] 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] 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] elopio, oie [23:12] elopio: ack