[04:20] <ePierre> Hi!
[04:22] <Noskcaj> hello ePierre
[04:37] <ePierre> living in Asia, I often feel I'm in the bad timezone :D
[04:42] <Noskcaj> ePierre, A bitnorth of me, but probably a similar timezone (I'm AU)
[04:43] <ePierre> 12:43PM here
[04:44] <ePierre> Melbourne?
[04:53] <Noskcaj> sydney
[05:00] <ePierre> Nice!
[05:52] <pitti> Good morning
[09:32] <davmor2> Morning all
[09:37] <ePierre> hey davmor2  :)
[12:45] <om26er> ubuntu-qa could anyone please review this https://code.launchpad.net/~om26er/address-book-service/test_dummy_service/+merge/225846
[12:50] <brendand> om26er, looking
[12:56] <brendand> om26er, address-book-service has no ui, so you can't use autopilot to test it
[12:57] <brendand> om26er, why do you need to have an -autopilot package? is it to distribute the helpers so that other tests can use them?
[12:59] <om26er> brendand, the service provides a dummy backend, it needs to be tested on a real app, so I had to use address-book-app to verify that. But really I am writing those tests to be able to produce reusable helpers for the UX test
[13:00] <om26er> brendand, the important part is in fixture_setup.py
[13:00] <brendand> om26er, what's the reason not to have the helper in address-book-app?
[13:02] <om26er> brendand, a bad change in the service can make the dummy backend stop working and we won't know if it did. only when the UX test starts failing
[13:05] <om26er> brendand, I am testing the service, not the app.
[13:05] <brendand> om26er, then by all means add a test for the service, but you don't need to package it in an autopilot package
[13:05] <brendand> om26er, if you're packaging it then you must intend for other tests to use part of it?
[13:06] <om26er> brendand, the test have dependencies and it needs to run in the CI
[13:06] <om26er> brendand, yes, other tests will use most of the code
[13:06] <om26er> re-use.
[13:07] <brendand> om26er, i don't think tests have to be in an autopilot package in order to run in CI
[13:08] <om26er> brendand, whats you suggestion ?
[13:10] <brendand> om26er, first of all can the test for address-book-service itself, and the helper code that might be used in other places be seperated?
[13:15] <om26er> brendand, the helper code sets a few environment variables and restarts the service so that the dummy backend of the service is started.
[13:15] <om26er> brendand, you mean in two different branches or in two different projects ?
[13:15] <om26er> the helpers can live anywhere but they belong to the service, as the fixture is trying to start the dummy service.
[13:16] <brendand> om26er, i think the helpers belong in address-book-app actually
[13:19] <brendand> om26er, because they are useful for tests that test the address-book-app
[13:19] <om26er> brendand, how ? address-book-app, messaging-app and the dialer-app all use address-book-service. The service provides contacts, what these helpers are doing is they start the service with a certain vcard so that *any* app that uses these helpers can be fasciliated
[13:21] <brendand> om26er, btw have you checked how this helper overlaps with the one that's already there in ubuntu-experience-tests (but about to be moved to address-book-app)?
[13:22] <brendand> om26er, that allows the running address-book-service to be interacted with
[13:23] <om26er> brendand, I did look at those helpers in ubuntu-experience-tests. What they are doing is they add/delete contacts live on the service. The developer of address-book-app guided us against that a few months ago and implemented this dummy backend for us
[13:24] <om26er> and I thought they were not being used by any UX test ?
[13:24] <brendand> om26er, but for experience tests do you think it's a good idea to use dummies/mocks?
[13:24] <brendand> om26er, we're supposed to be testing the whole system
[13:25] <brendand> om26er, for the address-book-app autopilot tests it's different, since we're only testing the app itself
[13:26] <brendand> om26er, the tests that are using it haven't been merged yet - it was specifically merged so that it could be shared between myself and rhuddie's tests
[13:27] <om26er> brendand, I do agree to that but half, adding a contact from an API is not the same as a user would add it from the UI :)
[13:28] <om26er> brendand, I can halt my branch for now, it can probably be used for integration testing in future.
[13:28] <brendand> om26er, maybe not, but you need to try and limit the scope of the test somehow
[13:29] <brendand> om26er, also using the ui to setup prerequisites makes for large and unmaintainable tests
[13:29] <brendand> om26er, i see some people are doing that though
[13:32] <om26er> brendand, the test I am working on has to interact with unity to launch app, messaging-app for sending the messaging and the address-book-service to reveal a contact to send the message to.
[13:33] <brendand> om26er, we should definitely have a standard way to launch an app via unity, otherwise it will be a mess
[13:33] <brendand> om26er, currently i'm not doing that but i would if there was a straightforward helper to use
[13:33] <om26er> brendand, I created one, you can use it when it gets merged.
[13:34] <om26er> its starting app from the launcher
[13:34] <brendand> om26er, and unless your test cases is actually about creating a contact, i don't see the problem with doing it via the service
[13:35] <brendand> om26er, a test case will nearly always have some prerequisites, and these should be created/configured in the most straightforward way possible
[13:35] <om26er> brendand, so you suggest I use the helpers from ubuntu-experience-tests to add a contact ?
[13:36] <brendand> om26er, let me move them to address-book-app (although you can start, because not much will change on using it except the import)
[13:48] <balloons> you were busy pitti :-)
[13:49] <pitti> balloons: hehe, yes; good morning!
[13:50] <balloons> good morning. I tried to follow along with the emails as you went through things. I agree that my original timeline was the same as yours, I figured we'd move over a slightly longer period ;-)
[13:51] <pitti> balloons: yeah, I was a bit paniced by the "by tomorrow" thing :)
[13:52] <balloons> yea, it was EOD for me and thomi started asking about it.. I mentioned that we finally had a solution and I was going to start working towards implementing it
[13:52] <pitti> balloons: so I think autopkgtest has the necessary functionality there (maybe a few beautifications)
[13:53] <balloons> yes, I played long enough last night to confirm that.. I think I agree. It's a bit rough still, but definitely seems to work
[13:53] <pitti> balloons: so it would be nice if you could update and land your calendar MP
[13:53] <balloons> so, I like the new syntax for depends. much nicer
[13:53] <pitti> balloons: and we need someone to fix notes-app
[13:54] <pitti> balloons: yeah, and no magic semantics
[13:54] <pitti> I mostly added the "autopilot": "foo_tests" to be compatible with existing apps
[13:54] <balloons> so, wow.. you were able to mark everything else invalid, really?
[13:54] <pitti> balloons: yes, I ran through them all :)
[13:54] <pitti> kept my phone busy this morning
[13:54] <balloons> that's really surprising
[13:54] <pitti> why?
[13:55] <balloons> well... I suppose not really surprising, heh. We've moved most things into the toolkit
[13:55] <balloons> hekoer
[13:55] <balloons> *helper
[13:55] <pitti> balloons: but NB that these are only the clicks we install by default; the store has many more :)
[13:55] <balloons> ofc ofc
[13:55] <pitti> but I suppose the default click apps are what matter for image verification etc.
[13:55] <balloons> yep
[13:56] <balloons> so, my other thoughts are to cleanup the debian packaging for the -autopilot packages
[13:56] <pitti> balloons: hah, new autopkgtest just got promoted to utopic
[13:56] <balloons> they are a bit broken too.. but I'll leave it alone
[13:56] <pitti> balloons: yeah, we can drop them all once we moved CI over
[13:56] <balloons> pitti, ohh, on the subject, are you going to backport to trusty?\
[13:56] <balloons> autopkgtest that is
[13:57] <pitti> balloons: I can issue a backport request, yes; until that lands you can just use the deb from utopic
[13:57] <pitti> in the lab (for production autopkgtest) I just run straight out of git, which makes deployment of fixes dead easy
[13:57] <balloons> pitti, I thought the deb would work straight up.. Many of the developers still use trusty, with a utopic vm
[13:58] <balloons> I told them to install the deb and linked it, but lol, last time I did that I sent them on a goose chase breaking there system so they didn't believe me ;-)
[13:58] <pitti> oh, really? it's a bit tricky on precise as there's no python3-debian yet; but on trusty it should just work
[13:59] <pitti> (I have a locally built precise backport for python3-debian for our friends in CI)
[13:59] <balloons> well.. I'm sure it works fine. I've had them play with newer versions of the toolkit and autopilot before.. those are more connected and what broke things in the past for them
[14:01] <balloons> pitti, link to the lp built deb? my local mirror is slow
[14:01] <balloons> autopkgtest - 3.1git1 that is
[14:01] <pitti> balloons: http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.1git1_all.deb
[14:01] <balloons> ty
[14:01] <rvr> pitti: ping me when you are free
[14:02] <rvr> pitti: (I'm vrruiz :)
[14:02] <pitti> ah, I just /whois'ed :)
[14:02] <pitti> rvr: better just ask your question, I'm swamped in things anyway :)
[14:03] <rvr> pitti: I asked you yesterday to meet to check the problem I have with a test (dbusmock with callbacks)
[14:04] <pitti> rvr: ah, anything I can look at for this?
[14:04] <rvr> pitti: Hangout? I think it will be faster to introduce you to the problem
[14:04] <pitti> rvr: sure
[14:04] <rvr> Ok, let me create it
[14:05] <pitti> rvr: you aren't logged in
[14:28] <rvr> pitti: Details sent
[14:31] <pitti> rvr: so I wrote http://paste.ubuntu.com/7765896/ now, and it's completely invisible to "gdbus call -e -d com.example.DeepThought -o / -m com.example.DeepThought.Answer"
[14:33] <pitti> rvr: back in 15 mins, then I'll look at that
[14:33] <rvr> pitti: ok
[14:33] <balloons> pitti, sent you a mail with a few follow-up responses to my questions. I'll discuss once you've read ;-)
[14:37] <rvr> Hmm
[14:47] <pitti> rvr: so, neighbor cat is fed and caressed, continueing :)
[14:47] <rvr> lol
[14:47] <rvr> pitti: I tested your code here
[14:48] <rvr> $ python3 dbus-cb.py
[14:48] <rvr> DeepThought: method Answer called, will succeed
[15:02] <pitti> balloons: replied
[15:02] <pitti> rvr: it fails with 1/3 probability and succeeds with 2/3
[15:03] <pitti> (just to test both the error and success callbacks)
[15:04] <rvr> SometimesFlakyDeepTought :)
[15:04] <pitti> yeah, much more realistic that way :)
[15:04] <jibel> brendand, about your mtp transfer test, how is the file transferred from the device? via ssh xxxx@xxx "cp /<mtp address>/<filename> <local path>", correct ?
[15:04] <balloons> pitti, ok, I just proposed something for notes, but trying to run it with the new click= isn't working
[15:04] <brendand> jibel, essentially
[15:05] <pitti> balloons: oh, how so?
[15:05] <balloons> also, can you approve https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/autopkgtest/+merge/225910?
[15:05] <jibel> brendand, okay. so ssh doesn't have any active role in the transfer other than driving the host?
[15:07] <brendand> jibel, exactly
[15:07] <brendand> jibel, it's ssh not scp :)
[15:07] <jibel> brendand, yeah, just confirming :)
[15:07] <pitti> balloons: done
[15:08] <balloons> pitti, I can send the log and how I'm running.. one sec I'll paste
[15:08] <balloons> http://paste.ubuntu.com/7766046/
[15:08] <jibel> brendand, I think the test should just verify that the file is there and not corrupted like same checksum on both sides and that's good enough
[15:09] <brendand> jibel, good idea
[15:09] <pitti> balloons: ah, hah; it's --click=
[15:09] <jibel> maybe test with different sizes of files too, lot of small, 1 big ...
[15:09] <pitti> balloons: or --click com....
[15:09]  * brendand wonders how to hash several files together
[15:10] <pitti> brendand: funny, it's trying to interpret this as a source package name, and apt-get source interprets the =... as a  version to download
[15:10] <pitti> brendand: cat file1 file2 | sha1sum ?
[15:11] <pitti> balloons: but if you fixed the Exec=, don't you need to rebuild the click and test that instead of the preinstalled one?
[15:11] <brendand> pitti, cool. i didn't know sha1sum took stdin - i probably should have expected it though :)
[15:11] <pitti> brendand: welcome to Unix! :-)
[15:13] <brendand> pitti, yeah but you know you can't always assume X tool is going to be compliant. something as fundamental as sha1sum ought to be though i guess
[15:13] <pitti> balloons: oh, so that -I doesn't even come from ubuntu-app-launch and that broken Exec= line, but from the test itself?
[15:14] <pitti> brendand: regardless of that, I suppose the bogus $@ and the -I should be fixed in CMakeLists as well?
[15:14] <balloons> pitti, ohh, haha.. --click :-) Trying again
[15:14] <pitti> balloons: yeah, it's a bit nasty to fit all the different use cases into a concise CLI syntax, and bare identifiers are already taken for apt sources :/
[15:14] <balloons> pitti, yes, it's coming from the test itself.. The test controls how the app is launched
[15:15] <pitti> balloons: and as apt source names can contain '.' there is no solid way to tell apart a click and an apt source name
[15:15] <pitti> nor are click packages required to contain dots
[15:15] <balloons> pitti, right.. completely reasonable
[15:15] <pitti> so I iniitally thought about click:foo.bar
[15:15] <pitti> but it's not really simpler than --click=foo.bar
[15:16] <balloons> so, tests seem to be running now
[15:16] <pitti> balloons: so I like your idea of wrapping it in click-buddy, or phablet-test-run, or whatever
[15:17] <pitti> balloons: btw, '--- \ssh '
[15:17] <pitti> balloons: that \ is just to escape a line break; apparently the shell gracefully handles/ignores it here :)
[15:17] <balloons> pitti, ohh, btw, for the store clicks, I found out it's coming in a few weeks, but you'll have to be logged in to get them
[15:18] <pitti> balloons: ok, so I guess for now I'll completely ignore this and demand that you either have it installed or have the .click locally
[15:18] <pitti> and let the retrieval be an SEP :)
[15:19] <balloons> pitti, yea I assumed the --- \ stuff was to handle some shell weirdness
[15:19] <balloons> I discovered that when I left an additional space and it blew up :-)
[15:19] <pitti> balloons: I just put that into the documentation as they span two lines
[15:19] <pitti> which looks nicer than one long one, and separates the tests from the testbed args
[15:20] <pitti> balloons: one thing to make the command line shorter is to implement automatic source retrieval from the vcs-* manifest fields, but I haven't done that yet
[15:20] <balloons> so, since we are calling conventions, there's a couple other things to discuss. Could we give a reference to an lp branch?
[15:20] <pitti> (it would also slow down the test run quite a bit, though)
[15:21] <pitti> balloons: yeah, not sure about that yet; I'd have to teach it about bzr, git, hg and what not (as this should also work for Debian packages then)
[15:21] <balloons> also, is it necessary to pull the entire branch, or could we simply just copy in the tests/autopilot directory?
[15:22] <pitti> it depends on the test metadata
[15:22] <pitti> if it only has one "autopilot" test or only autopilot_module tests, then yes
[15:22] <pitti> (and not DEP-8)
[15:22] <balloons> pitti, the idea being I could specify a branch and have it do everything; as it stand if I want to run a whole suite of these I need to branch all of them
[15:22] <pitti> balloons: right, for that case automatic --click-source retrieval through vcs-* would help indeed
[15:22] <pitti> and then something like checkout --lightweight
[15:25] <balloons> pitti, right.. so that should handle the image verification case then I'd think
[15:26] <pitti> balloons: yes, something like adt-run --click foo --click bar --click baz --- ssh ..
[15:26] <balloons> the other half is the app developer workflow.. I think being able to re-use the temp directory would be helpful. Ohh that reminds me of what I was going to say
[15:26] <pitti> without the interspersed --click-source
[15:27] <pitti> balloons: apt-get without apt-get.. :)
[15:27] <balloons> pitti, yes indeed!
[15:27] <pitti> with a writable image this wouldn't be a problem
[15:27] <pitti> and we can't write to anywhere permanent
[15:27] <pitti> perhaps $HOME/.cache/
[15:28] <pitti> but then this leaks into other test, shadowing that your test misses test deps, so it shoudln't be done by default
[15:28] <balloons> pitti, so in theory if you unpacked the depends into /home/phablet/autopilot as is done now, because autopilot is on the image, etc, that would emulate how I test now.. aka, not requiring setup each time
[15:28] <pitti> balloons: well, you don't know which package versions you unpacked, whether there are updated versions, etc.
[15:28] <balloons> pitti, yes, it would be a non-clean env
[15:29] <pitti> I'm not going to rewrite half of apt
[15:29] <pitti> if we want apt, let's use apt; developers can use r/w
[15:29] <pitti> anything permanent without proper version tracking etc. is going to introduce potential bugs
[15:30] <balloons> yep, totally. I'm just thinking through how we can adopt a best practice from what's happening now
[15:30] <pitti> balloons: btw, a lot of the packages will disappear once libautopilot-qt will stop installing python2.7 and all those python 2 libs
[15:30] <pitti> balloons: and I hope in the medium term we'll get a better way of bringing the apt and click worlds together
[15:30] <pitti> mvo had some nice ideas about that
[15:31] <pitti> and it's like the #1 problem for convergence
[15:31] <balloons> the slowness of the testruns is a small price for the robustness. As it stands, most folks can't easily run tests due to hitting those hidden errors (bad env, missed depends, outdated depends)
[15:31] <pitti> like, system image plus a chroot for apt, and then permanently extending $PATH and friends
[15:32] <pitti> balloons: so, let's land the python2 sectomy fast, and jdstrand just told me how to shave off that minute for aa-clickhook
[15:32] <balloons> pitti, right.. once that's done the setup should be rather minimal
[15:33] <balloons> and nothing ever stops me from just pushing my tests and calling autopilot manually.. I can be my own tool if I wish for some reason :-) This brings sanity to the world
[15:33] <pitti> FWIW, "bzr checkout --lightweight" is surprisingly fast
[15:33] <pitti> balloons: right, or --shell
[15:33] <pitti> or -s
[15:34] <pitti> balloons: or running your tests in an LXC container, which is so much faster :)
[15:34] <balloons> so I think I'm pretty happy. Really we are left with working on making  invoking the testrun to be easier. Ohh, there is one thing I'm not thinking about..
[15:35] <balloons> How can I run a single test?
[15:35] <balloons> this hearkens back to be able to pass -v or other arguments as well Ithink
[15:35] <pitti> balloons: right, from autopkgtest's POV, "autopilot" is the one and only single test
[15:36] <pitti> balloons: that, or again --shell
[15:36] <balloons> yes, I could in theory change the manifest.. that's no good
[15:36] <pitti> balloons: we can invent somethign for passing additional args to the AP command (erk more special cases, but so what)
[15:36] <balloons> pitti, how does --shell work? It won't run till after the tests
[15:36] <pitti> balloons: for calculator-app I just commented out the tests in teh checkout and ran them then
[15:37] <pitti> balloons: right, -s or --shell apply after a test run; from then on you can run individual tests in that shell
[15:37] <pitti> (thus -s is usually more useful)
[15:37] <balloons> I think passing args is a bridge we'll need to cross at some point. But yes, it's not crucical..
[15:37] <balloons> yea, I still have to wait for the test run, but you are right. I can then invoke the tests any way I wish
[15:38] <pitti> right, let's keep that idea on the backburner
[15:38] <balloons> :-) So one final bug for passing args then?
[15:38] <pitti> balloons: in other news, of all the tests that I ran today, music-apps' were the most enjoyable
[15:38] <pitti> was nice to listen to some calming music which suddenly started playing :)
[15:38] <balloons> pitti, lol..
[15:38] <balloons> the backstory on music is kind of funny
[15:39] <pitti> balloons: final bug> I suppose so; I need to think about how to make this look not horrible
[15:39] <balloons> originally the random music playing wasn't so calming shall we say
[15:39] <balloons> pitti, yes.. here I am asking to make invoking the tests easier, yet demanding I be able to pass args!
[15:40] <pitti> balloons: so of all the packages in http://paste.ubuntu.com/7766218/ only the last two should remain, and they are only 550 kB
[15:40] <pitti> balloons: the fun thing is, downloading/unpackgin python2 stuff won't even *do* anything, as autopkgtest's magic will only work for python3 :)
[15:40] <pitti> (as there's no separate PYTHON3PATH and PYTHON2PATH, you can't mix the two locally)
[15:41] <balloons> pitti, ahhah. how true!
[15:41] <balloons> pitti, so I wonder who can review https://code.launchpad.net/~nskaggs/notes-app/ap-setup-update/+merge/225992
[15:41] <pitti> balloons: actually, I wonder if my libautopilot-qt bug is correct
[15:42] <pitti> it should certainly be fixed, but I just realized that it's already installed by default (without recommends)
[15:42] <pitti> so it must be something else
[15:42] <balloons> pitti, my guess on the py2 stuff is we're going to end up with it for awhile.. I have a bug or two about making py3 default, etc
[15:43] <balloons> I'm not sure if there's a way they can package it easily to be a pure py3 install, with no py2 bits
[15:43] <pitti> balloons: so autopilot-touch is already installed
[15:43] <pitti> ooh!
[15:43] <pitti> it's ubuntu-ui-toolkit-autopilot
[15:44] <pitti> that depends on all the py2 stuff
[15:44] <balloons> yes, autopilot could be removed from the images ;-) Ohh, speaking of which, in our depends can we actually specify a version? I assume not, as we're using apt, we're going to get whatever apt gives us
[15:44] <balloons> pitti, ohh, well hmm.. that might be a simple packaging fix
[15:44] <pitti> balloons: you can specify constraints like >= 1.2.3
[15:45] <balloons> pitti, ohh marvelous
[15:45] <pitti> balloons: you can also specify exact versions, but then your test will fail if apt doesn't have that
[15:45] <balloons> pitti, yes ofc.. but the autopilot disasters of breaking tests could be totally avoided this way
[15:45] <pitti> balloons: this is exactly why I argued so much about having separate pytho3-foo-autopilot packages, but nobody wanted to believe me back then :(
[15:46] <balloons> pitti, it's fine.. we can just blame elopio :-)
[15:48] <pitti> balloons: I have a meeting in 10 mins (tech board) and need to clean up a few things; would you mind filing a bug against ubuntu-ui-toolkit to stop depending on py2 stuff in ubuntu-ui-toolkit-autopilot?
[15:48] <pitti> (or using alternative deps with py3 first)
[15:48] <balloons> pitti, I'll probably file the bug and then do an MP for it
[15:48] <balloons> if the change is simple enough
[15:49] <balloons> thanks for your help on everything.. quick iterations ;-)
[15:49] <elopio> I can prove my innocence.
[15:49]  * balloons waves to elopio
[15:50] <balloons> buenoes dias mae
[15:50] <balloons> so elopio see above.. do you think we can tweak ubuntu-ui-toolkit to depend on py2 or py3, so it doesn't pull py2 stuff?
[15:50] <balloons> I'm branching now to look
[15:50] <elopio> balloons: you are getting to the advanced jargon.
[15:50] <elopio> ¿quihubo?
[15:51] <pitti> balloons: thanks; I'll leave the night shift (US time) to you then :)
[15:51] <elopio> balloons: that's a question for barry. I suppose it will involve changing all the packages to use python3-ubuntu-ui-toolkit-autopilot, or python-ubuntu-ui-toolkit-autopilot
[15:52] <elopio> if we are to touch all the packages, it would be better to touch them to be py3, and then drop py2 from the toolkit.
[15:52] <pitti> elopio: well, I argued that to death with barry and thomi back then
[15:52] <pitti> and they didn't want to split the package
[15:52] <balloons> elopio, in french I would say pas mal.. I'm not sure about 'not bad' in spanish.. no mal ;-)
[15:52] <pitti> so I suppose we'll just move the deps to py3 and mop up the py2 breakage (I doubt that there's a lot)
[15:53] <balloons> elopio, could we drop py2 altogether from the toolkit?
[15:53] <balloons> honestly, why couldn't we at this point?
[15:53] <elopio> pitti: there are some. It's not yet a quick task, but one really needed.
[15:53] <elopio> otherwise we can't add those heleprs to the UX testing project.
[15:53] <elopio> balloons: not yet, we need to port some other projects.
[15:54] <balloons> elopio, breaking things always motivates.. there's likely to always be a lingering project
[15:54] <balloons> fair enough.. I'll just file the bug then
[15:55] <pitti> elopio: apt-cache rdepends ubuntu-ui-toolkit-autopilot doesn't look bad
[15:55] <pitti> elopio: and hopefully most of those *-autopilot packages are ported to py3 now?
[15:56] <pitti> rvr: sorry, seems I got sucked into the discussion with balloons for too long, Tech board now; promised, will look tomorrow morning!
[15:56] <balloons> ohh lookey what I found: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1249235
[15:56] <rvr> pitti: Thanks!
[15:57] <elopio> balloons: that's done.
[15:58] <balloons> elopio, ahh I misread it.. the title was misleading
[15:58] <elopio> balloons: there's one that's driving me crazy
[15:58] <elopio> maybe you can try to find what's going on, that will help.
[15:58] <balloons> elopio, sure thing..
[15:59] <elopio> balloons: https://code.launchpad.net/~barry/dialer-app/py3autopilot/+merge/220658
[15:59] <balloons> elopio, ok, so this is just converting the dialer to py3, and you still get an error right?
[16:00] <elopio> balloons: I don't, neither barry. Just jenkins gets the error.
[16:00] <balloons> perfect.. I'll debug :-)
[16:00] <balloons> I love fixing jenkins only erros
[16:00] <balloons> I've done it so much, hah!
[16:02] <pitti> balloons: just saw your mail reply -- ^5s!
[16:04] <pitti> I thought dialer-app has used py3 for a long time already
[16:04] <pitti> so apparently not
[16:29] <elopio> brendand: I get this with the py3 branch:
[16:29] <elopio> have_phonesim = out.startswith('[ /phonesim ]')
[16:29] <elopio> TypeError: startswith first arg must be bytes or a tuple of bytes, not str
[16:30] <brendand> elopio, of what - messaging-app?
[16:31] <elopio> brendand: yes. Running the UX tests with the py3 messaging app branch.
[16:31] <brendand> elopio, that's odd because i specifically fixed that issue
[16:33] <elopio> brendand: oh, I'm using the fix action items branch
[16:33] <elopio> I thought py3 was a prerequisite for that one. Sorry.
[16:34] <brendand> elopio, ok - ignore my response in the other channel :)
[16:35] <elopio> I will :)
[17:43] <phillw> elfy / balloons The only things noticed in testcase 1483 (Alternate Install - Guided) are.... min does not work (I'm guessing they took it out as it was actually doing max and max was doing min). And the prompt to unmount an already mounted system - which is to be expected on a side by side install. I think it does a merit a mention in the test case, as a new tester may think it is an error and we don't need more bugs :P
[17:56] <balloons> phillw, please add that to the bug report.. Well, add just what needs to be changed in your opinion. That said, you are probably the best person to change it as well if you are willing
[18:02] <balloons> If nothing else, just pasting a revised copy of the test in the bug would make it possible for someone to do it
[18:04] <phillw> balloons: I'm not an editor,
[18:04] <phillw> I'll do that.
[19:22] <elopio> balloons: july 10th. You missed the month on your email.
[19:38] <phillw> balloons: bug 1335669
[19:39] <balloons> elopio, ty.. man, I need to update that in severla places ;-(
[23:33] <phillw> balloons: I'm  saddened that nothing has happened for the issue on  https://wiki.ubuntu.com/QATeam/Hardware
[23:34] <phillw> balloons: https://bugs.launchpad.net/ubuntu/+source/hardinfo/+bug/1308853
[23:40] <knome> u
[23:40] <knome> oh bah
[23:41] <knome> that's not what and where i was supposed to write!