#ubuntu-autopilot 2015-02-02
<doug5> balloons, do you know when veebers is around more or less?
<balloons> doug5, yes here in another hour he'll be about
<doug5> ok cool
<balloons> doug5, he wanted to talk to you about your mp
<doug5> we have to fix the doc
<doug5> veebers, hello!
<veebers> hey doug5 hows it going?
<doug5> veebers, not bad, thx...you?
<veebers> doug5: a little tired but otherwise good :-)
<doug5> veebers, I have updated the mp, but I'm unsure what to do with the docstrings
<veebers> doug5: oh cool, I'm just in a meeting at the moment. I'll take a look after that and get back to you :-)
<doug5> veebers, sure, np :)
<thomi> barry: got a second?
<barry> thomi: i got a third and fourth too
<thomi> great - you might need them :D
 * barry hides
<thomi> barry: I made a quick and dirty package for selenium here: https://launchpad.net/~canonical-platform-qa/+archive/ubuntu/selenium/+packages
<thomi> and the problem I'm having is that the distropatch doesn't apply
<thomi> it's listed in d/patches/series
<thomi> and the patch itself seems find
<thomi> *fine
<thomi> but in the binary package, the patch doesn't get applied
<thomi> any ideas?
<barry> thomi: in the package source, you can `quilt push -a` and `quilt pop -a` without error or warning?  sometimes (i forget in which instances) if a patch has fuzz, quilt will not be happy
<thomi> hmm
<thomi> no, I can't
<thomi> ok, so the patch needs changing. how do I do that?
<barry> thomi: here's how i do it:
<barry> `quilt push -a` until it stops with an error
<barry> `quilt push -f` to "force" the broken patch to apply
<barry> fix the patch (e.g. <edit> <edit> <edit>)
<barry> `quilt refresh`
<barry> `quilt pop`
<thomi> which file am I editing?
<barry> `quilt push` should now have no errors, if it does, rinse/repeat
<barry> thomi: the files in the quilt patch that fail to cleanly apply
<barry> quilt should tell you which ones that is
<barry> and since patch(1) is used,you'll have .rej files for those
<thomi> hmm, I see a .rej file, but I'm not sure how to fix it
<barry> thomi: that i can't help you with since it's specific to the patch.  it's like resolving a conflict in a $vcs
<thomi> I assume it's because the offsets in the .patch file are wrong
<barry> could be
<barry> generally go through each hunk and manually apply them to the file
<thomi> how do I know what the correct offsets should be?
<thomi> ahh ok
<thomi> then how do I get those changes out of the source tree and back into a patch?
<barry> you don't have to.  once the source tree is happy, `quilt refresh` will fix the top quilt patch on the stack
<thomi> ... how does it know how to do that? magic!
<barry> yep
<barry> `man quilt` talks about this i think
<thomi> barry: awesome, thanks
<barry> thomi: good luck!
<thomi> thanks. last thing I need to do now is get it building python2 & 3 packages, which shouldn't be too hard
<barry> thomi: esp. if it's setup.py based.  pybuild ftw!
<thomi> yup
<rpadovani> balloons, I don't want to be herald of bad news, but your fix for calculator app didn't work :S
<rpadovani> https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/bigNumber150122/+merge/248183
<rpadovani> balloons, TBH I'm not sure the bug is in autopilot tests, but maybe (and I underline maybe because I'm pretty confused) in the packaging / files inclusion. Sometimes seems the external file isn't loaded
<balloons> rpadovani, :-(
<balloons> rpadovani, it definitely helped fix the tests locally for me.. as for bignumber, :-( I thought for sure i was running big number though
<rpadovani> balloons, it works also for me, this is the strange, and this is why I'm thinking about package issues
<rpadovani> balloons, look to this
<rpadovani> http://(864)930-0890:8080/job/generic-mediumtests-vivid/921/testReport/junit/ubuntu_calculator_app.tests.test_main/MainTestCase/test_operators_precedence/
<rpadovani> TypeError: Cannot call method 'format' of undefined
<rpadovani> seems mathks isn't loaded
<rpadovani> buttons don't count here
<balloons> rpadovani, ohh that's not the same issue.. the app neve rlaunched
<balloons> rpadovani, I re-ran, maybe it was a fluke
 * rpadovani cross fingers
<thomi> barry: are you able to take a peek at lp:~thomir/+junk/selenium-packaging and advise? It seems like pybuild doesn't honor the data_files kwarg in setup.py?
<thomi> the build fails with 'error: can't copy 'py/selenium/webdriver/firefox/x86/x_ignore_nofocus.so': doesn't exist or not a regular file', but that file exists in the source tree, and is referenced in setup.py's data_files section
<thomi> so I think it should work?
<rpadovani> balloons, this time 4 fails instead of 5, but 3 out of 4 are different tests :D
<rpadovani> https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/bigNumber150122/+merge/248183
<rpadovani> balloons, actually, it want to was a :S, not a :D
<rpadovani> I'm quite confused
#ubuntu-autopilot 2015-02-03
<balloons> rpadovani, that time it failed though.. before the app never launched
<balloons> rpadovani, wow, look at how slow it runs ;-) http://(864)930-0890:8080/job/generic-mediumtests-vivid/940/artifact/ubuntu_calculator_app.tests.test_main.MainTestCase.test_operation_on_infinite_number.ogv. Still these look correct. You'll have to change the asserts in the tests to match the new significant figures you calculate too
<MacSlow> Why are dash and unity8 just two small square windows when an autopilot-test is started on the desktop? What's missing to have them use the usual 40x71 GU dimensions?
<MacSlow> elopio, ^
<elopio> MacSlow: hum, that I don't know. Does the same happen when you do initctl start unity8?
<MacSlow> elopio, yes
<elopio> MacSlow: when I do that I get the two windows, with space enough for three columns of apps.
<thomi> hey barry, got time for me to hassle you about packaging *again*? :D
<barry> thomi: it's a brand new day, so sure!
<thomi> barry: so, I get one question a day? :D
<thomi> curses! did I just use it up?
<barry> bzzt!  that's two
<thomi> heh
<thomi> barry: so, I've used pybuild before several times, and never had this issue...
<thomi> selenium ships some binary files which are listed in the data_files section of setup.py
<thomi> but pybuild can't see them - I suspect because they're not copied into the temporary directory perhaps
<thomi> Any ideas? The branch I'm working from is lp:~thomir/+junk/selenium-packaging
<barry> thomi: make sure there's a MANIFEST.in file that names those data files, otherwise they may not get into the orig.tar.gz
<barry> that's always been what bites me
<thomi> ahhhh
<thomi> they're not :D
<thomi> barry: actually, they are, I missed them
<thomi> "recursive-include py/selenium/webdriver/firefox/x86 *.so"
<barry> thomi: so if you `python setup.py sdist` they end up in the .tar.gz?
<thomi> barry: yes
<thomi> barry: the error message I get is:
<thomi> error: can't copy 'py/selenium/webdriver/firefox/x86/x_ignore_nofocus.so': doesn't exist or not a regular file
<barry> oh, .so files.  those might be getting filtered out by other bits of the debian build tools.  `export DH_VERBOSE=1` in your d/rules file.  so it is (almost?) never correct to include .so files source packages, those just might be getting filtered out
<thomi> I assume that a .so counts as a 'regular' file - it's not a socket or anything
<barry> thomi: where do you get that error?
<thomi> I have verbose set, I don't see any filter messages
<thomi> let me pastebin, one second
<thomi> barry: http://pastebin.ubuntu.com/10041069/
<thomi> further up I get:
<thomi> warning: no files found matching '*.so' under directory 'py/selenium/webdriver/firefox/x86'
<thomi> which I guess is a sign of the root cause...
<barry> yep, i see that
<thomi> I assume that, if those files were being filtered there'd be some sort of log message?
<thomi> barry: I guess you're stumped too? Who else should I bug? I'm tempted to email the DPMT ML, but I suspect I'll get the "don't put .so files in your source package" answer :(
<barry> thomi: probably so.  but iirc there's a debian/binary-file-override-magic file that might do the trick.  right now i can't remember what it's called and am putting out some other fires :(
<thomi> barry: ahh, ok, no worries
<barry> thomi: debian-python@ is your best bet
#ubuntu-autopilot 2015-02-04
<balloons> veebers, a couple questions for you when you have a moment
<balloons> 1) when will autopilot land with the json build?
<balloons> 2) Are you ok with not having links to the source itself inside the api docs for the first iteration?
<veebers> balloons: OTP at the mo, will be with you in a bit
<veebers> balloons: 1.  I'll try get a card for next sprint(so next week)
<veebers> balloons: 2. No, as that would make the documentation unusable, and with no guarantee when it will be rixed
<veebers> fixed*
<balloons> veebers, heh, ok we should chat more about 2; but first an update on what's been happening. You may have noticed we pushed things out a week as mhall needed more time to implement. The source docs are not something they are willing to implement right now and would require much more work.
<balloons> veebers, we don't have to remove the static documents as soon as the initial import is complete; so we could keep those and refer to those until the import is done satisfactorily. That way at least the status quo is maintained
<balloons> does that help things?
<balloons> i would push to keep them until you are happy with the alternative
<veebers> balloons: sorry was distracted. The problem I have with that is then there are 2 versions of the docs available (one being broken). Also, what's the guarantee that it will get finished and we don't sit in a half finished state for ever?
<veebers> As long as there is a complete version of the docs around I can imagine there being less encouragement to get them done
#ubuntu-autopilot 2015-02-05
<balloons> veebers, can't argue with logic. But what's the alternative then? No implementation?
<balloons> I guess no implementation unless it includes source. You could let the work continue but keep it off the site.
<veebers> balloons: right, I would prefer it be released all working instead of potentially stuck with half a solution
<veebers> I"m not saying its likely to get only half done, but I'm aware priorities may change etc. which might push it to the edge of the backlog
<balloons> veebers, that is fair enough, so the work now needs to happen; and more work besides
#ubuntu-autopilot 2015-02-06
<doug5> balloons, hello!
<balloons> doug5, howdy :-)
#ubuntu-autopilot 2015-02-09
<gadago> hi all
<gadago> I'm trying to test out ubuntu openstack using the auto-pilot installer (I have maas up and running) but seem to have got stuck
<gadago> I'm at the "Bootstrapping Juju" part, my node boots just fine and the cloud-init script runs, but when it finishes, it just sits there and the auto-pilot install still says Bootstrapping Juju: xxx time elapsed couting up
<gadago> any idea?
<gadago> I've been following the guide here http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
<gadago> could anyone help me with the ubuntu openstack installer?
<gadago> no matter what install type i choose (Autopilot, Multi, Single) I can't get passed "Bootstrapping Juju"
<gadago> MAAS start the installer, etc, etc, seems to create network bridge for Juju, all seems to okay, but then just sits there at the login prompt
<gadago> the openstack installer just continues to say "Bootstrapping Juju"
<gadago> no idea what I'm doing wrong
<balloons> gadago, probably best to ask in #juju or #ubuntu-server
<gadago> balloons, thanks
<balloons> your welcome, good luck!
<balloons> bah; you're
#ubuntu-autopilot 2015-02-11
<MacSlow> Greetings folks!
<MacSlow> I'm wondering which package does provide the python-bits so importing ubuntuuitoolkit works... the obvious choices don't seem to help
<elopio> MacSlow: ubuntu-ui-toolkit-autopilot
<MacSlow> elopio, already solved... thanks
<elopio> MacSlow: remember to ping ubuntu-qa, we all have it configured to highlight the message.
<MacSlow> elopio, ah... good to know thx
#ubuntu-autopilot 2015-02-17
 * balloons awaits to pounce on veebers :-)
