#ubuntu-autopilot 2014-08-02
<Monkiko> Hello I have a question about getting started with autopilot testcase writing.
<Monkiko> I'm following the instructions on https://wiki.ubuntu.com/QATeam/ContributingTestcases/Autopilot and the first requirement for Autopilot is to sudo apt-add-repository ppa:autopilot/ppa . It's not working for me. Is this outdated?
#ubuntu-autopilot 2014-08-04
<elopio> barry: https://code.launchpad.net/~canonical-platform-qa/dialer-app/py3autopilot-sleep/+merge/229483
<elopio> that solves the old error that only happens on your branch. We have a couple of new ones in mako, but they are from trunk.
<elopio> I'll look at them today.
<barry> elopio: great!  i'll merge that into my branch and re-push.  hopefully we're nearly there. :)
<elopio> barry: we are always nearly there, that's what's frustrating about this branch :)
<barry> elopio: there is that :)
<barry> elopio: still almostly nearly there ;)
<elopio> barry: yes, but now I'm almost sure it's not your branch the cause of the failures.
<barry> elopio: phew :)
<elopio> so you are almostly nearly done :)
<barry> :-D
<elopio> ping veebers: I'm curiours about the new autopilot release. Is it happening soon?
<elopio> *curious
<veebers> hey elopio, well we have a silo and running gatekeeper tests, but the results from the image aren't that sane, so it makes it hard to confirm that autopilot hasn't regressed anything
<veebers> elopio: I'll be checking results again soon, although I'm not sure if much has changed :_\
<elopio> veebers: from the run #197, the only one that looks weird is the one on the toolkit.
<elopio> with so many errors on the toolkit, I would prefer to release autopilot and get screenshots to be able to diagnose them quickly, even we get one or two regressions.
<elopio> let me know if I can give you a hand testing the silo.
<veebers> elopio: ack, I'll sort that out this morning. CHeers
<elopio> thanks.
<veebers> elopio: you around still?
<elopio> veebers: I am here.
<veebers> elopio: ^_^ hey, if you also agree that the test failures I see on the gatekeeper are expected and match those on the smoke dash then I can change autopilot release to tested (test report here: http://pastebin.ubuntu.com/7955749/)
<elopio> veebers: unity8 has been stable for a while now. Those 5 failures shouldn't be there.
<veebers> elopio: that's from Run 193 right? that was from last week, they don't appear in the most recent 2 runs
<elopio> veebers: ah, ok.
<veebers> elopio: (there is a lot of text to take in on that 'report' put there are 3 gatekeeper runs-worth  there)
<elopio> veebers: do you have a phone with the silo?
<elopio> it would be great if you could run the toolkit test that failed. That one is not expected either.
<veebers> elopio: not setup right no, I would have to flash to latest etc.
<veebers> elopio: It might be faster for me to run the gatekeeper job to just run the uutk tests, that way we have a report too
<elopio> veebers: I have just flashed the latest one. i can give it a try.
<veebers> elopio: I'll do both
<elopio> veebers: no, the toolkit tests take like 40 acolon@example.com.
<veebers> elopio: ack, let me know if you want me to run the gatekeeper
<veebers> elopio: ah ok
<thomi> veebers: when you get a moment, perhaps later this week, could you please check why this isn't landing? https://code.launchpad.net/~vorlon/autopilot-qt/split-qt4-qt5-binaries/+merge/229378
<veebers> thomi: sure thing
#ubuntu-autopilot 2014-08-05
<elopio> cgoldberg, nuclearbob: I'm going to merge the change that landed into archive for autopilot yesterday.
<elopio> and then update the merge proposal for new new landing on the silo.
<nuclearbob> elopio: seems reasonable to me
<cgoldberg> sounds greek to me :)
<elopio> ping veebers
<elopio> hello.
<elopio> I was trying to push the autopilot release, but it got complicated.
<veebers> elopio: hey sorry was OTP, what's the issue, doesn't sound good :-\
<elopio> veebers: it's not bad. It's just that a changeset that's not on trunk or on the 1.5 branch is on the archive.
<elopio> so we need to merge it before landing. But when I was going to do it I got confused, I'm not sure how you are using trunk so I didn't know in what branch to do the merge.
<elopio> this is the changeset: http://launchpadlibrarian.net/181532211/autopilot_1.5.0%2B14.10.20140716-0ubuntu1_1.5.0%2B14.10.20140716-0ubuntu2.diff.gz
<veebers> elopio: ugh, that happened last time too :-( we use lp:trunk as our development branch (i.e. day to day changes reviewed and merged to it) and then release into lp:autopilot/1.5
<veebers> it's not a perfect system as we have a branch or two that are bottom approved but can't top approved as they will be merged into trunk and thus released without meaning to
 * veebers looks
<veebers> elopio: as that's already in archive, I would just merge it directly (I'm pretty sure that's what I did last time)
<elopio> veebers: yes, it already has results on the dashboard, so we don't need to test again.
<veebers> elopio: So I'm pretty sure what I need to do is merge that changeset into trunk, push it and rebuild the silo, yes?
<elopio> veebers: I think merge that change into 1.5
<elopio> because the changelog shows one more entry that's only on 1.5, not on trunk.
<elopio> that's where I get stuck and prefered to wait for you.
<veebers> elopio: rats, I'm not sure then because then that change won't be in trunk
<veebers> elopio: let me ask someone
<elopio> I thought that if you merged it with the one you are landing, it would get to trunk at some point.
<elopio> but yeah, sounds problematic.
<thomi> veebers: just push to both
<thomi> or push to 1.5, and merge back to trunk
<thomi> and then go ask Steve nicely if next time he could please prepare a MP for any changes to the AP packaging
<veebers> thomi: sweet, merging back to trunk sounds easiest, cheers
<veebers> elopio: right, that changeset now exists in trunk and 1.5, what needs to happen now to proceed the release work you were doing?
<elopio> veebers: somebody from ci needs to publish the package.
<elopio> oh, wait, you need to rebuild the silo I think
<veebers> elopio: cool, I can rebuild now
<elopio> thanks veebers.
<veebers> elopio: rats, now I have to sort out a changelog of my own for it to proceed
#ubuntu-autopilot 2014-08-06
<robru> thomi, hey, you want to merge my memevent branch asap?
<thomi> robru: yes please!
<robru> thomi, k, the thing is, my jasmine-unit test branch is a prerequisit, and it's unreviewed.
<thomi> link me?
<robru> thomi, not sure if I should merge that, or resubmit without it
<thomi> merge it
<robru> thomi, https://code.launchpad.net/~robru/uci-engine/jasmine-unit-testing/+merge/228229
<robru> thomi, ok, will merge. wouldn't mind a 'lgtm' ack on the mp though
<thomi> ok, just reviewing this one ^
<thomi> robru: first one approved
<thomi> robru: one thing, shouldn't it be 'KB' for kilobyte?
<robru> thomi, ok, it's merged.
<thomi> 'b' == bit, 'B' == 'byte'
<robru> thomi, uhhh...
<thomi> and is it a KB or a KiB?
<robru> veebers, is it kilobits or kilobytes? ^^
<thomi> ... or kibibytes?
<veebers> robru, thomi ugh, let me re-check now
<veebers> comparing the results of smem-tabs gives me '618980' without units and '604.6M' with  units
<veebers> also,  '316' and  '316.0K'
<thomi> OK, so the correct unit is 'kiB'
<thomi> or KB, if you want to ignore SI
<thomi> but certainly not 'kb' or 'K'
<thomi> and not 'kB', which is 1000 bytes, not 1024
<robru> thomi, veebers sorry I have company over one sec
<robru> thomi, ok, it's pushed to trunk. didn't get time to look at chris g's thing today because I was so swamped with everything.
<robru> thomi, you should probably do a local deployment before going live with IS, that jasmine branch had a lot of big changes.
<thomi> robru: OK, I'll try and get around to doing a deployment. even bvetter would be if veebers got juju setup
<robru> veebers, make sure you run `mkdir -p /usr/local/bin`. juju completely falls over without any sort of useful error messages if that directory happens to be missing on your system. stymied me for an entire month.
<veebers> o_0 nice
<robru> veebers, yeah there's some deep dark corner of juju where it tries to make a symlink there, but does so without checking if the directory exists first. and if the direcotry doesn't exist, the symlink fails, and then the whole thing falls over
<robru> but I really gotta go, i have company over.
<barry> nuclearbob: \o/  * Remove python2 compatibility code from autopilot.
<nuclearbob> barry: yeah, I've been working on that one since Malta
#ubuntu-autopilot 2014-08-07
<elopio> ping barry: do you know how to call the python3 pep8 binary?
<barry> elopio: good question! doesn't look like python3-pep8 has a /usr/bin script
<elopio> barry: I'm calling it like this: python3 -m pep8 .
<elopio> but I'm not sure if I can use that in a debian/rules file
<barry> elopio: that's probably fine!
<elopio> awesome. barry: are you a motu?
<barry> elopio: i'm a core dev :)
<elopio> barry: in order to get a package to the archive the wiki says I need the approval from two motus, but I guess two core devs are just as good.
<elopio> barry: could you take a look at https://code.launchpad.net/~canonical-platform-qa/ubuntu-autopilot-tests/motu/+merge/229905 when you have some time?
<barry> elopio: i'll put it in a tab :)
<elopio> thanks. No need to hurry as the other reviewer won't be back until tomorrow.
#ubuntu-autopilot 2014-08-11
<balloons> elopio, remember this old branch? https://code.launchpad.net/~dpm/ubuntu-filemanager-app/run-ap-from-out-of-source-build/+merge/217510 We've hit the problem again about the best way to run tests inside the build environment as a developer.
<balloons> I think I'm coming around to the mp's way of doing it..
<elopio> balloons: I'm not sure what you mean, that's an english phrase I don't fully understand.
<elopio> do you mean you like the idea of searching for the build dir, or that you like the idea of passing it as a parameter ?
<balloons> elopio, hehe.. sorry about that. I'm trying to say, I think what david originally suggested, using the cmakepluginparser, is the way to go
<elopio> I still don't agree. I think that while developing things we should always call the cmake autopilot task to run the tests.
<elopio> but we always can do both.
<elopio> if there's a BUILD_DIR environment variable, use it.
<elopio> if there is not, then we can try to find it or run the installed one. Of that part I'm not really worried atm.
<elopio> balloons: out of curiosity, what are the problems you are facing now?
<balloons> elopio, well I'm running into the old hardcoded local source path issue.. It's a bit of the setup code we've copied about everywhere, but never really standardized beyond, you should build in tree and layout your project this way
<balloons> folks are using make and building out of tree.. it fails in this case
<balloons> elopio, is there a project that uses cmake autopilot successfully atm?
<elopio> balloons: I've started following dobey's advice about CMake passing the build path on unity-click-scope
<elopio> I like the way it works. But we still need some more fancy things, like being able to select which tests to run.
<balloons> my concern with shoving it into cmake now is cmake build configs are reserved for mad scientists :-)
<balloons> lol.. but seriously, I'll go check out what you did
<elopio> balloons: it's really simple in this case, a lot more than querying the file.
<elopio> http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/autopilot/CMakeLists.txt#L16
<elopio> BUILD_DIR=${CMAKE_BINARY_DIR}
<elopio> then the logic on the launch method is also simplified
<elopio> http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/autopilot/unityclickscope/test_click_scope.py#L135
<elopio> if BUILD_DIR exists, use the binaries from that dir.
<elopio> if it doesn't, just call the installed ones.
<elopio> well, I think it's simpler than dpm's solution. But that might be because I like it best and not being impartial.
 * balloons looks
