[06:39] <pitti> Good morning
[07:20] <elfy> balloons: thanks - merged and synced and edited the testsuite - all looks normal now \o/
[10:31] <pitti> jibel: FYI, I'll probably get the wolfes reinstalled in the next days (coordinating with smoser)
[10:31] <pitti> jibel: they will get proper grub so that they will always run the latest kernels
[10:31] <pitti> jibel: I adjusted the setup-adt-lxc.commands to the latest changes (apparmor profiles, proxy, etc.); does the jenkins setup there look sufficient?
[10:32] <pitti> jibel: i. e. install jenkins-slave, write /etc/default/jenkins-slave, start jenkins-slave?
[10:32] <pitti> jibel: i. e. if I'd disable them from jenkins, reinstall them, and re-enable them, should they work? or is there a step missing?
[10:33]  * pitti is eager to try his two-command set up again :)
[11:01] <davmor2> Morning all
[11:10] <jibel> pitti, it should work.
[11:10] <pitti> jibel: merci
[13:24] <pitti> jibel: do you have a way to interpret http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-setup-testbed/148/
[13:24] <pitti> jibel: or is this just jenkins gobbledigok?
[13:38] <jibel> pitti, it is because I forced a rebuild on wazn/amd64 withouth replaying the full matrix
[13:38] <pitti> jibel: ah, thanks
[13:38] <jibel> pitti, in this case jenkins doesn't update the rsult on the master job
[13:40] <venkat> hi
[13:51] <pitti> jibel: FTR, stopping wolfe-03 and 04 from jenkins now, reinstalling those
[14:48] <elopio> davmor2: I can't open the notes app. I have just flashed devel-proposed.
[14:48] <elopio> is that a known issue?
[14:50] <davmor2> elopio: works here
[14:53] <davmor2> elopio: was it a fresh install or an update?
[14:53] <elopio> davmor2: flashed with ubuntu-device-flash
[14:54] <elopio> but I kept my old data.
[14:54] <davmor2> elopio: right so effectively and update then :)
[15:09] <davmor2> elopio: popey can open notes too
[18:08] <elopio> hey robotfuel, this is great: https://developers.google.com/api-client-library/python/guide/mocks
[18:08] <elopio> but how would you tell the rss qml to use the mocks intead of the real ones?
[18:40] <robotfuel> elopio: you tell the rss to look at a local server that returns your mocks, you might have to add an input flag that overrides the default server address.
[18:41] <elopio> robotfuel: that's the part I don't know how to do on the qml + js, overriding the default server.
[18:45] <robotfuel> elopio: they are currently hardcoded so you'd have to change that here http://bazaar.launchpad.net/~ubuntu-rssreader-dev/ubuntu-rssreader-app/trunk/view/head:/GoogleFeedApi.qml
[18:48] <elopio> robotfuel: but is there a way with javascript or qml to get the value from an env variable?
[18:59] <robotfuel> elopio: yes I had to do some looking
[18:59] <robotfuel> elopio: http://askubuntu.com/questions/336083/how-to-use-arguments-in-qml-without-getting-qmlscene-arguments
[19:00] <balloons> oO
[19:01] <robotfuel> elopio: this looks like the best way it's in the sdk http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Arguments/
[19:02] <elopio> robotfuel: nice :D
[19:43]  * elopio goes for lunch.
[20:14] <dkessel> good evening :)
[20:21] <balloons> dkessel, good evening.. How are you?
[20:22] <dkessel> fine, thank you. updating to image 223 on my nexus 7 ;D
[20:23] <dkessel> i also did some package testing of xubuntu yesterday. found a few bugs :)
[20:39] <balloons> dkessel, ubuntu touch not so bad on the nexus 7 is it? I was pleasantly surprised :-)
[20:41] <dkessel> balloons - well i really look forward to another "promoted" image... but anyway, i like it, yes :)
[20:46] <dkessel> mhhh. app icons really should be cached somehow....
[20:48] <dkessel> balloons, good to see nobody has built a "pioneers" port yet :) that's what i plan on doing...
[20:49] <balloons> ohh Siedler!
[20:49] <dkessel> ja :)
[20:53] <dkessel> i need to go, bb
[21:47] <balloons> veebers, if I can get you to leave a comment on https://code.launchpad.net/~veebers/autopilot-qt/reintroduce-exporting-qobject-children-of-qml-items/+merge/207581, I'd appreciate it. Just wondering what the status is. We still have an outstanding mp awaiting it's goodness
[21:49] <thomi> balloons: it changes the order of objects exported by select_many, and several test suites rely (incorrectly) on that order
[21:49] <thomi> so we cannot release it until everyone updates their tests
[21:50]  * balloons facepalms
[21:50] <thomi> we're planning on building it into a PPA, so people can update their suites more easily
[21:50] <thomi> but we're fighting a few fires on othe fronts at the moment
[21:50] <balloons> ok, so hmm..
[21:50] <balloons> I'll update the mp and I guess we'll have to decide
[21:51] <thomi> well, we're still committed to getting it out
[21:51] <veebers> balloons: sorry was making coffee. Yeah it's not good news sorry, what thomi said
[21:51] <thomi> and TBH, it's better that you're blocked
[21:51] <thomi> ...means you'll have motive to fix all the test suites :)
[21:51] <balloons> been blocked for quite some time.. the mp original date is 1-10
[21:51] <veebers> balloons: also, sorry I should have kept you updated
[21:52] <balloons> and been trying to land since the end of Jan ;-)
[21:52] <thomi> yeah
[21:52] <thomi> I know
[21:52] <thomi> it sucks
[21:52] <balloons> <3
[22:13] <balloons> elopio, have you seen this error before? "RuntimeError: Application under test exited before the test finished!"
[22:54] <elopio> balloons: I have, when the app crashes.
[22:54] <balloons> elopio, right.. I guess I'm trying to land my tweaks to the weather app and I want to make sure I'm not causing it
[22:55] <elopio> balloons: are you talking at the branch I approved? That would be highly unlikely, you are not changing any behavior.
[22:56] <balloons> elopio, https://code.launchpad.net/~nskaggs/ubuntu-weather-app/fix-acitivity-timings/+merge/209776
[22:57] <balloons> elopio, we landed a fix for your bug
[22:57] <balloons> without refactoring and changing a bunch, I did tweak the activity timings
[22:58] <elopio> balloons: that's nice. Can I make some suggestions?
[22:59] <balloons> elopio, yes.. for instance, I know you might be able to suggest how to move the common utility check back into the emulator
[22:59] <elopio> balloons: _wait_for_activity should be a public method in MainView
[22:59] <elopio> and probably, a better name is wait_for_activity_to_finish
[22:59] <balloons> elopio, yep I agree.. It was there
[23:00] <balloons> but I didn't take the time to figure out how to wean it off of asserts
[23:00] <elopio> balloons: your problem is with the eventually, right?
[23:00] <balloons> I assume I can cobble something with wait_for
[23:00] <elopio> balloons: that's what I was going to suggest.
[23:01] <elopio> get_activity_indicator, first, make it private, _get_activity_indicator
[23:01] <balloons> I know.. I simply haven't done it
[23:01]  * balloons listens
[23:01] <elopio> then let it just return self.select_single("ActivityIndicator")
[23:01] <elopio> remove the running and the try except.
[23:02] <elopio> now  wait_for_activity_to_finish could be:
[23:02] <elopio> try:
[23:02] <elopio>     self._get_activity_indicator().running.wait_for(False)
[23:02] <elopio> except StateNotFoundError:
[23:02] <elopio>     # No activity in progress.
[23:02] <elopio>     pass
[23:03] <elopio> what do you think?
[23:04] <balloons> ah-hah, me gusta
[23:06] <balloons> yes I feel silly, but I'm pretty bonkers today.. I thought about wait_for for 10 seconds before I did this, and realized, nah, I need a property for it to work
[23:06] <balloons> I'll have to think about it later.. then I use one anyway.. whoops
[23:08] <balloons> ok elopio so I'll pick your brain on one further thing
[23:08] <balloons> inside the tests you'll notice this interesting pair of lines: loadingPage = self.main_view.wait_select_single("Tabs", objectName="rootTabs")
[23:08] <balloons>         self.assertThat(loadingPage.visible, Eventually(Equals(True)))
[23:10] <balloons> in every case he's simply trying to ensure this call works: tabObjects = self.main_view.select_many('LocationTab', objectName='LocationTab'). Thoughts on cleaning that up?
[23:10] <balloons> I ask specifically because the errors I mention above hit on that pair of lines repeatedly
[23:19] <elopio> balloons: hum
[23:19] <elopio> thinking...
[23:20] <elopio> probably, we need to encapsulate that on a wait_for_location_tabs() method
[23:20] <elopio> and there must be a better way to do it.
[23:20] <balloons> yes, obviously methodize it.. but there has to be a better way, exactly
[23:21] <elopio> balloons: this is probably wrong select_many('LocationTab', objectName='LocationTab')
[23:21] <elopio> the objectName should identify uniquely, so when you see it on a select_many, it smells.
[23:21] <balloons> I don't want to dive too deep into the tests, but heh.. slippery slope
[23:22] <elopio> generally, we add an index to the objectName, like, locationTab1. So if you have 3 location tabs, and are waiting for a new one to appear, you would only do
[23:22] <elopio> wait_select_single(LocationTab, objectName='locationTab4')
[23:22] <balloons> right.. if you know you want a second one, which in these tests, that is the case
[23:23] <elopio> I still haven't read all the tests, so I might be wrong, but something like that is what I would try.
[23:23] <balloons> I haven't read everything either.. maybe I'll have to go that far at least
[23:26] <elopio> balloons: and when you find some helpers that are close to what you need, but not quite, it might be that the existent test is taking the wrong approach.
[23:26] <elopio> if that's the case, it's easier to start from scratch than to adjust the helpers.
[23:26] <balloons> yea, see like this test is adding a location. The sane thing to do would be to kill all this silliness and add a single assert to assure the location is added
[23:37] <elopio> balloons: +1. Check that there's one more tab, check that it's selected, and check that the tab title is the same as the city you selected. That should be it.
[23:42] <robotfuel> elopio: balloons are you trying to do the same thing as wait_for_destroyed() with your try except?
[23:43] <balloons> robotfuel, commonly we'll perform an action and then an activity spinner is displayed
[23:43] <balloons> so we want a few things. wait for the spinner to appear, then wait for it to finish and carry on
[23:43] <balloons> however sometimes it'll go so fast, the test will never see the spinner
[23:45] <elopio> balloons, robotfuel: I don't like this. I see this as a thing to add in the design.
[23:45] <elopio> we need a place on the ui where you can tell if something is loading, and it should be consistent on all applications.
[23:45] <elopio> and it should just not be visible if nothing is loading.
[23:46] <elopio> it should never be destroyed.
[23:46] <balloons> elopio, part of the issue with this app is there are multiple activity indicators.. your original suggestion fails because of that :-)
[23:46] <balloons> yes, all unique objects doing the same thing. fun
[23:47] <elopio> balloons: multiple activity indicators in the same app, that surely is a bug :)
[23:47] <robotfuel> elopio: the gallery shows each image loading with an indicator for each, I don't think design will agree
[23:47] <balloons> *as designed*
[23:47] <elopio> robotfuel: well, that could be an exception.