[00:43] <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?
[00:43] <thomi> sure, link me?
[00:44] <veebers> oops
[00:44] <veebers> https://code.launchpad.net/~veebers/autopilot/revert-ext-class-fix-for-now/+merge/251025
[00:44] <thomi> the name makes me sad already
[00:44] <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)
[00:44] <veebers> thomi: aye, I knew that it would, I'm not happy about it either
[00:45] <thomi> so, you're going to release with the CPO extension class bug ?
[00:46] <veebers> thomi: right, the current fix doesn't actually ffix it in the wild
[00:46] <veebers> i.e. with the fix a _bunch_ of tests fail, without the fix they pass
[00:46] <veebers> then next week we'll be working on getting the proper fix in plae
[00:46] <veebers> place*
[00:46] <thomi> so it's not a fix, my point is, if you do that you're releasing a known bad autopilot
[00:47] <veebers> thomi: right, but it's an issue that already exists in autopilot
[00:47] <thomi> ok
[00:47] <veebers> we're releasing an autopilot that doesn't have a fix for that _yet_
[00:48] <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
[00:48] <thomi> so why release at all?
[00:48] <thomi> (approved, BTW)
[00:49] <veebers> thomi: cool thanks.
[00:49] <veebers> thomi: To release the doc improvements (incl the enablement of the json for doc publishing) now
[00:50] <thomi> oh, is that work done?
[00:50] <veebers> heh, enablement :-P I like making words up
[00:50] <veebers> thomi: For the publishing? Not complete but needs these changes to go forward
[00:53] <veebers> thomi: see, you've only just left and the quality of the autopilot code is already going downhill ;-)
[00:54] <thomi> lol
[00:54] <thomi> anyway, that's inaccurate, it's just not going uphill :D
[00:57] <veebers> ^_^
[14:31] <MacSlow> rhuddie, elopio: how can I make sure an AP-test is run against a locally compiled unity8 from within the source-tree?
[14:36] <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
[14:37] <rhuddie> seems to look in a particular path for the unity8 binary in the source tree
[14:37] <MacSlow> rhuddie, if that's the only way, I'll use that
[14:44] <elopio> MacSlow: I think you have a make task in your project.
[14:45] <elopio> like make-autopilot. It's documented on the README or CODING file.
[14:47] <MacSlow> elopio, I know these bits of info... but I still don't seem to get the local unity8 being executed
[14:48] <MacSlow> elopio, that's the reason I was asking
[14:56] <elopio> MacSlow: I almost never change things in unity8, last time I did it was months ago. mzaanneti or saviq should know.
[14:56] <MacSlow> elopio, ok
[14:56] <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.
[14:56] <elopio> but I'm not really sure about the steps.
[14:57] <Saviq> MacSlow, you need "make install"
[14:57] <MacSlow> Saviq, I did
[14:57] <Saviq> MacSlow, then PYTHONPATH=tests/autopilot autopilot run foo
[14:57] <Saviq> MacSlow, should run the tests on the local build
[14:57] <MacSlow> Saviq, that's what I use
[14:58] <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
[14:59] <Saviq> MacSlow, what makes you say that it runs the wrong unity8 though?
[14:59] <Saviq> MacSlow, -vv will be verbose and say what is launched etc.
[14:59] <MacSlow> Saviq, no wonder I've problems trying to grab objectName="shell"
[15:01] <MacSlow> Saviq, -vv not for autopilot?!
[15:01] <Saviq> MacSlow, yes, for autopilot
[15:02] <MacSlow> Saviq, as a parameter for run?!
[15:02] <Saviq> MacSlow, autopilot -vv run foo
[15:04] <MacSlow> Saviq, autopilot and autopilot3 only spit out version information with this
[15:04] <Saviq> MacSlow, right, sorry, yeah, autopilot run -vv foo
[15:05] <MacSlow> Saviq, tried that in the meantime too :)
[15:06] <Saviq> MacSlow, and what makes you think it's trying to run the wrong binary?
[15:08] <MacSlow> Saviq, the fact that there's no single qml-item with objectName="shell", which is the one used for the OrientedShell.qml
[15:09] <Saviq> MacSlow, that doesn't sound like proof enough, what does the autopilot log say about which BINARY is used?
[15:10] <MacSlow> Saviq, which would be written where?
[15:11] <MacSlow> Saviq, I only know of the stuff in ~/.cache
[15:11] <Saviq> MacSlow, "Starting job unity8 with arguments..."
[15:11] <Saviq> MacSlow, on your console
[15:11] <Saviq> MacSlow, it's the output from autopilot run -v
[15:18] <MacSlow> Saviq, I don't have that in the output of autopilot (tried 1.4.0 and 1.5.0)
[15:18] <Saviq> MacSlow, pastebin your whole console output please
[15:18] <Saviq> with the command you used
[15:22] <MacSlow> Saviq, http://pastebin.ubuntu.com/10430561
[15:23] <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
[15:23] <Saviq> MacSlow, most likely you're not using the base testcase that actually takes care of setting the right binary
[15:23]  * MacSlow tries...
[15:24] <Saviq> MacSlow, tests/autopilot/unity8/shell/tests/__init__.py
[15:24] <Saviq> you want to inherit from tests.UnityTestCase
[15:25] <MacSlow> Saviq, doing that
[15:41] <MacSlow> Saviq, the issue seems to be the the args passed to restart_unity() from process_helpers.py
[15:42] <Saviq> MacSlow, is it working for the previous tests?
[15:42] <Saviq> like do you get the correct BINARY mentioned in the log if you're running one of the previous tests?
[15:43] <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
[15:43] <MacSlow> Saviq, and i nmy case it's only 'QT_LOAD_TESTABILITY=1', and nothing else
[15:45] <Saviq> MacSlow, so look at the other test and see what it's doing differently than you
[15:46] <MacSlow> Saviq, yup... fyi http://pastebin.ubuntu.com/10430933/
[21:27] <veebers> thomi: are you keen to approve another ap mp for me? I need to find a replacement :-)
[21:28] <thomi> veebers: maybe, but you really need to start asking people in QA
[21:28] <veebers> thomi: fair enough, I'll do that now
[21:28] <thomi> veebers: maybe save me for when others don't have the necessary experience to reviwe the code?
[21:28] <thomi> veebers: like, introspection internals, for example
[21:28] <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)
[21:29] <veebers> thomi: sure, makes sense to me. Sorry to bother you, it's muscle memory :-)
[21:29] <thomi> heh, no worries.
[21:29] <thomi> veebers: want to review my launchpad branch? :P
[21:30] <veebers> lol, point taken. But I would take a shufti just out of interest
[21:30] <thomi> will let you know when the diff is generated
[21:30] <nuclearbob> veebers: the 1.5.0+15.04.20141031-0ubuntu1 looks a little funny to me
[21:30] <veebers> sweet
[21:31] <veebers> nuclearbob: oh, so that'll be coming from 1.5 when I merged it back into trunk
[21:31] <nuclearbob> veebers: the same changelog is under five people, and elopio is named twice
[21:31] <nuclearbob> veebers: ah, okay
[21:31] <veebers> nuclearbob: to clarify I merged the changelog from 1.5 back into trunk then added the topmost entry
[21:31]  * veebers updated MP desc
[21:31] <nuclearbob> veebers: ah, okay.  Sounds reasonable to me, then
[21:36] <veebers> nuclearbob: if you're cool with that do you mind approving the mp? :-)
[21:37] <nuclearbob> veebers: done
[21:37] <veebers> sweet ,cheers
[21:44] <thomi> veebers: https://code.launchpad.net/~thomir/launchpad/devel-fix-editemails-link/+merge/251176
[21:51] <veebers> thomi: very cool. Ah, what's it like writing non-pure python3 code again?
[21:51] <thomi> veebers: it's actually not too bad
[21:51] <thomi> veebers: but zope is mental
[22:03] <veebers> ^_^