<balloons> elopio, hmm.. \
<balloons> I do like setting / reading a builddir env var
<balloons> ok, I'll try this
<elopio> balloons: I would prefer to pass arguments to autopilot instead of env vars, but this works for now for me.
<elopio> what I would like to do is to standardize the way we launch apps. But it's a little hard if we are not able to stabilize the tests.
<elopio> now that dialer app is going to be python3, that's going to be my sample app.
<elopio> balloons: would you help me to set up autopkgtests for dialer-app?
<balloons> elopio, yes should be REALLY simple to do so
<balloons> yes, we mentioned in david's original mp my preference for passing an arg to autopilot, but I digress
#ubuntu-autopilot 2014-08-17
<kurain> hey all
<kurain> Ihow to use autopilot for calling slots of qt class?
<robotfuel> kurain: you just call it like,  shell.slots.showHome()
<robotfuel> kurain: Most of the time if you're calling a slot it should tested at a lower level most likely with qml or qt unit tests.
<robotfuel> kurain: the only time I can think of the need of calling slots in autopilot tests is to test custom proxy objects.
* veebers changed the topic of #ubuntu-autopilot to: #ubuntu-autopilot Autopilot documentation is at http://developer.ubuntu.com/api/devel/ubuntu-14.10/python/autopilot/ | latest tutorial video is: https://www.youtube.com/watch?v=En1MaDDp9_8
<veebers> cheers thomi
* thomi changed the topic of #ubuntu-autopilot to: #ubuntu-autopilot Autopilot documentation is at http://developer.ubuntu.com/api/devel/ubuntu-14.10/python/autopilot/ | latest tutorial video is: https://www.youtube.com/watch?v=jkLtbmQxXYc
#ubuntu-autopilot 2014-08-18
<elopio> ping barry: hey, the package ubuntu-experience-tests has been on the upload queue for a while
<elopio> https://launchpad.net/ubuntu/utopic/+queue
<elopio> can you give it a push?
<barry> elopio: ENOPERM
<elopio> barry: oh, ok. I think pitti has.
<elopio> I missed him today. I'll send him an email.
<barry> elopio: +1
<thomi> barry: hey, got a moment?
<barry> thomi: hi, what's up?
<thomi> barry: WRT python3 & openid...
<thomi> barry: I found this, which is what I want:
<thomi> https://github.com/necaris/python3-openid
<thomi> but I've noticed that the tests fail *if* you have python3-lxml installed on your system
<thomi> so my question is: how do I build my package (I currently use 'bzr bd') so it builds in a clean environment without that installed?
<thomi> python3-lxml is needed by ubuntu-desktop, so I don't want to remove it
<barry> thomi: might be better to figure out what's wrong upstream and provide a pull request
<thomi> hmmmm
<barry> (i don't see that issue reported in their tracker)
<thomi> no, me neither
<barry> then you could include the patch as a quilt patch until upstream releases a fixed version
<thomi> The error I get repeatedly is:
<thomi> ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
<barry> hmm. i'd have to try to reproduce it but it sounds like there are some sample data bugs (i.e. no encoding declared) or data objects that should be bytes instead of strings
<barry> iow, a real upstream bug
<thomi> yeah
<barry> always better to fix it first as far upstream as you can ;)
<thomi> ok, managed to get it downt o one single failing test
#ubuntu-autopilot 2014-08-19
<thomi> barry: Got a second?
<barry> thomi: yep
<thomi> barry: yesterday I managed to fix all the failing tests in python3-openid!
<thomi> I made a pull request, and it was merged last night \o/
<barry> thomi: awesome!
<thomi> the upstream dev also mentioned that they'll do another release soon, so that's nice
<thomi> right, that's the good news :)
<thomi> the bad news is that...
<thomi> During a package build, I still get a failure:
<thomi> http://pastebin.ubuntu.com/8091792/
<barry> thomi: how are you building the package?
<thomi> barry: which looks to me like it's related the the encvironment the package is built in not having some env var that sets the default codec or something
<thomi> barry: with sbuild
<thomi> I make a src package with 'bzr bd -S' then build it with 'sbuild -Ad utopic python3-openid_3.0.2-1.dsc'
<barry> thomi: yep, that's it.  there's a file that's expecting a default system encoding, which on your desktop is probably some UTF-8 encoding.  there's no default encoding in sbuild
<barry> *really schroot environment
<thomi> barry: that's odd though, is that the traceback doesn't match the source code
<thomi> when it complains about this:
<thomi>   File "/Â«PKGBUILDDIRÂ»/openid/test/trustroot.py", line 76, in pyUnitTests
<thomi>     test_data = test_data_file.read()
<thomi> the upstream line is actually:
<thomi> oh wait
<thomi> OK, it *does* match
<barry> :)
<thomi> but the complete code is this:
<thomi> test_data_file_name = os.path.join(here, 'data', 'trustroot.txt')
<thomi>     test_data_file = open(test_data_file_name, encoding='utf-8')
<thomi> I thought that since it was specifying an encoding in the open call, we should be good?
<barry> yes, should be!
<thomi> hmmmm
<thomi> OK, that traceback really *doesn't* matcht he source code - it's off by one line, which is what confused me
<barry> any possibility there's a quilt patch mucking things up?
<thomi> there is a quilt patch, which is the changes I made to make the tests pass, but that should be applied when the tests are run, right?
<thomi> barry: perhaps you could try? lp:~thomir/+junk/python3-openid is the packaging branch...
 * barry tries