<thomi> anything I can help with?
<balloons> thomi, just curious about the autopilot release.
<balloons> Also, I assume https://code.launchpad.net/~acerisara/autopilot/move-to-object/+merge/247524 can be top-approved?
 * balloons pounces
<balloons> good morning veebers. Once you've had ample time to awaken and sort yourself, ping me
<veebers> balloons: sure, I'll ping you after the standup meeting that happening soon :-)
<thomi> balloons: sorry, got distracted
<thomi> balloons: veebers: I'm disturbed by the deletion of the docstring in that MP
<thomi> but... it's veebers's baby now, so I'll let him decide
<veebers> thomi: I'm not sure which docstring you're talking about
<thomi> in https://code.launchpad.net/~acerisara/autopilot/move-to-object/+merge/247524
<balloons> thomi, ohh right, the see blah
<balloons> is there a more elegant way to do it, while still avoiding double documentation?
<thomi> are te two methods identical?
<balloons> mm.. I suppose it should actually have a docstring.. a unique one
<balloons> meh
<thomi> yeah
<thomi> and make that function public, and give it a docstring too
<balloons> I was thinking it was a duplication, but it's not purely one
<thomi> that way the docstring can say "moves the cursor to the center point of the object. See `autopilot.input.get_center_point` for  details on how the center point is calculated'
<veebers> thomi: can I get your opinion on this bug please? https://bugs.launchpad.net/autopilot/+bug/1422797
<ubot5> Launchpad bug 1422797 in Autopilot "MIR refuses the app to connect" [Undecided,New]
<thomi> looking
<veebers> I'm pretty sure it's not an autopilot issue (we haven't changed anything recently)
<veebers> balloons: hey, what's the haps?
<balloons> veebers, hey.. just wondering how the autopilot release was progressing
<thomi> veebers: well, it might not be an issue in the autopilot _code_ :D
<thomi> but it's still an issue with autopilot
<veebers> balloons: currently it's not. Are you blocked on it not being released?
<thomi> veebers: elopio's suggestion sounds plausible - I'd recommend following that up (make sure it's the case), and then maybe talk to the mir team about it
<balloons> veebers, the apdocs re-work is blocked on it persay, but it would be nice
<thomi> if elopio is correct, then this will affect users as well
<veebers> thomi: ack, thanks
<veebers> balloons: is or isn't?
<thomi> balloons: <pedant>"per se"</pedant> :P
<thomi> <-- studied latin
<veebers> balloons: can it wait until next week?
<balloons> veebers, wow, my sentence. No it is not blocked. The task to get the docs autoupdating is
<balloons> and yes, as mhall is heading to scale for the rest of the week, it matters not this week :-)
<veebers> balloons: right, ok :-) The blocked task, is that something that I'm blocking or elsewhere?
<veebers> thomi: did balloons make a bit of a 'fox paz' ;-)
<thomi> haha
<balloons> thomi, yes.. wow, I don't usually type persay
<balloons> odd thing that
<thomi> you can butcher French all you like :D
<balloons> more fun with sentences ^^
<veebers> (balloons this is where you say you did it on purpose to annoy thomi :-))
<veebers> balloons: Autopilot release is on the backlog for the sprint starting next week. So early next week we'll have a release
<veebers> sorry again for the delay
<balloons> veebers, I'm pretty sure the IOU balance is still in your favor.
 * balloons debits 1 IOU from veebers account
