#ubuntu-autopilot 2015-02-23
<veebers> thomi: hey, you have a moment?
<thomi> veebers: depends
<thomi> what's up?
<thomi> (btw, I've semi-officially started in CI now)
<veebers> thomi: ah awesome, congrats :-)
<veebers> thomi: I would like to bounce something off you. In autopilot, the change that we made for the extension classes in the proxy object creation (def _try_custom_proxy_classes) wasn't perfect
<veebers> I see in the gatekeeper testing a bunch of errors that seem to stem from CPOs that multi inherit.
<veebers> I tried what I thought would be a fix, but I'm getting really odd issues, for instance, the validate_dbus_object method gets swapped out at some stage to something completely different
<veebers> thomi: so I was hoping for some advice on how to further debug this.
<thomi> heh... multi-inheritance almost certainly won't work for CPOs
<thomi> why do people feel the need to multi-inherit CPOs?
<veebers> current culprit: class ContactListPage(_common.PageWithHeader, _common.PageWithBottomEdge):
<thomi> yeah you can't do that
<thomi> whoever did that needs a slapping :D
<thomi> PageWith*** are both CPOs?
 * veebers double checks
<thomi> if you want to do that, make those classes mixin classes
<veebers> thomi: affirm
<thomi> but you can only derive from your emulator_base exactly once in the class heirarchy
<veebers> thomi: hmm, ok. So now I have a couple more queries. Is there a way that we can determine that a cpo is attempting to use multiple inheritance? (so we can provide a sane warning)
<thomi> one sec
<veebers> secondly, this is now a larger issue as it means that application test code needs to change (because up until now this seems to have worked).
<thomi> veebers: to answer your first question... yes, with a metaclass you can
<thomi> you can walk up the inheritance tree and inspect everything there
<thomi> WRT your second comment - it might have worked, FCVO "work"
<thomi> I doubt, for example, you could have passed the child class as an object to select_*
<veebers> ah right, walk the tree set a flag when finding something inherited from the CustomProxyBase, error if we attempt to set again or something
<thomi> something like that
<veebers> ok, makes sense
<veebers> thomi: ok, so my current plan is to back out the fix that we did re: the extension classes, get the doco stuff and a couple of other fixes in
<thomi> remind me what our fix was, and what precipitated it?
<veebers> thomi: Then I'll get a proper fix for the base class stuff and send out a communication to the teams to make sure that the code is correct and ready
<veebers> thomi: this fix, where the extension classes weren't always being used in a class:
<veebers> https://code.launchpad.net/~veebers/autopilot/fixing-extension-classes-and-test/+merge/246962
<veebers> The proposal I had today was pretty much: __bases__ = tuple(set(base).union(set(extensions)))
<thomi> veebers: why doesn't that work?
<veebers> thomi: my proposal? I'm not entirely certain, but it's causing issues with the address book test I'm using to confirm (my failing test passes with it too)
<thomi> what's the error message?
<veebers> AttributeError: Class 'ContactListPage' has no attribute 'open_contact'
<thomi> what's the difference in __bases__ with, and without your proposal?
<veebers> thomi: the odd thing I'm seeing is that the validate_dbus_object method code changes so that possible_classes is always an empty list so never attempt to use the CPO version
<veebers> I suspect something is happening earlier on that dirties something to make it misbehave
<thomi> how do you mean 'changes'? a different VDO function is called?
<veebers> thomi: yeah
<thomi> what's the new function it's calling?
<veebers> thomi: If I do: print(inspect.getsource(proxy_class_dict['ContactListPage'].validate_dbus_object))
<veebers> the first time around it's fine, but after that it's calling something like: return (name == b'webbrowser-app' and . . .
<veebers> thomi: fyi: http://paste.ubuntu.com/10365925/
<veebers> that's 2 calls to _try_custom_proxy_classes (the ?? note the different calls) for the path "......PageStack/PageWrapper/ContactListPage"
<thomi> this is *exactly* what I'd expect to happen when multiple inheritance is used
<thomi> veebers: can you check the content of __bases__ in each case?
<veebers> thomi: in a good or bad way? I'm not sure where the webapp stuff is coming from as this is the addressbook app tests and CPOs
<thomi> I bet __bases__ will reveal all :D
<veebers> thomi: hmm, yeah sure. Give me a couple of minutes to hack that up and get details
<veebers> thomi: also, if you're EOD we can pick this up tomorrow if you like
<thomi> I'll be on for a bit longer
<veebers> gah, now it's refusing to work at all :-| Sorry, just a couple more minutes :-)
<veebers> thomi: looks like you were right :-) http://paste.ubuntu.com/10366010/
<veebers> s for source, b for bases, 3 calls there in the log
<thomi> are you really surprised? :P
<veebers> nope
<thomi> so, someone's messing up __bases__ causing your MRO to go haywire
<thomi> there's only like 2-3 places where that can happen
<thomi> so I don't think it'll be hard to find
<thomi> I suspect that new code that gets the bases is to blame
<veebers> thomi: the new code being the stuff that I added today?
<thomi> veebers: if not that, then in the same general vicinity, yeah
<thomi> but I didn't mean to disparage your code :P
<veebers> thomi: the order of __bases__ matters right, that's what the MRO is?
<thomi> veebers: the order matters, yeah
<thomi> the MRO is more than that though
<thomi> the rules are somewhat non-trivial
<veebers> thomi: heh, I didn't see any disparaging there
<thomi> but for our purposes, the CPO-parent should be first
<veebers> ok, so I need to do more than just set union the 2 bases ther
<thomi> everything else (mixin classes) later
<thomi> well...
<veebers> yeah, that's what I had in mind. I'll hack around on that
<thomi> you probably won't have any problems, but ideally, yeah
<veebers> thomi: sweet, I'll work on that now. Thanks for the help :-)
<thomi> no worries
<thomi> I think tomorrow I'll withdraw myself from qa-related IRC channels BTW
<veebers> thomi: ah ok, it won't stop me bothering you for help though ;-)
<thomi> heh
#ubuntu-autopilot 2015-02-24
<veebers> thomi: hey, if you have a moment, Further to yesterdays discussion I made the changes and ran into MRO jexceptions with the existing tests, so I need to work on this further. Current plan is to back out the code that was added for this and get the rest of autopilot landed
<thomi> OK. I don't know what yor other constraints are, but i think that's possibly a mistake
<thomi> I mean - it's all in your head now, it'll be twice as hard to fix later
<veebers> thomi: the reason I suggest this is I think that its more work than I finish in a day, so I want to get the release with other things out the door (as well as sprint work(
<veebers> But I'll hold off for now perhaps, see if I can't get this other work out the way then solve this
<thomi> veebers: it's up to you, but surely this is part of the sprint?
<veebers> thomi: not offically, I screwed that up badly. Currently in a single week sprint
<thomi> veebers: then you really shouldn't be looking at it at all, surely?
<veebers> right, which is partially the reason for my above statement (finish the in progress landing) but I shouldn't even be doing that
<veebers> email sent. Ugh I need to get better at adhering to cards and getting stuff planned for a sprint :-\
<balloons> veebers, morning! how's about that autopilot release? I know it's been back and forth
<veebers> balloons: err, I started it, there is an issue that needs fixed, just sorting it out now (I screwed up having this as part of the sprint initially)
<veebers> balloons: so its happening, I just need to fix some things up
<thomi> veebers: do you have any idea how many of the autopilot test suites require dependencies that aren't covered by the standard set of ap packages?
<veebers> thomi: no idea off the top of my head sorry
<thomi> veebers: but...more than 0, right?
<veebers> thomi: I'm sure more than one, window-mocker for instance
<veebers> s/instance/one/
<veebers> thomi: what details do you need, the number or a list of deps?
<thomi> veebers: ideally, what % of ap test suites need non-default dep packages installed
<thomi> but... a rough estimate is fine
<veebers> thomi: when do you need it?
<veebers> thomi: oh wait, do you mean autopilots own test suites or for the applications test suites?
<thomi> the latter
<thomi> application test suites
<thomi> sorry :D
<veebers> hah, right well I'll take a look later, I need to have something fdor lunch right now
#ubuntu-autopilot 2015-02-26
<veebers> thomi: hey, I know that you've changed teams already, but can you do me a favor? Can you review/approve this MP so that I can unblock the current landing for AP?
<thomi> sure, link me?
<veebers> oops
<veebers> https://code.launchpad.net/~veebers/autopilot/revert-ext-class-fix-for-now/+merge/251025
<thomi> the name makes me sad already
<veebers> The current plan is to revert this, get the current stuff landed and getting the actual fix for this issue is on the backlog of the projects team up (so I hope to get that on the books next week)
<veebers> thomi: aye, I knew that it would, I'm not happy about it either
<thomi> so, you're going to release with the CPO extension class bug ?
<veebers> thomi: right, the current fix doesn't actually ffix it in the wild
<veebers> i.e. with the fix a _bunch_ of tests fail, without the fix they pass
<veebers> then next week we'll be working on getting the proper fix in plae
<veebers> place*
<thomi> so it's not a fix, my point is, if you do that you're releasing a known bad autopilot
<veebers> thomi: right, but it's an issue that already exists in autopilot
<thomi> ok
<veebers> we're releasing an autopilot that doesn't have a fix for that _yet_
<veebers> it's not the optimal position to be in, but I didn't realise that it was a bigger issue until this sprint was already underway
<thomi> so why release at all?
<thomi> (approved, BTW)
<veebers> thomi: cool thanks.
<veebers> thomi: To release the doc improvements (incl the enablement of the json for doc publishing) now
<thomi> oh, is that work done?
<veebers> heh, enablement :-P I like making words up
<veebers> thomi: For the publishing? Not complete but needs these changes to go forward
<veebers> thomi: see, you've only just left and the quality of the autopilot code is already going downhill ;-)
<thomi> lol
<thomi> anyway, that's inaccurate, it's just not going uphill :D
<veebers> ^_^
<MacSlow> rhuddie, elopio: how can I make sure an AP-test is run against a locally compiled unity8 from within the source-tree?
<rhuddie> MacSlow, I'm not entirely sure, but you might want to look at: http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/tests/autopilot/unity8/__init__.py#L75
<rhuddie> seems to look in a particular path for the unity8 binary in the source tree
<MacSlow> rhuddie, if that's the only way, I'll use that
<elopio> MacSlow: I think you have a make task in your project.
<elopio> like make-autopilot. It's documented on the README or CODING file.
<MacSlow> elopio, I know these bits of info... but I still don't seem to get the local unity8 being executed
<MacSlow> elopio, that's the reason I was asking
<elopio> MacSlow: I almost never change things in unity8, last time I did it was months ago. mzaanneti or saviq should know.
<MacSlow> elopio, ok
<elopio> there is a way, and I think it's to run the build script, get into the build dir, and make autopilot in there.
<elopio> but I'm not really sure about the steps.
<Saviq> MacSlow, you need "make install"
<MacSlow> Saviq, I did
<Saviq> MacSlow, then PYTHONPATH=tests/autopilot autopilot run foo
<Saviq> MacSlow, should run the tests on the local build
<MacSlow> Saviq, that's what I use
<MacSlow> Saviq, but when I let it dump the qml-item tree the source: line for the shell is Shell.qml where it should be OrientedShell.qml
<Saviq> MacSlow, what makes you say that it runs the wrong unity8 though?
<Saviq> MacSlow, -vv will be verbose and say what is launched etc.
<MacSlow> Saviq, no wonder I've problems trying to grab objectName="shell"
<MacSlow> Saviq, -vv not for autopilot?!
<Saviq> MacSlow, yes, for autopilot
<MacSlow> Saviq, as a parameter for run?!
<Saviq> MacSlow, autopilot -vv run foo
<MacSlow> Saviq, autopilot and autopilot3 only spit out version information with this
<Saviq> MacSlow, right, sorry, yeah, autopilot run -vv foo
<MacSlow> Saviq, tried that in the meantime too :)
<Saviq> MacSlow, and what makes you think it's trying to run the wrong binary?
<MacSlow> Saviq, the fact that there's no single qml-item with objectName="shell", which is the one used for the OrientedShell.qml
<Saviq> MacSlow, that doesn't sound like proof enough, what does the autopilot log say about which BINARY is used?
<MacSlow> Saviq, which would be written where?
<MacSlow> Saviq, I only know of the stuff in ~/.cache
<Saviq> MacSlow, "Starting job unity8 with arguments..."
<Saviq> MacSlow, on your console
<Saviq> MacSlow, it's the output from autopilot run -v
<MacSlow> Saviq, I don't have that in the output of autopilot (tried 1.4.0 and 1.5.0)
<Saviq> MacSlow, pastebin your whole console output please
<Saviq> with the command you used
<MacSlow> Saviq, http://pastebin.ubuntu.com/10430561
<Saviq> MacSlow, and if you run any of the existing tests? I tried unity8.shell.tests.test_lock_screen.TestLockscreen.test_can_unlock_pin_screen
<Saviq> MacSlow, most likely you're not using the base testcase that actually takes care of setting the right binary
 * MacSlow tries...
<Saviq> MacSlow, tests/autopilot/unity8/shell/tests/__init__.py
<Saviq> you want to inherit from tests.UnityTestCase
<MacSlow> Saviq, doing that
<MacSlow> Saviq, the issue seems to be the the args passed to restart_unity() from process_helpers.py
<Saviq> MacSlow, is it working for the previous tests?
<Saviq> like do you get the correct BINARY mentioned in the log if you're running one of the previous tests?
<MacSlow> Saviq, yeah... for e.g. one of thre greeter-tests it spits out a very long option-list from process_helpers.py which has the "BINARY=..." bit in it
<MacSlow> Saviq, and i nmy case it's only 'QT_LOAD_TESTABILITY=1', and nothing else
<Saviq> MacSlow, so look at the other test and see what it's doing differently than you
<MacSlow> Saviq, yup... fyi http://pastebin.ubuntu.com/10430933/
<veebers> thomi: are you keen to approve another ap mp for me? I need to find a replacement :-)
<thomi> veebers: maybe, but you really need to start asking people in QA
<veebers> thomi: fair enough, I'll do that now
<thomi> veebers: maybe save me for when others don't have the necessary experience to reviwe the code?
<thomi> veebers: like, introspection internals, for example
<veebers> nuclearbob, alesage, elopio: Could I get a review please? Just an updated changelog for the current release (so we get something sensible out of it)
<veebers> thomi: sure, makes sense to me. Sorry to bother you, it's muscle memory :-)
<thomi> heh, no worries.
<thomi> veebers: want to review my launchpad branch? :P
<veebers> lol, point taken. But I would take a shufti just out of interest
<thomi> will let you know when the diff is generated
<nuclearbob> veebers: the 1.5.0+15.04.20141031-0ubuntu1 looks a little funny to me
<veebers> sweet
<veebers> nuclearbob: oh, so that'll be coming from 1.5 when I merged it back into trunk
<nuclearbob> veebers: the same changelog is under five people, and elopio is named twice
<nuclearbob> veebers: ah, okay
<veebers> nuclearbob: to clarify I merged the changelog from 1.5 back into trunk then added the topmost entry
 * veebers updated MP desc
