[14:35] <brendand> elopio, talk talk talk :)
[14:35] <elopio> brendand: fgimenez: https://code.launchpad.net/~veebers/autopilot/revert-ext-class-fix-for-now/+merge/251025
[14:36] <elopio> https://bugs.launchpad.net/autopilot/+bug/1376996
[14:36] <brendand> elopio, so merge that with AP trunk
[14:36] <elopio> brendand: remove the skip, reintroduce the inheritance dark magic
[14:36] <elopio> there are some app tests that fail then. I don't know which ones, chris is the one who knows.
[14:38] <fgimenez> elopio, brendand this should be removed from trunk's head, right?
[14:41] <elopio> fgimenez: I think that the idea would be to make a branch for it, make sure that all autopilot selftests pass, and then run the gatekeeper job with that branch.
[14:41] <elopio> then check for the new gatekeeper errors related to inheritance. Make an autopilot selftests for that error, and fix it.
[14:43] <elopio> fgimenez: do you have the vpn set up?
[14:44] <fgimenez> elopio, i think so, let me try to launch it
[14:44] <fgimenez> elopio, how do we reintroduce the inheritance? just removing the skip doesn't make any test fail
[14:45] <elopio> fgimenez: hum, so that test is not good.
[14:45] <elopio> fgimenez: I just know part of this story, veebers knows more.
[14:46] <elopio> fgimenez: about building autopilot, I think you should join #ubuntu-ci-eng
[14:47] <elopio> I added a row in the spreadsheet, and then sil2100 assigned a silo to me.
[14:47] <elopio> on this page http://people.canonical.com/~platform/citrain_dashboard/#?q=autopilot you will see the build button.
[14:48] <elopio> this explains this weird process: https://wiki.ubuntu.com/citrain/LandingProcess
[14:49] <fgimenez> elopio, ok thanks a lot
[15:02] <fgimenez> elopio, wait, i was executing the unit tests
[15:11] <fgimenez> elopio, but yes, it makes no difference to execute python3 -m autopilot.run run autopilot.tests.functional.test_introspection_features with or without the skip...
[15:12] <fgimenez> elopio, http://paste.ubuntu.com/10773819/
[15:12] <elopio> fgimenez: I remember it was failing, but it started failing suddenly.
[15:12] <elopio> I don't know what caused the failure.
[15:17] <fgimenez> elopio, the previous paste was with the skip, this is without http://paste.ubuntu.com/10773866/ and test_customised_proxy_classes_have_extension_classes passing
[15:24] <elfy> good afternoon quality people :D
[15:25] <elopio> fgimenez: can you please leave a comment on the card for veebers?
[15:26] <elopio> jfunk: can we work on the inheritance card before the prioritization meeting?
[15:27] <fgimenez> elopio, ok will do
[15:29] <nuclearbob> pitti: I'
[15:29] <nuclearbob> m getting an error on adt-run but executing the test script manually works
[15:29] <pitti> nuclearbob: hey
[15:30] <nuclearbob> I'm grabbing the error now, it's about a (
[15:30] <nuclearbob> http://pastebin.ubuntu.com/10773980/
[15:30] <nuclearbob> and I'll grab the test script
[15:32] <nuclearbob> pitti: test script is here: http://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-power-tests/trunk/view/head:/debian/tests/tc-powermeter-05 and if I copy it over and execute it, it works
[15:37] <pitti> nuclearbob: do you actually execute it, or run it through bash?
[15:37] <pitti> nuclearbob: because, "function foo()" is a bashism
[15:38] <nuclearbob> pitti: oh right, thanks, I'll change the shebang line, I had just been running it through bash
[15:38] <nuclearbob> I'll remember to check that in the future
[15:38] <pitti> $ sh -n /tmp/tc-powermeter-05
[15:38] <pitti> /tmp/tc-powermeter-05: 28: /tmp/tc-powermeter-05: Syntax error: "(" unexpected
[15:38] <nuclearbob> yep
[15:38] <pitti> nuclearbob: or just drop "function" :)
[15:38] <pitti> nuclearbob: (it seems fine otherwise)
[15:39] <nuclearbob> pitti: yeah, checkbashisms reports nothing when I remove that
[15:41] <jfunk> elopio: yes, actually can you join a call?
[15:41] <elopio> nuclearbob: are you ok being the vanguard from 20:00 UTC to 23:00 UTC ?
[15:41] <jfunk> elopio: we're postponing the prio meeting to tmw
[15:41] <elopio> jfunk: ok.
[15:41] <elopio> jfunk: the fixing sanity call?
[15:42] <nuclearbob> elopio: I'd prefer to do earlier than that if that's feasible, that's 7 PM for me
[15:42] <elopio> nuclearbob: 17:00 UTC - 20:00 UTC ?
[15:43] <nuclearbob> elopio: that works fine except for today, when I have an appointment :) I can do 20:00-23:00 tonight and then 17-20 after that, if that's okay
[15:43] <elopio> nuclearbob: don't worry about today.
[15:43] <nuclearbob> elopio: okay. I'll pick up 17-20 UTC starting tomorrow
[15:47] <elopio> jfunk_: brendand: tomorrow the calendar is full of stakeholder meetings.
[15:48] <elopio> you moved it to the same time as the unity one.
[16:08] <rhuddie> elopio, do you have a moment to go over the webbrowser test failure?
[16:08] <elopio> rhuddie: yes I do.
[16:09] <rhuddie> elopio, excellent. This is the issue: http://pastebin.ubuntu.com/10771280/
[16:09] <rhuddie> elopio, there seems to be some sort of race condition when clearing the address bar text in the browser when entering a new url
[16:09] <rhuddie> it doesn't happen every time
[16:10] <elopio> rhuddie: is it like you clear it, and then the page is loaded, and then it's filled again?
[16:11] <rhuddie> no, the browser loads with the start page, and then we try to enter in a new url. the helpers then clear the address bar before the new url is entered.
[16:12] <rhuddie> elopio, here is the test code: http://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/trunk/view/head:/ubuntu_sanity_tests/tests/test_with_webbrowser.py#L130
[16:13] <elopio> rhuddie: yes, but I'm wondering why the field is filled after we have cleared it.
[16:13] <elopio> is it because we are clicking in the wrong place?
[16:14] <rhuddie> elopio, well, it is filled by default with the start page.
[16:14] <elopio> rhuddie: it starts filled, then we cleared.
[16:14] <elopio> but the clear is failing.
[16:15] <rhuddie> yes the clear is failing
[16:15] <rhuddie> elopio, but currently the clear is not called directly in the test code, but by the uitk helper which enters the text
[16:16] <elopio> rhuddie: yes. What I don't get is why you say there's a race condition.
[16:16] <rhuddie> elopio, well, because sometimes it works, and sometimes it doesnt :)
[16:17] <elopio> rhuddie: but this is sequential. For some reason we are failing to clear it.
[16:17] <elopio> I'm wondering if it's because we are not hiting the button.
[16:17] <rhuddie> elopio, here is the method pressing the button: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_textfield.py#L74
[16:18] <rhuddie> elopio, it seems like there has been some workaround added previously for checking the visible property
[16:19] <rhuddie> elopio, I've tried adding some waits to make sure the visible property is set true, but it did still fail in the same way
[16:19] <elopio> rhuddie: you lost me.
[16:20] <elopio> when the field has a clear button but it's not visible, the field is clicked to show it.
[16:20] <elopio> what workaround are you talking about?
[16:22] <rhuddie> elopio, that seemed a bit strange to me, that the text field had to be pressed again to show to show the clear button? but may be its not
[16:22] <elopio> rhuddie: it's not clicked again. It's if you try to clear it when it's not focused, so it's the first time you click it.
[16:23] <elopio> there could be something wrong in there, like we make something visible that hides the clear buttonl
[16:23] <elopio> rhuddie: do you have a screenshot of the error?
[16:24] <rhuddie> elopio, what happens is that the existing url is highlighted, and not deleted as expected.
[16:24] <elopio> rhuddie: that probably means that the clear button is not clicked.
[16:26] <rhuddie> elopio, there is another way to fix the issue, which is to call browser.main_window.address_bar.clear() before we try to enter the url in the test case.
[16:26] <elopio> it could be because we try to click it too fast, before it's visible. But that's not likely. We could add a clear_button.visible.wait_for(True), just to be sure about it.
[16:27] <elopio> or it could be because we are clicking the wrong coordinates, which is also unlikely.
[16:27] <elopio> rhuddie: that would do the same.
[16:27] <elopio> just with less ifs.
[16:27] <rhuddie> elopio, I tried adding the visible.wait_for(True), but it still failed in the same way
[16:28] <rhuddie> elopio, interestingly it didn't fail when I added the address_bar.clear() to the test. - I ran it for ages but it didn't fail once.
[16:29] <brendand> rhuddie, what about waiting for enabled?
[16:29] <elopio> rhuddie: what would be nice is to understand why that works.
[16:29] <brendand> rhuddie, it could potentially be disabled for a period of time
[16:30] <elopio> what would be different is that on write we call autopilot focused_write.
[16:30] <elopio> if we call clear directly, the focused doesn't happen.
[16:30] <rhuddie> elopio, yes I tried enabled too, but same result
[16:31] <elopio> rhuddie: so, that could be a valid workaround, but I would prefer to dig deeper and understand what's wrong calling clear from write.
[16:31] <rhuddie> elopio, yes, I was trying to understand why the helper was not working correctly...
[16:32] <elopio> rhuddie: can you debug the issue? like putting a breakpoint, call clear, and the field doesn't get cleared?
[16:33] <rhuddie> elopio, yes, I'll do some more digging.
[16:42] <elfy> wxl: you know your image is not booting on vb?
[17:28] <wxl> elfy: say what?
[17:30] <elfy> couple of days ago there was a pwconv /etc/passwd issue
[17:30] <elfy> today I got something else - booting it now for screenshot
[17:30] <elfy> but - image not for today currently
[17:30] <elfy> http://i.imgur.com/eBDaXxd.png
[17:31] <elfy> just thought I'd let you know
[17:32] <wxl> elfy: which image?
[17:33] <elfy> 64bit
[18:23] <ianorlin> elfy on my desktop the amd 64 image booted and installed with manaul partitoning fine
[18:23] <ianorlin> except for the eject part which all are broken
[18:24] <elfy> maybe a vb thing then - I don't look particularly deeply for other flavours unless asked or needed
[18:24] <elfy> and yea - that's still fubar
[18:24] <wxl> elfy: what vbox version?
[18:24] <wxl> ianorlin: did you use kvm?
[18:25] <ianorlin> I installed on bare metal
[18:25] <wxl> oh!
[18:25] <elfy> wxl: 4.3.26
[18:25] <wxl> elfy: from the repos or upstream?
[18:26] <elfy> repos thiscycle it seems
[18:27] <wxl> elfy: no i mean vbox
[18:27] <wxl> or maybe that's what you meant :)
[18:27] <ianorlin> ok I will try vbox on this new bare metal install don't want the two hypervisors conflicting
[18:27] <wxl> i don't use repo versions so i'm not sure i can back you up at all
[18:27] <wxl> danke ianorlin make sure to grab from the repos
[18:27] <wxl> and confirm you have 4.3.26
[18:28] <elfy> repos for vb wxl
[18:34] <ianorlin> yes I have that version and virtualbox fails
[18:34] <wxl> awww fooey
[18:34] <wxl> elfy: ↑ might want to check the other flavors more completely
[18:34] <elfy> I am SOO glad this vbox issue isn't seen in Xubuntu
[18:35] <elfy> last cycle was one after the other for us :p
[18:35] <wxl> not in xubuntu? how weird!
[18:35] <elfy> wxl: I would expect other flavours have QA leads
[18:36] <elfy> I just happened to see this for you when ianorlin asked me something the other day so followed along a while
[18:36] <elfy> well we did see it a while back, so did Mate
[18:37] <wxl> elfy: so can you email the list?
[18:37] <elfy> list?
[18:38] <wxl> the ubuntu quality list
[18:38] <ianorlin> ok also nocompcache isn't a magic fix
[18:38] <elfy> wxl: ack - but it'll be later on
[18:38] <wxl> k
[18:39] <elfy> wxl: what for though?
[18:39]  * ianorlin will try an alternate with vritualbox
[18:43] <elfy> wxl: did it - I'll likely not remember now I've made you aware of the issue and won't look again
[18:54] <wxl> elfy: i suggested it since other leads may need to know. mean they'll probably figure it out, but …
[18:55] <elfy> well I would have expected them to know I guess - it's been about on lubuntu for 2 or 3 days
[18:56] <elfy> anyway - such is life
[18:56] <wxl> yep
[18:58] <elfy> and a bunch of questions make me wish I'd not done it lol
[18:58]  * wxl ducks :)
[18:58] <elfy> I'd rather wxl mailed the list :p
[18:59] <wxl> forgive me for i have sinned elfy :)
[18:59] <elfy> especially as I've got a real pita issue with my isp
[19:00] <elfy> my mails to mailing lists - get marked as spam here - so I have to go webmail to unmark them :|
[19:00] <wxl> i'll reply
[19:13]  * elfy ponders lubuntu being upstart-less, wonder if that's part of this 
[19:18] <elfy> made you aware - my job is done :p