[00:36] <xnox> barry: hey
[00:36] <xnox> barry: i'll check
[16:25] <balloons> elopio, ping
[16:25] <elopio> balloons: pong.
[16:26] <balloons> elopio, seems mocking using the fixtures isn't working for me now.. still working for you?
[16:27] <elopio> balloons: mocking what?
[16:27] <balloons> elopio, sorry, mocking home.. I noticed it doesn't use a fake env on the desktop or device it seems
[16:28] <elopio> balloons: the fixture sets the initctl and env vars, that can't stop working because we have tests to check it.
[16:29] <elopio> but we are not using it on any app, are we?
[16:33] <balloons> elopio, I use it on calendar, music, filemanager too maybe?
[16:34] <balloons> elopio, I do remember it working, but something has changed as it's not atm
[16:36] <elopio> I know filemanager is not using it. I don't know about the rest. Let me see...
[16:38] <elopio> balloons: I think I'm not understanding what you are saying.
[16:38] <elopio> calendar is not using the fake home fixture in trunk.
[16:39] <elopio> it's using your original method, the one I copied to make the fixture.
[16:41] <balloons> elopio, yes I'm saying the original method.. I just tried on the phone and I see other events in the calendar.. it can't be working
[16:42] <elopio> balloons: ah, ok. I don't know about that. I haven't payed attention to that part while running the tests.
[16:44] <balloons> alright, well if you haven't seen it, I guess I'll start by looking at the tests
[16:44] <balloons> that show it's working :-)
[16:45] <elopio> I think the calendar tests will pass even if they start with existing events.
[16:54] <balloons> elopio, yes exactly
[16:54] <balloons> however music won't, which is what I'm diving into now
[21:34] <balloons> veebers, you about?
[22:29] <veebers> balloons: sorry I missed your ping. I am now
[22:29] <veebers> thomi: if/when you have a moment can you eyeball this please: https://code.launchpad.net/~veebers/autopilot/fix-upstart-rename-1330803/+merge/223486
[22:30] <balloons> veebers, I'm concerned why my environment patching isn't working, and I'm trying to rule out autopilot.. or really trying to understand what's changed to make it no longe rwork
[22:31] <balloons> specifically I'm attempting to patch what is considered HOME to get a clean enviroment
[22:32] <veebers> balloons: so you had working code/patching and now it doesn't work?
[22:32] <balloons> since phone brings more problems, I'm focused on the desktop for now, as it too no longer seems to work. In the past I used mock, then switched to fixtures.. It seems as of now, neither one works. Trying to confirm what the qml app sees atm, but it requires qt, so adding compiled code, blah
[22:32] <balloons> veebers, simply put yes. It worked, but now it doesn't
[22:32] <veebers> balloons: how are you currently patching the env?
[22:33] <balloons> veebers, using fixtures;self.useFixture(fixtures.EnvironmentVariable('HOME', newvalue=temp_dir))
[22:34] <balloons> that seems to work; in so much as if I log the environ variable after doing it, it's updated properly
[22:34] <veebers> oops wrong button
[22:34] <veebers> balloons: did I miss anything? last message I saw was: veebers, using fixtures;self.useFixture(fi . . .
[22:35] <veebers> balloons: I would say that should work
[22:35] <balloons> veebers, no I think you got everything
[22:35] <balloons> veebers, I agree, so I'm confused as to why it's not
[22:36] <balloons> and I'm not sure where the blame lies persay.. I also have another related question
[22:36] <balloons> I see launch_dir as an arg option for test_launch_application but it complains when I try and add it as an argument
[22:36] <veebers> balloons: what's changed between patching home working and not?
[22:36] <veebers> interesting
[22:36]  * veebers looks
[22:37] <balloons> veebers, since this is across apps.. the only changes have to be on AP's side.. I guess I could backdate AP and see
[22:40] <thomi> veebers: approved
[22:40] <veebers> balloons: so if you're using fixtures with EnvironmentVariable none of that is autopilot
[22:40] <veebers> thomi: cheers
[22:40] <balloons> veebers, well technically I'm using the helper done by elopio
[22:40] <veebers> ah ok
[22:41] <balloons> veebers, so I would be happy to remove using that and call AP directly.. trying to narrow things down
[22:41] <balloons> I see patch_enviroment is deprecated, but I tried using it also
[22:41] <balloons> didn't change anything
[22:41] <veebers> balloons: aye, patch_environment uses fixtures.EnvironmentVariable
[22:44] <balloons> veebers, so part of the trouble is I can't verify that the app isn't seeing the patched env or not.. qml apps aren't friendly to printing these things afaik
[22:45] <balloons> afaict, the patching from AP's side works.. then the app launches, and by all accounts, it isn't having the desired effect
[22:46] <veebers> balloons: hmm one way to confirm this might be to write a simple qml app that has a text label that displays $HOME. Run that outside autopilot, then run that within autopilot (while patching the env)
[22:47] <balloons> veebers, right.. however seems qml doesn't get access to such things.. So I'm trying to write a qt app that does it
[22:47] <balloons> kind of annoying..
[22:47] <thomi> balloons: launched how? Remember that some apps are launched in a clean environment
[22:47] <balloons> veebers, any thoughts on the launch_dir issue however?
[22:47] <thomi> for example if they're click / ubuntuapplaunch launched
[22:47] <veebers> balloons: not yet, just going to look further now
[22:48] <balloons> thomi, I'm using launch_test_application
[22:48] <balloons> but launch_click_package seems to fail too
[22:48] <balloons> although while we are on the topic.. I noticed there's ubuntuapplaunch and some others as well..
[22:49] <balloons> ahh nvm.. it's a wrapper for upstartapplaunch
[22:49] <balloons> kk
[22:49] <thomi> balloons: upstartapplaunch doesn't exist any more
[22:49] <thomi> it's ubuntuapplaunch now
[22:49] <balloons> hmm.. I still have UpstartApplicationLauncher on my system
[22:50] <thomi> balloons: oh, sure that still exists
[22:50] <balloons> and I've upgraded... maybe this is why I'm seeing import errors for UpstartAppLaunch
[22:50] <thomi> it's public API, so we can't change the name easily
[22:51] <veebers> balloons: are you running T or U? I have a branch that I'm about to land that fixes Upstart -> Ubuntu app launch for T
[22:52] <balloons> veebers, I'm on U.. the weird part is yea, on the desktop I can't use python2 autopilot without the import error
[22:52] <balloons> but casting that aside, stay focused :-)
[22:53] <veebers> balloons: :-) what's the complaint you see when trying to use launch_dir?
[22:54] <balloons> veebers, http://paste.ubuntu.com/7660802/
[22:54]  * veebers looks
[22:55] <balloons> calling like so; http://paste.ubuntu.com/7660804/
[22:56] <veebers> balloons: heh, yeah I can see the issue. It'
[22:56] <veebers> s a bug :-\
[22:56] <veebers> Will file and fix
[22:57] <balloons> ok, good my sanity still exists.. I didn't see it in the arglist, but adding it didn't fix it
[23:00] <veebers> balloons: but I don't have a straight forward answer for your HOME env var question  though :-\
[23:03] <balloons> veebers, that's ok, I'm very close to getting the output from a qt/qml app
[23:03] <balloons> so i'll have more data
[23:03] <balloons> trolled; QML sees home as: $HOME
[23:08] <balloons> veebers, sweet, so I got the env list
[23:08] <balloons> veebers, and home shows correct.. so I guess you are safe on this front :-)
[23:11] <veebers> balloons: heh sweet
[23:12] <veebers> balloons: I was going to suggest: what happens when you launch $APP like: HOM=/tmp/blah <application> ?
[23:12] <balloons> veebers, not a bad idea..
[23:12] <veebers> but I guess you're getting some answers now
[23:12] <balloons> well no.. I'm more confused that ever honestly
[23:13] <balloons> it means everything is being set correct afaict, and the app has HOME set properly. But it completely disregards it
[23:13] <balloons> so that means qmlscene or ?
[23:13] <balloons> I really have no idea
[23:14] <ahayzen> balloons, o/ is this the mediascanner2 issue?
[23:14] <balloons> ahayzen, yes I'm trying to solve music's issue of not having a fresh enviroment
[23:14] <ahayzen> balloons, you sure it is not something to do with mediascanner2 moving to use dbus to communicate
[23:15] <balloons> to be fair I don't know anything at the moment
[23:15] <balloons> since music isn't a compiled app it still might not be working
[23:16] <balloons> and AP in general seems to be misbehaving for me now
[23:16] <ahayzen> balloons, lol ... does autopilot stop/start mediascanner2 or something? i tried doing that manually one time but with no success
[23:17] <balloons> ahayzen, no it doesn't.. I tried messing with mediascanner.. it's a ball of worms
[23:18] <ahayzen> :/ that dbus move has caused chaos it was all working in Malta
[23:18] <balloons> ahayzen, tests as well?
[23:18] <balloons> I'll feel saner if so, haha
[23:18] <ahayzen> balloons, yep end of Malta *everything* was working
[23:19] <balloons> so what on earth changed to make the patching not work since Malta
[23:19] <ahayzen> balloons, we were ready to land then mediascanner2 migrated to using dbus ...and that broke us with the app failing to start ... and then autopilot broke around the same time
[23:20] <balloons> yes, but it's not just you.. all the patched apps don't mock properly anymore
[23:20] <ahayzen> oh god thats not good
[23:20] <balloons> I discovered that with calendar today
[23:21] <ahayzen> but you got calendar working a few weeks ago?
[23:21] <balloons> it still works, but the env is not clean
[23:21] <ahayzen> ah
[23:22] <balloons> for music you guys have to have a clean env
[23:22] <ahayzen> yep
[23:42] <veebers> balloons: I'm about to go for an early lunch, keep me in the loop with your env var findings. I should have a fix for the launch_dir stuff today
[23:42] <balloons> veebers, will do