<balloons> and yes, messing with thomi is good fun. It's especially good fun now that he is on CI, and thus his ability to hit me back is lessened :-)
<thomi> *cough*
<thomi> you like having your CI jobs turned off for inexplicable reasons, do you? :P
<veebers> heh, 'why are my CI jobs failing with the error 'Incorrect use of latin words' all of a sudden
<veebers> elopio: hey, if you get time this week can you confirm if fixtures.Timeout will do what want for this bug? https://bugs.launchpad.net/autopilot/+bug/1408374
<ubot5> Launchpad bug 1408374 in Autopilot "It's not possible to define a time out per test" [Undecided,New]
#ubuntu-autopilot 2015-02-18
<MacSlow> rhuddie, hey there... what a common causes for a failure like http://pastebin.ubuntu.com/10291809 ? The test-code in question is http://bazaar.launchpad.net/~macslow/unity8/shellRotation/view/head:/tests/autopilot/unity8/shell/tests/test_rotation.py
<MacSlow> rhuddie, I tried comparing it with test_lock_screen.py, but don't see any obvious difference in terms of test-setup. Any help is greatly appreciated!
<rhuddie> hey MacSlow, I would say from that it looks like  your self._proxy object has not been created correctly
<MacSlow> rhuddie, ah ok... I'll look into that... thanks
<rhuddie> MacSlow, no prob, good luck
<balloons> doug5, did you see the comments about your mp yesterday?
#ubuntu-autopilot 2015-02-19
<balloons> doug5, might be best to have it in here
<doug5> balloons, k
<balloons> as thomi and veebers discussed it. I left our irc comments in the mp. basically, thomi was wanting docs for the method
<balloons> https://code.launchpad.net/~acerisara/autopilot/move-to-object
<doug5> yes but the doc is duplicated
<balloons> right, so it was a little confusing, but I agreed we should say something as it's not literally the same method is it./
<balloons> ?
<veebers> Ugh, I really need to get that review done. Sorry peeps
<doug5> so the doc at `autopilot.input.Mouse.move_to_object` is ok
<doug5> and the doc at move_to_object should say "look at get_center_point to see how bla bla bla"
<doug5> strange, because it is how I did in first place, but then there was the issue that doc in private modules is not generated IIRC
<doug5> do you know how to generate the doc? This way I can check how it will look like
<balloons> doug5, yes, is it not well spelled out in the readme?
<doug5> ops, sorry :)
<balloons> doug5, no, I was just wondering / wanting to make sure it was
<balloons> so it's not a rtfm situation :-)
<balloons> didn't mean to imply that
<doug5> balloons, no worries :D
<thomi> doh - I missed that conversation ^^
#ubuntu-autopilot 2015-02-20
<MacSlow> How can I print the QML-type of a proxy-object with AP?
<MacSlow> There are calls like get_children_by_type() but nothing like get_type() or something similar.
<balloons> MacSlow, hmm
<balloons> using print_tree will print everything of course, including the qml type
<MacSlow> balloons, yeah I know... but that's just too much to deal with in a handy fashion
 * balloons is thinking
