[00:01] <elopio> balloons: what do you say about this one? https://code.launchpad.net/~canonical-platform-qa/reminders-app/fix1363599-upstart_and_sandbox/+merge/233832
[14:04] <balloons> elopio, looking at https://code.launchpad.net/~canonical-platform-qa/reminders-app/fix1363599-upstart_and_sandbox/+merge/233832
[14:21] <elopio> balloons: thanks.
[14:33] <elopio> om26er: yesterday I didn't do much on the dashboard. Just a little work  on ^
[14:34] <om26er> elopio, me neither, I was faced with other things. Also struggling to know, is the dashboard now showing everything latest ?
[14:34] <balloons> elopio, left a comment, gonna play with running it now
[14:34] <om26er> when I say latest I mean, is it showing results after your fixes ?
[14:34] <elopio> om26er: it should. I haven't looked yet.
[14:35] <elopio> om26er: the only that was pending was calendar, and balloons just landed it yesterday.
[14:36] <balloons> calendar has fails; it needed a depends specified to jenkins. Next runs should show the proper state
[14:39] <elopio> balloons: working on your comments.
[14:54] <balloons> elopio, it's odd reminders doesn't run for me locally.. it's the same credentials traceback loop
[14:56] <elopio> balloons: hum, works here and on jenkins. What's the message you are getting?
[14:56] <balloons> elopio, like this: http://paste.ubuntu.com/8310029/
[14:57] <balloons> and you have to kill the thread
[14:57] <elopio> balloons: that's the error you get when you don't have the sandbox plugin installed.
[14:58] <balloons> ahh right.. hehy
[14:58] <balloons> I've seen that happen so much, I never even thought about it being valid.. wonder how the package got removed
[15:05] <elopio> balloons: no idea. But when we run with autopkg, it will take care of installing the deps, so I'm not worried about catching that error for now.
[15:06] <elopio> balloons: I replied, fixed and added some more work to the TODO. It's ready for a new review.
[15:13] <balloons> elopio, do you think autopilot should be expanded to support launch_ubuntu_app?
[15:14] <elopio> balloons: it does support launching an random desktop file, if it's on the right location.
[15:15] <elopio> if we are going to be writing many test desktop files like this, I think we should put the helpers on the toolkit.
[15:15] <elopio> most of this code is duplicated from the toolkit, but on the toolkit it's inside a helper that also writes the QML.
[15:15] <elopio> we would need to split the part of the desktop in its own fixture.
[15:16] <elopio> balloons: do you think this is going to be common? Should I file the bug?
[15:18] <balloons> elopio, sorry, otp at the same time. It's worth having a think about. I think we should keep app launching as standard as possible, and I'm wondering if autopilot doesn't need to support this more directly, hence my question. Still, a helper might also make sense, but I'll have to think about it after this call
[17:08] <balloons> elopio, so on rtm, latest image, using the installed click from your branch, I get stuck on processing session, just as before.
[17:08] <knome> balloons, did you fix the tracker already? :P
[17:08] <balloons> knome, I can't login to it.. :-(
[17:08] <knome> hah.
[17:10] <elopio> balloons: that's weird. It has been working, according to the dashboard results.
[17:10] <balloons> knome, I keep bugging is to help.. it's a bad pub key
[17:11] <knome> elopio, he can't login to the production server where the tracker is :)
[17:11] <knome> balloons, naughty key!
[17:12] <balloons> elopio, I agree it's a bit weird, but I am seeing it. Did you run your branch on the device?
[17:12] <balloons> going to run trunk now and see
[17:12] <elopio> balloons: I did. When I proposed it.
[17:12] <elopio> I'm getting it again to run once more.
[17:20] <elopio> balloons: no issues here: http://paste.ubuntu.com/8311092/
[17:23] <elopio> running the full suite. It's currently adding notes.
[17:29] <elopio> the one I can't run on krillin is calculator :/
[17:31] <balloons> elopio, lol.. that one works brillantly for me.. perhaps we simply can't run each other's mp's.. If I recall I was having you run calc on krillin
[17:32] <balloons> elopio, approved and left a comment. I'll look at victor's mp as well. FYI, my suggestion follows what I did in calendar, so you could look and see if you like it. it's in trunk
[17:41] <balloons> knome, just sent off another plea for help. I'm going to be conferencing the rest of the week. I really don't want this to roll on forever
[17:44] <elopio> balloons: you pass the test_type to the app, but you never use it, right?
[17:45] <balloons> elopio, in calendar app? I know I use it in the launcher, but not sure if I do in the tests themselves. I assume there was a reason I was passing it along
[17:45] <knome> balloons, yep.
[17:46] <balloons> there's a couple launchers in calendar, one has a vcard and uses it
[17:46] <elopio> balloons: but the launchers are on the test case, no on the app object.
[17:46] <balloons> elopio, yes. So I would agree it doesn't need to get passed to RemindersApp __init__
[17:47] <balloons> I may have passed it for no reason to calendar.. I only remember using it in the launcher
[17:47] <balloons> if so, shame on me :-)
[17:47] <elopio> balloons: it might be useful for some tests, but I'm not sure which yet :)
[17:47] <elopio> balloons: what the discussion with rvr was about making a fixture to encapsulate all the launchers.
[17:47] <elopio> so we would pass the test type to that fixture.
[17:48] <balloons> I think there does need to be a simplification for launching apps
[17:50] <elopio> balloons: we currently have three cases. We need only two: from branch and installed as click.
[17:50] <elopio> we will be able to remove the deb method that way. But for that we need jenkins to run autopkg tests.
[17:51] <elopio> the "from branch" case can be handled also with ubuntu-app-launch if we put the desktop file on the right place
[17:51] <balloons> elopio, I'm beginning to lose hope on removing the deb packaging ;-) But yes you are correct.. Installed or from tree
[17:51] <balloons> in theory, it's only 1 case
[17:51] <balloons> yes
[17:52] <elopio> balloons: yes, and it seems to be a long way to converge to that one case. Anyway, if we have all the launching things in one file, any changes should be transparent to the tests.
[17:52] <balloons> elopio, so do you see some of this going into autopilot itself?
[17:53] <elopio> balloons: not really. Maybe veebers will see it differently, but I think that autopilot shouldn't start copying desktop files.
[17:53] <balloons> I'm concerned launch_click_package will be effectively deprecated despite being "the way" to launch a click app
[17:54] <elopio> balloons: we need to convince tedg to pass arguments through ubuntu-app-launch. If he insists on having separate desktop files for each application mode we want to test
[17:55] <elopio> then we can still use launch_click_package if the click package ships those desktop files.
[17:55] <balloons> elopio, I can agree with that.. I really don't want to be generating desktop files
[17:55] <balloons> elopio, but if we have to have these helper methods and generate the desktop files, I feel that should go into autopilot itself
[17:56] <balloons> it's not unique to uitk
[17:57] <elopio> balloons: if veebers agree, I won't oppose of course as it will be more on his plate and less in mine :)
[17:57] <balloons> elopio, lol.. I don't think it's the best scenario to play out, but if it has to happen that way, I think that is the place for it to happen
[17:57] <balloons> elopio, do we have a metabug for this?
[18:02] <elopio> balloons: no bug. I'm not sure yet what to report.
[18:02] <elopio> ubuntu-app-launch not passing arguments?
[18:02] <elopio> no testability helper to start an app in a different mode?
[18:02] <elopio> no testability helper to write an alternate desktop file
[18:02] <elopio> ?
[18:04] <balloons> elopio, I would file under ubuntu-app-launch, and bring in autopilot as an also affects (and potentially uitk as well). We can meta out the issues in there
[18:04] <balloons> what we want / need is for ubuntu-app-launch to pass args. Then it's simple
[18:09] <elopio> balloons: ack, on it.
[18:25] <balloons> elopio, one more question on https://code.launchpad.net/~canonical-platform-qa/reminders-app/fix1363599-upstart_and_sandbox/+merge/233832.. is libclick have to be 0.4.0? can be make than >=?
[18:25] <elopio> balloons: 0.4.0 is part of the name of the package.
[18:26] <elopio> we are not specifiying a version for the package, so any libclick-0.4.0 will do.
[18:27] <balloons> elopio, err right.. I guess I was trying to comment on the weirdness of the package.. rather than libclick..
[18:27] <balloons> anyways, I'll top approve if you are ok and push to the store
[18:27] <balloons> we'll need to update jenkins config for the new depends, I'll do that too
[18:28] <elopio> balloons: I'm ok. colin's comment agains using click info --manifest was about not using a versioned API.
[18:28] <elopio> but jenkins has that lib for sure.
[18:28] <balloons> ohh right.. it's in the phone image you are right
[18:28] <elopio> I just added it to make it clear that we depend on that.
[18:29] <balloons> yes, I like that
[18:29] <elopio> but it's unlikely we'll ever run on something without it.
[18:29] <balloons> I don't like hidden depends :-)
[18:30] <elopio> I still don't know where to draw the line of the python testability packages we need.
[18:30] <elopio> I wanted to just call some python module: give me the version of this package.
[18:30] <elopio> but this call to gi.repository.Click is pretty simple.
[18:31] <elopio> on the other hand, if they upgrade to libclick-1, we will have to update. If we have a python testability module, it could handle all the versions we support.
[18:31] <elopio> I don't know. For now, I just want the reminders tests to go back to green so we can continue improving it.
[18:32] <elopio> balloons: please land it when you have some time.
[18:32] <balloons> elopio, +1.. we just want green :-)
[18:32] <balloons> somedays, that is enough
[18:32] <balloons> knome, I'm in!
[18:32] <knome> :)
[18:33] <knome> you got the instructions in PM
[18:33] <elopio> balloons: well, this is also pretty code, don't you think? ;) It's just that we haven't decided if it will be the same way everywhere, and we haven't decided where to put it if we'll need it everywhere.
[18:34] <balloons> elopio, yes.. which is a-ok. We have to test out ideas somewhere
[18:34] <balloons> and yes, the code is a far cry from hacky :-)
[18:34] <balloons> I really like the init's for this stuff now
[18:35] <balloons> we've iterated on them a bunch
[18:46] <balloons> elopio, thanks for the bug. And as always you solve my problems right as I need them solved. We need to pass an arg to file manager and terminal during launch :-)
[18:46] <elopio> balloons: ja, it's funny how we keep in sync without spreadsheets :)
[18:47] <elopio> who would have tought that by comming to this channel to discuss things publicly we need less overhead ;)
[18:48] <balloons> amazing isn't it?
[18:59] <balloons> knome, I can't live-edit production, but it should let me get a local clone up and going
[19:00] <balloons> just in case you thought this would be a quick fix :--)
[19:00] <knome> should be
[19:00] <balloons> if you are confident it will work, we can push to the branch and deploy trunk again
[19:01] <balloons> it's just js updates, so
[19:01] <knome> well,
[19:01] <knome> try what i suggested
[19:01] <knome> if it works, i can push the same code to trunk
[19:02] <knome> but i don't think it's a good idea to push it to trunk if it doesn't work :P
[19:02] <balloons> right.. ok, so we're on the same page. It's just going to take a bit to get what I need setup to try properly
[19:03] <knome> sure
[19:03] <balloons> elfy will just have to suffer :-)
[19:05] <knome> ;)
[19:05] <knome> and i need to run...
[19:05] <knome> i'll be back some time later
[19:05] <knome> good luck! ;)
[19:23] <elfy> balloons: sums it up - break something and wander off ... :p