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