<balloons> ideally you would avoid using xpath directly
<MacSlow> balloons, a what? "xpath"
<balloons> so if you get_properties that doesn't do what you want?
<MacSlow> balloons, sadly not
<MacSlow> balloons, initially I hoped it would spit out the qmlitem-type too... but as far as I can tell that call just dumps real QML-item-properties to stdout
<balloons> right, but it doesn't give you th objectpath?
<MacSlow> balloons, nope... here's an example of the output... http://pastebin.ubuntu.com/10327157/
<MacSlow> balloons, I could try to work-around with get_parent() and get_properties() but that's far from elegant
<balloons> MacSlow, yep that certainly works
<balloons> I'm curious about get_classname_from_path
<balloons> anyways, I suspect it's something worthy of adding support for in autopilot
<MacSlow> balloons, first I've to get the ap-test written... the nice to have's is for people who actually know stuff... which I'm not one of
<MacSlow> the get_parent() work-around got me what I wanted... but *sigh*
<balloons> MacSlow, :-) Sure, what did you want it for?
<balloons> the idea that you need it, when it seemingly hasn't come up in the past is interesting
<balloons> elopio, btw, am I missing something, or is there no way to get the qmltype returned ^^?
<MacSlow> balloons, trying to figure out how to get hold of orientation-related properties of the shell, when unity8 was started with the fake sensors
<elopio> hum, it's the class name, isn't it?
<balloons> elopio, yes classname
<MacSlow> elopio, I'm just writing up an email with all the info I could gather to ask you and rhuddie about this
<elopio> MacSlow: cool, because I don't get what you are trying to do :)
<MacSlow> elopio, I'm might try a few more things still
<MacSlow> elopio, the eMail will make things more clear... hopefully :)
<balloons> I think it would be easier enough to add a method for it. The thing is, seeing as no one has ever needed it, I too am wondering why MacSlow does. In theory, you are selecting and always know the qmltype
<MacSlow> balloons, I'm anything but an AP-expert... I'm just the one left do write that particular test :)
<MacSlow> s/do/to
<balloons> MacSlow, can you report a bug against autopilot for what you are wanting?
<MacSlow> balloons, well if you folks say it's never come up as a request before, I'm hesitating - as a AP-noob - to spoil the feature request-list with it
<balloons> MacSlow, lol, it's worth filling
<MacSlow> balloons, against which lp-project? Just plain autopilot?
<balloons> https://bugs.launchpad.net/autopilot/+filebug
<MacSlow> balloons, https://bugs.launchpad.net/autopilot/+bug/1423988
<ubot5> Launchpad bug 1423988 in Autopilot "Add a get_qml_type() to autopilot.introspection" [Wishlist,New]
<MacSlow> balloons, too brief?
<balloons> MacSlow, another sentence would be useful in the description. You want to be able to say proxy_object.get_qml_type().. However, it should be generalized.. so perhaps get_type_name
<balloons> you can leave it as-is; let the ap guys decide implementation of generic or not
<MacSlow> ok
#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
#ubuntu-autopilot 2016-02-18
<Razva> is there any way to tail a juju deployment via autopilot? I cannot really find any logs of the ingoing installation...
<dobey> Razva: i presume you're asking about openstack stuff. you probably want #ubuntu-openstack. this channel is for the automated testing framework named autopilot
#ubuntu-autopilot 2016-02-19
<Razva> any idea if MAAS + Autopilot will create a NAT for the LAN nic, or should I manually create it?
<dobey> i guess my response to that was ignored
<balloons> heh. We need something in topic honestly
<dobey> "This is not the autopilot you are looking for."
#ubuntu-autopilot 2016-02-22
<Razva> seems that Autopilot doesn't "wants" to setup a 5 node OpenStack cluster. everything is "green" but Cinder fails to deploy. we're digging in the logs but we cannot find anything relevant. any hints?
<Razva> [ERROR] Failed to upload leases: 'str' object has no attribute 'mac' < any hints?
<balloons> veebers, ping
<veebers> balloons: hey, what's the haps?
<balloons> hey -- it's about this channel. Sadly openstack-autopilot is ALSO a thing, and it's 80% of what I see in here now
<veebers> hah, right :-P
<balloons> poor dobey has to keep telling people to join another channel for openstack issues
<balloons> I tried to fix the topic, but I can't. Probably need someone from ubuntu-irc.
<veebers> balloons: if the traffic is low enough perhaps we could move the (original ;-) )autopilot to -quality?
<balloons> but if we're going to go that fair, might I suggest what we are doing in here?
<balloons> well.. I mean; it's interesting openstack users find this channel, lol, because AP users never did!
<veebers> balloons: I'm not sure I understand, is that a query about my suggestion to go to a different channel and fold this one?
<balloons> I kid, only slightly
<veebers> heh ^_^
<veebers> yeah
<balloons> My ramblings amount to a two questions: 1) How can we let people know we are talking about autopilot the testing tool, not openstack? 2) The bigger question. What should we do with this channel?
<veebers> balloons: for the 2nd question I think we need to ask; how much conversation re: autopilot happens here?
<balloons> So I guess since you jumped at shutting down the channel at the first hint of things, it sounds like perhaps you aren't too attached?
<veebers> if it's a lot/enough then we should discuss improving the channel. If it's not enough perhaps we should consider conceding and consolidate somehow
<balloons> I would say very litle happens now. It's always somewhere else. Since the tool itself isn't seeing thriving development, all AP conversations revolve around specific tests
<balloons> those conversations then occur in teams channels
<veebers> right, which is the feeling that I get
<balloons> but first -- can you fix the topic to explain it's not openstack-autopilot?
<balloons> that's the simple fix
<veebers> I can try :-)
<balloons> I see you and thomi as the only ones with powers in here. And thomi has control actually
<balloons> so we can't do anything too fancy
<balloons> without him anyway
<veebers> right
<dobey> heh
<dobey> it's the same damn person
* veebers changed the topic of #ubuntu-autopilot to: Autopilot documentation can be found here: http://developer.ubuntu.com/api/autopilot/python/1.5.0/ | latest tutorial video is: https://www.youtube.com/watch?v=jkLtbmQxXYc
* veebers changed the topic of #ubuntu-autopilot to: Autopilot (not openstack-autopilot :-) ) documentation can be found here: http://developer.ubuntu.com/api/autopilot/python/1.5.0/ | latest tutorial video is: https://www.youtube.com/watch?v=jkLtbmQxXYc
<veebers> hmm, topic needs work
* veebers changed the topic of #ubuntu-autopilot to: Autopilot testing tool (not to confused with Openstack Autopilot). Documentation can be found here: http://developer.ubuntu.com/api/autopilot/python/1.5.0/ | latest tutorial video is: https://www.youtube.com/watch?v=jkLtbmQxXYc
<veebers> balloons: let me know what you think
<balloons> perhaps tell them to join #ubuntu-server for openstack questions
<dobey> i think there's an #ubuntu-openastack even
<dobey> or at least, there is certainl a just #openstack channel
<balloons> yes there is #openstack also
<dobey> how the hell people don't find that, i have no idea
<balloons> I guess I'd list those

{'channel': 'ubuntu-autopilot', 'month': 2}