<barry> reproducible.  entering chroot
<thomi> I realise now that I should have made sure I could build the package before submirring the PR. ahh well
<barry> hang on
<barry> in the chroot, i see:
<barry>     test_data_file = open(test_data_file_name)
<barry>  
<barry> no encoding
<barry> do you perhaps have a quilt patch that isn't included in the branch?
<thomi> wha?
<barry> yep
<thomi> no, there's only the one patch
<barry> 3.0.2
<thomi> oooooh
<thomi> wait
<thomi> I bet it's in upstream, but not in the release
<barry> that would explain it!
<thomi> let's see...
<thomi> hmmm, nope, that works
<thomi> oh wait
<thomi> yeah, that's it :)
<thomi> barry: so I guess I just make tmy quilt patch include that line, until upstream does a new release?
<barry> thomi: yes.  take a look and see if they have a revision that matches just this change.  often you can just import upstream's changeset as the quit patch
<barry> *quilt
<thomi> hmmm
<thomi> ok
<barry> if not, just make sure the description or other patch headers indicate that it can be dropped when upstream makes a new release
<thomi> barry: how's your git fu?
<thomi> using git annotate, I can see that that line was introduced in a separate commit, which is hopeful
<barry> thomi: so-so but improving :)
<thomi> the commit revno looks like 9770cb66 ?
<thomi> or is that something else?
<thomi> but I'm not sure how to ask diff to show me what was introduced in that commit
<barry> git doesn't have monotonic revnos like bzr, it has sha (1? 256?) hashes.  the above is a shorthand for the full hash
<barry> thomi: yeah, this is why i "love" git :(
<thomi> it looks like I can do: git diff <commit> <commit>
<thomi> but I'm not sure how to say "<commit> +1"
<barry> there are ^ and ~ involved i think
<barry> let me see if i have a git repo handy
<thomi> barry: got it:
<thomi> git diff 9770cb66..9770cb66~1
<barry> i think you can always just do `git diff -c <revision>`
<barry> yeah, that's it
<thomi> barry: can I blindly append one patch to another? or are there headers that can only happen at the top of the patch file?
<thomi> where 'patch' == 'the ouput from git diff'
<barry> thomi: you can append them.  the file is basically patch(1) compatible
<barry> usually i group them logically, i.e. here's all the stuff that fixes bug #12345
<ubot5> bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<barry> oops :)
<thomi> heh
<thomi> cool
<thomi> wow, isdn... blast from the past
<barry> thomi: the point being you want to make it easy for you later to just delete the patch when upstream releases a fix
<barry> i.e. when they fix bug #1
<ubot5> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<barry> \o/
<thomi> :)
<thomi> I love that the Ubuntu Malaysia LoCo team has taken it upon themselves to fix the bug
<thomi> hmmm
<thomi> that doesn't work
<thomi> barry: still around?
#ubuntu-autopilot 2014-08-20
<barry> thomi: i'm back from dinner now
<thomi> barry: so now the tests are failing in sbuild because they try and create a TCPServer, and that seems to fail in the chroot
<barry> thomi: using pybuild?
<thomi> I assume there's some restriction within an sbuild chroot about what network operations you're allowed to perform
<thomi> barry: yes
<thomi> it looked like it was unable to resolve 'localhost', so I'm retrying now with '+1-473-444-0812', but I suspect the real problem is a policy that prevents package builds from doing any network activity
<thomi> (which sounds reasonable to me)
<thomi> but I'm wondering if the best thing is to skip those tests during a package build, or if there's something better I can do
<barry> thomi: so by default, pybuild sets http{,s}_proxy to +1-473-444-0812:9 which is the discard port to prevent accidental attempts to download stuff from pypi.  usually that's fine, but if you do need to make localhost connections for tests, you want to override_dh_auto_test and unset those envars for the duration of the test
<barry> https://wiki.debian.org/Python/LibraryStyleGuide
<barry> (search for http_proxy)
<thomi> ahhhh
<thomi> awesome
<barry> so something like this i think works:
<barry> override_dh_auto_test:
<barry>    http_proxy= https_proxy= dh_auto_test
<thomi> cool, trying that now - thanks :D
<barry> np!
<thomi> barry: yaaay! A built binary package :)
<barry> \o/
<thomi> barry: I'll upload this to mentors, and maybe get you to +1 it?
<thomi> barry: then perhaps you can upload it firect to Ubuntu to save us some time?
<barry> :)
<barry> thomi: send me an email so i don't forget and i'll take a look tomorrow
<thomi> barry: will do, thanks
#ubuntu-autopilot 2014-08-21
<elopio> thomi: robotfuel told me to ping you about https://bugs.launchpad.net/autopilot/+bug/1268782
<elopio> I want to fix it, but he said that the pressed time will take longer on autopilot than on QML, and that you had some ideas.
<ubot5> Ubuntu bug 1268782 in Autopilot "tap method of Touch device doesn't have press_duration arg" [Undecided,New]
<thomi> elopio: you can't make it accurate, for sure
<thomi> just reading the bug now
<elopio> thomi: I know that, but I don't expect the difference to be more than 0.5 seconds.
<thomi> elopio: right, your proposed solution in the bug comments sounds sensible to me
<elopio> on qml it's unlikely they will make one response for a press of 1 second, and a different one for a press of 1.5
<thomi> from memory Chris had a MP that was good, but I objected to the test
<elopio> thomi: I was going to take over chris' mp and update it. I don't see your objections there.
<thomi> I probably got veebers to do the review
<thomi> yeah, testing it with a Qml app seems really awkward
<thomi> but I'll leave that to veebers, since he's the AP guy these days
<elopio> veebers: any suggestions of what kind of tests would you like? When I filed the bug, I was just thinking of using the fake sleep.
<veebers> hey elopio o/, let me read the scrollback quickly
<veebers> elopio: aye, I agree that testing that sleep was called as expected is an acceptable test.
<elopio> veebers: ack, I'll assign the bug to myself.
<veebers> elopio: autopilot doesn't guarantee millisecond responses (ui, out of process testing, dbus etc.)
<veebers> elopio: As soon as a test as a 'waiting for a potentially slow emulator' comment I get cautious
<veebers> elopio: awesome, thanks for resurrecting that and taking it on :-)
<elopio> that's fine as humans also can't have that precision. If there's a problem with the UI because we are waiting some more milliseconds than we should, that's a UI bug.
<veebers> elopio: exactly, and it would (should!) be covered by something that's not an autopilot test
<elopio> veebers: this is ready for your inspection
<elopio> https://code.launchpad.net/~canonical-platform-qa/autopilot/fix1268782-press_duration/+merge/231678
<veebers> elopio: sweet, i'm just on the move between offices at the moment so will take a look once I've re-setup
#ubuntu-autopilot 2014-08-22
<veebers> elopio: you around still? Quick question, difflines 110, 119: is there a reason you're doing it this way and not using make_fake_object method (from that same test file?)
#ubuntu-autopilot 2014-08-27
<elopio> veebers: the bamf process manager will not work with xvfb?
<elopio> hum, and I'm also having problems with ubuntu_upstart_launch
<veebers> elopio: Are you saying you're having issues with using autopilot under xvfb?
<elopio> veebers: yes. I'm trying to run the toolkit tests with autopilot3-sandbox-run
<elopio> the ones that use ubuntu_upstart_launch failed to launch
<veebers> elopio: hmm, I wonder if it's setting the environment variables as expected. I'm not sure oof the top of my head sorry, I don't have experience with the -sandbox-run script yet'
<elopio> and the ones that use launch_test_application fail because they use the process manager to resize the window.
<veebers> elopio: have you had it working in the past or is this a new attempt?
<elopio> veebers: it's the first time I try it.
<veebers> elopio: what are you running? I would like to give it a try
<elopio> veebers:
<elopio> bzr branch lp:ubuntu-ui-toolkit/staging
<elopio> cd staging
<elopio> qmake
<elopio> make
<elopio> source export_modules_dir.sh
<elopio> cd tests/autopilot
<elopio> autopilot3-sandbox-run -X -d ubuntuuitoolkit.tests.custom_proxy_objects.test_listitems.SwipeToDeleteTestCase.test_swipe_item_to_wrong_direction
<elopio> something l ike that.
<veebers> elopio: I'm pretty sure it's due to unity (and thus bamf) not running in the created environment, similar reason for the upstart issue. I'm just trying to confirm now
<elopio> I'm not sure what bamf is, but yes, it says no applications are running even when they are on the launch_test_application case
<veebers> hmm, I don't think I"m exactly right, but I'm on the right path
<elopio> veebers: without xvfb or xephyr we can't run autopilot autopkgtests, right?
<veebers> elopio: can I ask what you're using it for? I'm still poking around at the moment (re: the bamf stuff, I suspect the upstart stuff is a different ketle of fish)
<veebers> elopio: honestly I don't know much about the autopkg tests, but I would say you're correct
<veebers> elopio: that question of mine was directed in general, not your query re autopkgtests :-)
<elopio> veebers: I'm trying to start running the autopilot tests as autopkgtests. The toolkit team is the one that suffers more because they have too many tests, so I tried to start there.
<veebers> ah, right make sense
<veebers> thomi: who would a good person to talk to about bamf nowadays? It looks like there needs to be 'something else' added to use it within Xephyr
<thomi> huh? you shouldn't need to
<thomi> you're running unity 7, right?
<veebers> thomi: yeah I am, but it's not working as expected when using the autopilot3-sandbox script (which uses Xephyr & dbus-launch to create a new environment) so it's not using the same bamf connection as my desktop
<thomi> well no, it wouldn't
<thomi> but you also don't want it to, right?
<veebers> thomi: why wouldn't I? At the moment elopio is trying to use it to run tests, and it's failing for him because the process_manager (bamf) isn't working for him
<thomi> veebers: because you want bamf to match the nested apps, not the apps on your desktop
<thomi> so I suspect you're not running unity7 in your nested session
<thomi> or perhaps running u7, but not the bamfdaemon (although that should be auto-started, I believe)
<veebers> thomi: no you misunderstood (or I didn't exaplion well). You're right I don't want it to match the apps on my desktop
<veebers> it's the apps launched within the new newsted environment that aren't  showing up in bamf
<thomi> how do you know that?
<veebers> thomi:right, there is no unity7 within the nested X
<veebers> thomi: d-feet and ipdb
<thomi> how are you connecting to the nested dbus session with d-feet?
<veebers> from within my python dbugger I get os.environ['DBUS_SESSION_BUS_ADDRESS'] and plug that into d-feets 'connect to different bus'
<thomi> ok, so I don't think your apps will be mapped unless u7 is running
<thomi> but WRT your original question, I'd ask someone like Trevino or Stephen Webb
<veebers> thomi: right, I guess that's the answer we're looking for. The 'something else' is unity7 :-)
<thomi> I'm a little concerned that the toolkit tests need bamf :-/
<elopio> thomi: it shouldn't. But I want to resize the window and bamf is the only backend for that at the moment.
<veebers> thomi: ok, also; Ted G is the man to talk to about ubuntu-app-launch right? (elopio is also having issues with that using the sandbox)
<elopio> thomi: how could I resize an app on xephyr or xvfb without unity7 running?
<thomi> yes, tedg is libUAL
<thomi> elopio: why do you want to resize the app, and how do you do this on a device?
<veebers> sweet, cheers thomi
<elopio> thomi: I want to simulate the size the window will get on a device.
<thomi> elopio: ahhhh
<elopio> just for desktop runs. On the devices I don't do it.
<thomi> that's really nasty
<thomi> can't you set the window geometry when you launch it?
<elopio> thomi: no. ubuntu-launch-app doesn't know about geometries
<veebers> elopio, you could set the xephyr screen size
<elopio> that was ted's explanation.
<veebers> no wait, that doesn't affect the app
<thomi> elopio: well, this is a really nasty hack, and TBH I'm not surprised we're finding problems with it
<thomi> I don't understand why libUAL would have to know about *anything* in the command line parameters
<thomi> but there you go - that whole area is a huge ball of oddness
<elopio> thomi: it's a little bad. But shouldn't we be able to resize windows anyway?
<thomi> elopio: on a platform where that makes sense, sure, and you can
<thomi> elopio: but you're trying to do it on a platform that we don't support
<thomi> (i.e.- a raw X session, with no desktop manager)
<elopio> you are right, xephyr doesn't let me resize the app manually either.
<elopio> veebers: if I change the xephyr window size, the app is just scaled in it. It seems to me that the only way to do it is to pass the window size when launching the app.
<veebers> elopio: right, I redacted my suggested as soon as I said it, sorry :-\
<elopio> I could skip the device simulation scenarios for now. But we need the launch upstart working.
<elopio> veebers: martin put some insteresting things about upstart here: /usr/share/autopkgtest/setup-commands/ubuntu-touch-session
 * veebers looks
