#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 '127.0.0.1', 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 127.0.0.1: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 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 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
