[05:28] <pitti> Good morning
[07:00] <DanChapman> good morning
[07:04] <elfy> morning DanChapman
[07:04] <DanChapman> morning elfy :-) how are you?
[07:04] <elfy> awake - just :p
[07:18] <DanChapman> elfy, yeah same here. got ill children in this house :-( now just got to look forward to catching it!
[07:19] <elfy> nice
[07:19] <elfy> just hope you had chickenpox when they get that ...
[08:12] <pitti> jibel: I have the "wait 20 s after boot and check runlevel" patch locally applied on wazn, first two tests succeeded now; I restarted the other ones
[08:12]  * pitti commits
[08:17] <jibel> pitti, I think we need the same hack in UpgradeTestBackendSSH in upgrade()
[08:17] <pitti> jibel: why? that just calls .start(), doesn't it?
[08:18] <jibel> pitti, because it calls start() then immediately calls upgrade() and capture the list of services before the upgrade
[08:18] <jibel> so we may miss some or have too much
[08:18] <pitti> jibel: oh, you mean we need to move super().upgrade() after .start() in Qemu.py, too?
[08:19] <pitti> jibel: you already did that for LXC (thanks)
[08:19] <jibel> pitti, that too
[08:19] <pitti> jibel: ok, then I don't understand what you mean
[08:19] <jibel> pitti, but I meant that the initial list of services is captured too quickly after start()
[08:21] <pitti> jibel: what I meant was http://bazaar.launchpad.net/~auto-upgrade-testing-dev/auto-upgrade-testing/trunk/revision/116
[08:21] <jibel> pitti, in LXC.py we call upgrade() which calls start() and super().upgrade()
[08:21] <pitti> jibel: which does to Qemu what you did to LXC in r111
[08:21] <jibel> but in super().upgrade() we don't wait for the system to settle
[08:21] <pitti> jibel: no, but start() already does?
[08:22] <pitti> jibel: but what couldn't hurt is to do the same sleep/runlevel check in Qemu's start() as well; AFAIK that just tries whether /bin/true works
[08:22] <jibel> pitti, ah right, sorry
[08:26] <jibel> next run should be green again
[08:33] <pitti> meh!
[08:33] <pitti> jibel: seems I need to blacklist kdm, precise -> trusty kubuntu switched from kdm to lightdm as it seems
[08:33] <pitti> jibel: I blacklisted plymouth this morning, as that's really just transient
[08:33] <pitti> jibel: anyway, I'll get it to green today, promised :)
[09:59] <pitti> jibel: ok, much better already: http://d-jenkins.ubuntu-ci:8080/view/Upgrade/
[10:00] <pitti> now, why isn't whoopsie starting for quantal -> saucy..
[10:01] <pitti> that starts to smell like an actual bug now
[11:04] <davmor2> Morning all
[14:36] <balloons> ty DanChapman for merging those autopilot requests :-)
[14:40] <DanChapman> balloons: np :-) how's it going? ready for a busy few days?
[14:41] <balloons> DanChapman, never completely ready, but always excited and happy to talk
[14:41] <DanChapman> :-D
[18:32] <elopio> veebers, thomi: have some time to talk about the folder hierarchy after I deprecate the word emulators?
[18:33] <thomi> elopio: gimme 2 minutes?
[18:33] <thomi> Then I will
[18:33] <elopio> ok
[18:37] <thomi> elopio: have time now
[18:44] <elopio> thomi: so, this is the current structure:
[18:44] <elopio> tests.autopilot.ubuntuuitoolkit.tests
[18:44] <elopio> tests.autopilot.ubuntuuitoolkit.emulators
[18:44] <elopio> no, scratch that.
[18:44] <elopio> it's not namespaces, it's directories.
[18:45] <elopio> tests/autopilot/ubuntuuitoolkit/tests
[18:45] <elopio> tests/autopilot/ubuntuuitoolkit/emulators
[18:45] <thomi> right
[18:45] <thomi> so... can we drop the 'tests/autopilot/' prefix?
[18:45] <thomi> I mean, it's not important to the conversaion here, they could be *anywhere* in the source tree right?
[18:46] <elopio> I can't just put what's currently in tests/autopilot/ubuntuuitoolkit/emulators
[18:46] <elopio> in tests/autopilot/ubuntuuitoolkit/__init__.py, because at some point we might want to provide actual python toolkit APIs on ubuntuitoolkit.
[18:46] <elopio> thomi: yes, we could drop the prefix.
[18:47] <elopio> what I propose is to move ubuntuuitoolkit.emulators to ubuntuuitoolkit.autopilot
[18:47] <elopio> and ubuntuuitoolit.tests to ubuntuuitoolkit.autopilot.tests
[18:47] <thomi> yeah - that sounds sensible to me
[18:48] <elopio> now, we need to fix the prefix because it would be horrible tests/autopilot/ubuntuuitoolkit/autopilot/tests
[18:48] <thomi> :)
[18:48] <elopio> I don't really know how to make it better.
[18:48] <elopio> if we just drop the first tests/autopilot
[18:49] <elopio> we separate them from tests/qml
[18:49] <elopio> it was somewhat nice to have them together.
[18:49] <thomi> elopio: so.. I'm not convinced that you're ever going to ship an actual toolkit in the python package
[18:49] <elopio> but, maybe we should also drop tests/qml, and put them next to the components.
[18:50] <elopio> thomi: well, even if we don't release the toolkit in python, I think it's not right to assume that the ubuntuuitoolkit namespace is all ours.
[18:51] <thomi> elopio: not forever, but it is today. Ideally you'd rename that python package, but that's a lot more work then we want to do right now
[18:51] <elopio> thomi: it would be the same amount of effor to move the helpers to ubuntuuitoolkit.__init__ than to move them to ubuntuuitoolkit.autopilot
[18:52] <thomi> elopio: yes, but your package and paths wouldn't be so ugly
[18:52] <elopio> thomi: droping the tests/autopilot prefix to the path is a bzr move + a cmake change.
[18:53] <elopio> no big deal there either.
[18:53] <thomi> right
[18:53] <elopio> something fancier than that could be a problem.
[18:53] <thomi> In general, I think it's a python anti-pattern to have deeply nested namespaces
[18:53] <thomi> so I prefer the flatter solution
[18:53] <thomi> and yes, I realise that autopilot does this, but we're fixing that :)
[18:54] <elopio> thomi: flat would be something like calling the package ubuntuuitoolkit_autopilot ?
[18:54] <thomi> elopio: no, like
[18:54] <thomi> custom proxy classes and helpers are in 'ubuntuuitoolkit'. tests are in 'ubuntuuitoolkit.tests'
[18:55] <thomi> if you ever release the python SDK, release it under 'ubuntusdk'
[18:55] <thomi> or some other name
[18:55] <thomi> it really won't belong in the same package I don't think
[18:55] <elopio> ok, I agree that a namespace hierarchy is not pythonic.
[18:56] <elopio> however, putting the autopilot helpers in ubuntuuitoolkit is not clear.
[18:56] <elopio> we need to mention somewhere that they are autopilot helpers.
[18:56] <thomi> elopio: right - ideally you'd rename that top-level package
[18:56] <thomi> 'ubuntu_sdk_helpers' or somesuch
[18:56] <elopio> thomi: what name would you propose?
[18:56] <thomi> but anny name change is going to be painful
[18:57] <thomi> although... maybe not so bad
[18:57] <thomi> with the ci-train
[18:57] <elopio> ubuntu_sdk_testing, I like something like that.
[18:57] <thomi> yeah
[18:57] <thomi> 'ubuntu_sdk_testing.tests' :P
[18:57] <thomi> I suppose that's not too bad
[18:58] <elopio> ubuntusdk_testing.user_accpentance_tests
[18:58] <elopio> ubuntusdk_testing.helper_tests
[18:58] <elopio> I actually would like something like that.
[18:58] <elopio> then we can run first the helper tests, and if they pass, we run the uat.
[19:54] <dkessel_> good evening
[20:38] <letozaf> balloons,  hi
[20:38] <balloons> letozaf, hello
[20:39] <letozaf> balloons, I was trying to figure out why reminders app does not start, do you know how to fix this: No token set. Cannot execute job. ( FetchUsernameJob )
[20:39] <letozaf> balloons, I think that reminders app does not start due to a token problem
[20:39] <letozaf> balloons, but do not know how to fix this
[20:40] <letozaf> balloons, well if you got time obviously as I think  you're quite busy with vUDS
[20:47] <balloons> letozaf, I agree with all those things.. but I would think the app would still start
[20:48] <balloons> it starts when run from the command line
[20:48] <balloons> so clearly it should work; the __init__.py  launch is not correct, that's my guess as we discussed
[20:49] <letozaf> balloons, yes I think you're right
[20:49] <letozaf> balloons, I will have to see if I find out what's wrong in  the __init__.py
[20:50] <letozaf> balloons, but how do I know if something has change in the way reminders app get's launched ?
[20:51] <letozaf> balloons, I mean the tests used to work a long time ago and I do not know about the changes, if changes have been made obviously
[20:51] <balloons> letozaf, yes the depcrecated qmlscene which broke things for us
[20:53] <balloons> letozaf, well let's look together
[20:53] <balloons> give me a moment :-)
[20:53] <letozaf> balloons, ok
[20:58] <balloons> letozaf, so launch_test_local won't work anymore
[20:59] <letozaf> balloons, no and it tries to launch /usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene', '-testability', '-I', '/home/letozaf/autopilot-tests/new-reminders-app-tests/builddir/src/plugin', '../../src/app/qml/reminders.qml', '--desktop_file_hint=/home/phablet/reminders/reminders-app.desktop']
[21:00] <letozaf> balloons, :O
[21:00] <balloons> so for the moment, let's try launch_test_installed
[21:00] <balloons> mmm
[21:00] <balloons> also not gonna work
[21:02] <letozaf> balloons, I get http://paste.ubuntu.com/7075741/
[21:02] <balloons> letozaf, ok let me send you the hackery to launch
[21:03] <balloons> but it needs to be fixed to have it work without installation
[21:04] <letozaf> balloons, you mean without reminders.app being installed on my desktop ?
[21:05] <balloons> letozaf, merge lp:~nskaggs/reminders-app/fix-ap-launch
[21:07] <balloons> letozaf, so that forces launching via the installed version. It will get you running for now
[21:27] <balloons> letozaf, did it work? :-)