[00:00] <elopio> veebers: alesage: thomi: I now understand how to run lttng and more or less the output it gives us.
[00:00] <elopio> I would like to run this for each app MP
[00:01] <elopio> instead for all the apps at once
[00:01] <thomi> elopio: that sounds like a good idea, but it's not the focus of this sprint
[00:01] <elopio> like,
[00:02] <elopio> thomi: I know. But if I think that this tests shouldn't be handed over to CI, should I still do it?
[00:02] <thomi> elopio: why do you think we shouldn't be handing over app-startup tests to CI?
[00:03] <elopio> thomi: because I think we should hand them over to each app developer.
[00:03] <thomi> elopio: no, this is to measure a baseline.
[00:03] <thomi> we cna work on detecting regressions against the baseline in the future
[00:03] <thomi> (in fact, that work is on our backlog already)
[00:04] <thomi> these need to be running reliably in CI.
[00:05] <elopio> thomi: we need one baseline per app. So to define a baseline we just have to run the tests for one app many times.
[00:05] <elopio> I'm not sure how putting all the apps in the same script helps us defining a baseline.
[00:06] <thomi> Whether all apps are run from the same script, or all run from different branches is an organisational matter. I'm worried that you're now talking about doing work that's outside the scope of this sprint
[00:06] <thomi> CI need to be able to run all the nfss tests daily, and be responsible for infrastructure breakages
[00:06] <thomi> that's the goal of this sprint, nothing more
[00:08] <elopio> thomi: I have thte script for one app now. And can generalize it for many apps. That's one of the goals of the sprint. The second goal is to put it somewhere so it runs continuosly. There's where I think that putting it in a project of its own is not good.
[00:09] <elopio> I'm doing that, but the fact that we have tests without any link to the code that would make them fail makes me throw this question.
[00:13] <thomi> elopio: this isn't a functional test though
[00:13] <thomi> elopio: and we got the reply from CI that the tests should all live in the same place, so it won't be by itself
[00:14] <thomi> it'll be with the other nfss-based tests
[00:17] <elopio> thomi: I will do that. I just think that we are giving something to CI that in order to be useful will have to be moved.
[00:18] <thomi> elopio: eventually, maybe, but I doubt we'll get to that stage any time in the next 6 months, based on our current backlog
[01:28] <Nothing_Much> oh my goodness I forgot about this
[01:28] <Nothing_Much> so I read on the QA mailling list that there was a compromise
[01:28] <Nothing_Much> do I need to change my 1000 character Ubuntu One password?
[01:58] <Nothing_Much> uh okay
[01:58] <Nothing_Much> http://iso.qa.ubuntu.com/qatracker/milestones/326/builds/83014/downloads
[01:58] <Nothing_Much> where are the downloads?
[01:59] <Nothing_Much> if they're at the image.ubuntu.com link, could somebody bring them over to iso.qa.ubuntu.com?
[02:00] <Nothing_Much> *cdimage.ubuntu.com
[07:27] <pitti> Good morning
[07:31] <elfy> morning :)
[10:37] <Nothing_Much> derrr
[10:37] <Nothing_Much> http://iso.qa.ubuntu.com/qatracker/milestones/326/builds/83014/downloads
[10:37] <Nothing_Much> where are the downloads?
[10:37] <Nothing_Much> if they're at the cdimage.ubuntu.com link, could somebody bring them over to iso.qa.ubuntu.com?
[10:48] <slickymasterWork> Nothing_Much -> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20141030.1/
[12:35] <balloons> Nothing_Much, your passwords are fine and not affected at all.. The tracker uses SSO
[12:39] <knome> happy wednesday balloons
[12:42] <balloons> same to you knome
[14:53] <elopio> good
[14:53] <elopio>  morning
[14:54] <balloons> buenos dias elopio
[14:55] <elopio> hola balloons
[15:18] <knome> balloons, poked http://pad.ubuntu.com/uos-1411-improving-manual-testing
[15:19] <balloons> knome, awesome. I'll have a look.
[15:30] <balloons> knome, feel free to poke me if I don't write up a summary of cycle goals after UOS :-)
[15:31] <knome> will try to remember
[15:37] <elopio> ping pitti, are you still here? I'm trying to get app startup tests into dep8 and have a initial question.
[16:20]  * dkessel pokes balloons
[16:21] <elfy> knome: I see you poked that pad so much - that there's almost nothing left on it - what's happened to all the rest?
[16:22] <knome> elfy, there wasn't any content :D
[16:22] <knome> elfy, i had to create the pad ;)
[16:22] <elfy> orite - new pad
[16:23] <elfy> http://pad.ubuntu.com/trackers
[16:23] <knome> yep
[16:23] <knome> the old one is linked from that
[16:23] <knome> or is it?
[16:23] <knome> at least it was at some point..
[16:23] <elfy> ah yes it is - I was only really interested in the bugs - so didn't read *talk* :)
[16:24] <knome> lol ;)
[16:25] <elfy> though I am rather cycnical that most of the bugs will be anything more than Confirmed when we start Wassup Walrus ;)
[16:30] <balloons> hey dkessel I've not forgotten about you at all. Trust me :-0
[16:30] <balloons> My internet has given me some trouble, but you are on the ticket today. I WILL merge your stuff
[16:31] <dkessel> balloons: ok :)
[16:32] <knome> hallo dkessel
[16:33] <dkessel> hallo knome
[16:35] <rhuddie> elopio, hey, how are you getting on with dep8?
[16:36] <elopio> rhuddie: fine I think. I have a debian/tests/appstartup that's running on qemu.
[16:36] <elopio> I'm missing some deps and configs, but it's a start
[16:36] <elopio> rhuddie: how about you?
[16:37] <rhuddie> elopio, I have added some stuff to debian/tests, but getting some errors with adt-run
[16:37] <rhuddie> elopio, the branch I have is here https://code.launchpad.net/~rhuddie/ubuntu-test-cases/healthcheck-to-dep8
[16:38] <elopio> rhuddie: what are the erros?
[16:38]  * balloons chants I will merge, I will merge
[16:39] <rhuddie> elopio, like this: badpkg: got 2 lines of results from extract where 4 expected
[16:39] <rhuddie> elopio, I suspect my debian folder is not configured correctly
[16:40] <elopio> rhuddie: yes, I'm not sure what's that extract about.
[16:41] <elopio> rhuddie: you don't get that error when you just sh debian/tests/health-check, right?
[16:41] <rhuddie> elopio, let me check
[16:44] <elopio> rhuddie: let me see if this attempt works a little better and I'll push what I have.
[16:44] <elopio> I started with a sample debian tree, and cut all the things I think I won't need.
[16:45] <elopio> alesage: how are you doing there?
[16:45] <rhuddie> elopio, seems I get different errors depending on the adt-run parameters I use.
[16:45] <rhuddie> elopio, thanks, I'll take a look
[16:45] <alesage> elopio, I'm just working on getting the lrt tests to run, haven't tried making my own adt-test yet
[17:01] <elopio> rhuddie: http://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-test-cases/autopkg-startup/revision/1
[17:01] <elopio> I first made the qemu image
[17:01] <pitti> elopio: just back from a 2 hour hangout, and collecting IRC pings now (plus, have a phone call now, argh)
[17:01] <elopio> adt-buildvm-ubuntu-cloud -v
[17:01] <pitti> elopio: better just ask :)
[17:01] <elopio> and then adt-run --built-tree=. --- qemu adt-vivid-amd64-cloud.img
[17:02] <elopio> pitti: we have a test suite to measure app startup times. Currently the suite launches all the apps. CI wants to have this converted into something that can be run with adt-run, so while converting it I ended up with a debian package without files to install, just tests.
[17:03] <rhuddie> elopio, thanks. I am running on my device. I'll compare what you have and see how it goes
[17:03] <elopio> pitti: is that ok? to have packages for dep8 tests only?
[17:03] <elopio> rhuddie: my tests fails because ubuntu-app-launch doesn't work without X. I'm trying to solve that.
[17:04] <rhuddie> elopio, at least my tests won't need that :)
[17:04] <elopio> rhuddie: I think they will.
[17:05] <elopio> haven't read your tests, but I think they open apps.
[17:05] <pitti> elopio: why do we need new debs for that?
[17:05] <pitti> elopio: the app startup time for app foo should be in the deb or click for foo
[17:06] <elopio> pitti: that's what I said to thomi. But thomi said that's an organizational issue and for now we should just focus on getting this running.
[17:07] <elopio> and that I should ask you if there's something wrong with having a deb only for ubuntu dep8 tests.
[17:07] <pitti> elopio: we don't need debs at all for dep-8
[17:07] <pitti> at most we need deb or click sources
[17:07] <elopio> pitti: yes, what I have is a debian/control only with sources defined.
[17:08] <elopio> that seems to run ok, but feels weird.
[17:08] <pitti> it is
[17:08] <pitti> if they are currently central, we don't need that
[17:08] <pitti> and if we want to move them to the corresponding apps, these already have existing sources?
[17:09] <elopio> pitti: well, I first have to convince CI, thomi and the team to move them to the corresponding apps. We will talk about it on today's standup.
[17:09] <elopio> pitti: but, where would you put a dep8 test for ubuntu-touch?
[17:10] <elopio> something that tests the system wide user experience of an installed ubuntu as the user will find it?
[17:38] <pitti> elopio: ubuntu-touch-meta perhaps? (still OTP)
[17:38] <pitti> elopio: or touch-session?
[17:39] <elopio> pitti: that sounds better than making a new branch, to me at least. I'll bring that to the meeting.
[17:39] <elopio> thanks.
[17:44] <alesage> elopio ya I don't think LRT, e.g. belongs in any specific source tree
[17:45] <pitti> those could go also into lp:ubuntu-test-cases ?
[17:46] <elopio> pitti: ubuntu-test-cases has no debian package.
[17:46] <elopio> ubuntu-experience-tests does have one.
[17:47] <pitti> elopio: so what, you just need to add debian/tests/control to the branch :)
[17:47] <rhuddie> elopio, thanks for the branch. my stuff seems to work better with that
[17:48] <elopio> rhuddie: cool. I'm still stuck :(
[17:48] <elopio> + initctl set-env DISPLAY=:99 --global
[17:48] <elopio> initctl: Rejected send message, 1 matched rules; type="method_call", sender=":1.11" (uid=1000 pid=8950 comm="initctl set-env DISPLAY=:99 --global ") interface="com.ubuntu.Upstart0_6" member="SetEnvList" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init ")
[17:49] <elopio> pitti: and we also need the debian/control to declare that we are using autopkgtest, right?
[17:50] <pitti> elopio: adt-run doesn't need that, just if we want to treat it as an actual package and auto-run it through britney
[17:50] <pitti> elopio: but we have other kinds of tests anyway which also don't come with debian/control Testsuite:
[17:51] <pitti> elopio: i. e. if the exercise is to get something which you can run with autopkgtest, then debian/tests/ is enough
[17:51] <elopio> I see.
[17:51] <pitti> elopio: if it should manifest itself as an actual source package and we want to gate on dependency changes etc., then this package needs debian/control of course (otherwise you couldn't upload it into ubuntu)
[17:52] <pitti> but I guess CI's main concern is that we can run it on the UCI airline test runner (i. e. the autopkgtest machinery)
[17:52] <pitti> and have the test metadata in teh same format as all the others
[17:52] <elopio> pitti: at some point, we would like that many things trigger this tests, like unity, mir, sdk, ual. But that's out of the scope for this week.
[17:53] <elopio> so we are just getting it to run with adt the most simple way possible
[17:53] <pitti> elopio: ah, so the "dependency change gating"; yes, for that it's much easier if they are in a package which is in ubuntu and actually depends on mir/sdk/etc.
[17:53] <pitti> so ubuntu-touch-meta wouldn't actually be the worst place for that
[17:54] <pitti> ubuntu-touch-session doesn't have a lot of dependencies
[19:49]  * elopio goes lunch