<nuclearbob> veebers: ah, okay.  Sounds reasonable to me, then
<veebers> nuclearbob: if you're cool with that do you mind approving the mp? :-)
<nuclearbob> veebers: done
<veebers> sweet ,cheers
<thomi> veebers: https://code.launchpad.net/~thomir/launchpad/devel-fix-editemails-link/+merge/251176
<veebers> thomi: very cool. Ah, what's it like writing non-pure python3 code again?
<thomi> veebers: it's actually not too bad
<thomi> veebers: but zope is mental
<veebers> ^_^
#ubuntu-autopilot 2015-02-27
<rpadovani> balloons, o/ any chance? :-)
<balloons> oi?
<balloons> rpadovani,
<rpadovani> balloons, hey :-) A friend asked if the configuration of ubuntu jenkins server is available somewhere
<rpadovani> So who is the better one to ask to, if not you? :-)
<balloons> rpadovani, ohh my.. what specifically are they after?
<balloons> you can get access to all the scripts that CI uses, but if you are wanting to replicate there setup atm, I don't think it's an easy task
<rpadovani> balloons, study, I think, he's an ubuntu member. Well, I think scrpts are a good start, where I can point him?
<balloons> rpadovani, lp:ubuntu-ci-services-itself
<rpadovani> balloons, thanks you very much!
<balloons> but there's more. Best to ask specific questions about things he's interested in. Often you can view the jobs themselves and figure out where and what is running
<balloons> rpadovani, basically exploring https://launchpad.net/~canonical-ci-engineering will yield more
<rpadovani> balloons, okay, thanks :-)
<balloons> rpadovani, I know it's late so enjoy your evening.. but are all the tests needed for calculator filed as bugs or implemented?
<rpadovani> balloons, afaik, yes. We tried to report every time we implement a feature a bug for autopilot