<veebers> elopio: where would I see that on my system? DO I need to install something else?
<elopio> veebers: sudo apt-get install autopkgtest
<veebers> ahh, makes sense
<veebers> elopio: right, it looks like there is some more details needed for upstart when using the sandbox script. Are you able to reuse the autopkgtest stuff somehow for what your doing?
<elopio> veebers: I'm trying to set up the autopkgtests on the package to then run them with that setup script to see what happens.
<veebers> elopio: ah ok, sweet. Let me know how it goes
<elopio> I'm understanding half of what I'm doing :) I'm collecting tons of questions for Martin.
<veebers> ^_^
<veebers> elopio: oh, thanks for update the touch duration branch of yours. Approved
<elopio> veebers: thanks to you for the review.
<elopio> veebers: the launch still fails with that set up.
<veebers> elopio: :-( Can you tell why it fails?
<elopio> veebers: it says the same thing as on xvfb, RuntimeError: Timed out while waiting for application to launch
<elopio> it just takes a lot longer to say that
<veebers> elopio: which part timed out? Is this autopilot, or the process manager or something else?
<elopio> http://paste.ubuntu.com/8155837/
<elopio> veebers: it's autopilot waiting for upstart to launch the app.
<veebers> elopio: are you able to write a simple example/script that launches an upstart app in Xephyr (without using autopilot)? We want to single out if it's autopilot or the upstart/dbus setup that's getting in the way
<elopio> let me read the man
<elopio> veebers: this seems to work
<elopio> $ Xephyr -screen 1280x1024 :1 &
<elopio> $ initctl set-env --global DISPLAY=:1.0
<elopio> $ ubuntu-app-launch dialer-app
<elopio> if you have the dialer-app package installed.
<veebers> elopio: what happens if you setup the "initctl set-env --global DISPLAY=:1.0" in the autopilot test? i.e. before the app is launched
<elopio> I'm trying
<veebers> hmm actually that's silly of me
<veebers> oh actually maybe not
<veebers> I was confusing ENV with the initctl set-env.
<elopio> veebers: the xephyr display started by autopilot is :5.0, but it doesn't work.
<elopio> it still fails to launch the app.
<veebers> elopio: do you see anything come up on the xephyr screen?
<elopio> veebers: nothing.
<elopio> oh, but this works.
<elopio> $ Xephyr -screen 1280x1024 :1 &
<elopio> $ initctl set-env --global DISPLAY=:1.0
<elopio> $ autopilot3 run ubuntuuitoolkit.tests.custom_proxy_objects.test_listitems.SwipeToDeleteTestCase.test_swipe_item_to_wrong_direction
<elopio> it's just the sandbox the one that fails to launch it.
<veebers> elopio: hmm, so you're saying that running that makes it work (i.e. the app appears on the xephyr screen)?
<elopio> veebers: yes.
<veebers> elopio: I would say that it's the dbus stuff breaking it then (as the sandbox script uses dbus-launch)
<veebers> elopio: you could prove that by editing the sandbox script to remove the dbus-launch part and running it, it will use your normal session bus but that's ok
<veebers> this isn't a solution, but some debugging btw :-)
<elopio> veebers: well, it would still miss the initctl set-env part.
<veebers> elopio: oh sorry, I meant to say add that in (in the sandbox script)
<elopio> veebers: yes. With the set-env and without the dbus-launch, the sandbox works.
<veebers> elopio: It looks like there needs to be more setup for ubuntu-app-launch to work with the different session bus, but isn't that what that script that you linked me does?
<elopio> veebers: I thought so. It could be that what failed on my adt-run execution was the missing set-env
<elopio> I can try, but that's going to take longer than what I'll remain awake. I'll leave it running.
<veebers> elopio: heh, let me know how it goes ^_^
<zbenjamin> hey guys
<zbenjamin> is there any way for me to wait for a Qt signal in a test?
<zbenjamin> balloons: ^ any idea?
<elopio> zbenjamin: there's a discouraged way to do it
<elopio> http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/introspection/qt.py
<elopio> it's undocumented and thomi keeps saying that we should remove it, because it almost always means that you are using autopilot wrong.
<elopio> what are you trying to do? Maybe we can find an alternative.
<zbenjamin> elopio: why is the QtSignalWatcher discouraged? and what is the correct way
<elopio> zbenjamin: when you are doing black box testing through the UI, you take the role of a real user.
<elopio> real users don't have access to signals. They need to be notified through the UI.
<elopio> so if you are waiting for something, there must be a visual clue for it.
<balloons> veebers, can I use something that is python 3.3+ only in autopilot?
<veebers> balloons: um, 3.3 is default in Utopic right?
<balloons> python3.4 I thought is default?
<veebers> balloons: ah, you might be right. Right so now autopilot is python3 and i utopic you can use what is default there (i.e. 3.4)
<balloons> awesome
#ubuntu-autopilot 2014-08-29
<m-b-o> Hi, I have a problem with ubuntuuitoolkit and the AppHeader proxy
<m-b-o> with "_get_action_button_in_overflow()" in particular
<m-b-o> sometimes the action is clicked, without a visible overlay
<m-b-o> which happens here: http://+1-473-444-0812:8080/job/generic-mediumtests-utopic-weather-app/lastSuccessfulBuild/artifact/ubuntu_weather_app.tests.test_settings.TestSettings.test_switch_wind_scale%20%28with%20mouse%29.ogv
<gerlowskija> I was looking at: http://unity.ubuntu.com/autopilot/tutorial/good_tests.html#scenarios...is there a way to specify that the scenarios are only used on some of the tests in the class? My understanding is that each test is run once for each scenario in the list. Is there a way to override that, or do tests that use scenarios and tests that don't alwa
<gerlowskija> ys have to be in separate classes?
<balloons> I was hoping barry would be around, but he's not.. Might be difficult to get an answer today.. holidays :-)
<gerlowskija> ok. I can always ask again later, nbd.
<balloons> https://pypi.python.org/pypi/testscenarios/
<cgoldberg> gerlowskija, offhand, I don't know of a nice way to selectively apply scenarios within a class.  But that smells to me like your TestCase classes are too big... generally you'd only group very similar tests into a class.
<cgoldberg> in that same guide, see 'Test One Thing Only', and 'Test Length' :)
<cgoldberg> gerlowskija, that's a good document btw.. I forgot that was part of AP docs
<gerlowskija> cgoldberg: haha fair enough.  I'm not against splitting classes, just wanted to make sure there wasn't some other best-practice I was missing.  Thanks for weighing in; I'll split the classes
#ubuntu-autopilot 2014-08-30
<hakermania> can someone eli5 to me?
#ubuntu-autopilot 2015-08-20
<tsdgeos> guys can anyone review https://code.launchpad.net/~aacid/autopilot/add_wait_for_proxy_upstart_launcher/+merge/268456 ?
<tsdgeos> or at least acknowledge its existance
<balloons> tsdgeos, howdy
<tsdgeos> balloons: hi
<balloons> that should be an easy review for veebers to do later
<balloons> tsdgeos, you need to run flake8 on the code first, so it passes the build
<tsdgeos> k
#ubuntu-autopilot 2015-08-24
<veebers> barry: Hey you around?
<veebers> barry: For wily, I'm in the process of getting this in: https://code.launchpad.net/~canonical-platform-qa/autopilot/fix-updated-flake8/+merge/268424
<veebers> barry: sorry for any miss-communication, I should have filed a bug but thought I would be able to get the fix in quickly.
<barry> veebers: ah :)
<barry> veebers: i think i have a working branch now too.  why don't you attach your to the bug and i'll do the same.  i'll leave it to you to reconcile any differences if needed.
<barry> *yours
<barry> veebers: and no worries.  thanks for working on a fix
<veebers> barry: sure thing, have done :-)
<barry> veebers: i'll unassign myself from it
#ubuntu-autopilot 2016-08-03
<siva> Hi. I am trying to deploy OpenStack on ubuntu 14.04 using canonical autopilot. I am following http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot. Selected âInstallâ to start building your cloud. I hope maximum the installation process will take 20 to 30 minutes. But for me it has been taking too much time. I started before 3 hours. Still installation process going on. Showing 1% done.
<siva> On selected hardware it deployed OS and bootstrapped Juju. All services installation in progress.
<siva> Why it was taking too much time.
<siva> Please tell me the reason if anyone familiar with this issue.
<siva> Where I can found cloud services installation logs?
<siva> Log details: http://paste.openstack.org/show/547811/.
#ubuntu-autopilot 2016-08-08
<Sina_Maleki> Hi all
<Sina_Maleki> Anybody here ?
#ubuntu-autopilot 2016-08-09
<Sina_Maleki> Hi friends
#ubuntu-autopilot 2016-08-12
<Moschops> Hi hi. Can anyone tell me what to do about "We don't seem to link to version 4 or 5 of QtCore. Unable to determine which autopilot driver to load. Autopilot introspection will not be available for this process." ?
#ubuntu-autopilot 2016-08-17
<sinamaleki> Hi all anyone here ?
#ubuntu-autopilot 2016-08-24
<ram_____> Hi all. How can I enable a customized charm as part of Ubuntu Autopilot installation? I mean How can we integrate our customized juju charm along with autopilot openstack deployment
<ram_____> Hi. Which version of Autopilot we should use to deploy Liberty OpenStack?
<ram_____> alex-abreu : Hi. Which version of Autopilot we should use to deploy Liberty OpenStack?
<alex-abreu> ram_____, I might not be the one you are looking for
<ram_____> alex-abreu : Ok. Thank you.
#ubuntu-autopilot 2016-08-25
<ram_> Hi. I want to develop a cinder-storagedriver  charm. And i want to integrate it with Ubuntu-autopilot . SO can I give input parameters like san IP, san user and san password from landscape autopilot UI?. Otherwise everything we have to hardcode into the charm. And different users for the same storage array have different credentials.
<ram_> Please anyone give answer for this

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