[06:03] <pitti> Good morning
[07:03] <elfy> morning DanChapman
[07:04] <DanChapman> good morning elfy :-)
[09:48] <jodh> pitti: hi - is the Depends: in d/tests/control as functional as d/control (the dep8 spec does not say)? Specifically, can I use architecture specifications?
[09:56] <pitti> jodh: it gets passed to pbuilder-satisfydepends, so it ought to work
[09:57] <jodh> pitti: ok, thanks. Would be good to have the spec updated on that point.
[10:17] <pitti> jibel: there are a couple of -ppc64 tests on http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/
[10:17] <pitti> jibel: did you add them on purpose, or did they somehow reappear from two weeks ago?
[10:17] <pitti> jibel: i. e. should we just delete them again?
[10:18] <pitti> ah no, they are from Feb 21, I assume I can kill them
[10:20] <jibel> pitti, I didn't readded them, they can be deleted.
[10:20] <pitti> jibel: yup, done
[10:20] <jibel> pitti, actually I don't know how they have been recreated, i'll investigate further
[10:21] <pitti> jibel: they got created during the sprint (last run Feb 21), apparently they just recently (re-)appeared in the private jenkins view
[10:21] <jibel> j-lallement@tachash:/var/lib/jenkins/QA/logs/trusty$ grep ppc64 run-jenkins.trusty.2014030*|grep -v ppc64el
[10:22] <jibel> j-lallement@tachash:/var/lib/jenkins/QA/logs/trusty$
[10:22] <jibel> hm
[10:23] <jibel> pitti, not created by adt-britney
[10:23] <pitti> jodh: tested, Depends: foo [armhf] works
[10:24] <pitti> jodh: the doc says
[10:24] <pitti>   Depends: <dpkg dependency field syntax>
[10:24] <jibel> jenkins' search box, most useless search box I know
[10:24] <pitti> jodh: I don't think we want to copy the dpkg spec there? (alternatives, versions, architectures, etc., it's quite complex)
[10:25] <jodh> pitti: ack - I'm re-running my tests and it has correctly handled multiple architectures being specified.
[10:27] <jodh> pitti: true, but the doc then goes on to talk about dep8-specific depends syntax. I'm not suggesting you copy the dpkg spec, simply that the text of that depends section maybe refers to the relevant section of Debian policy and states that the following special syntax enhances the usual depends syntax (ie @, and @builddeps@).
[10:29] <pitti> jodh: like http://paste.ubuntu.com/7037777/ ?
[10:32] <jodh> pitti: Yes - maybe, "This supports all features of dpkg dependencies, see <https://www.debian.org/doc/debian-policy/ch-relationships.html>. The following additional syntax is permittted:".
[10:34] <pitti> jodh: done in http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=bca85ac
[10:35] <jodh> pitti: great - thanks!!
[10:58] <davmor2> Morning all
[14:40] <elopio> robotfuel: all tests are passing now here:
[14:40] <elopio> https://code.launchpad.net/~elopio/ubuntu-rssreader-app/refactor_tests/+merge/208517
[14:41] <elopio> can you give it another look please?
[14:41]  * robotfuel looks
[14:42] <elopio> balloons: ^ you too, if you have time. That branch was actually your request :)
[15:06] <balloons> elopio, yep, can't wait to have a look
[16:03] <rvr> Now live: http://summit.ubuntu.com/appdevweek-1403/meeting/22131/making-the-perfect-user-acceptance-test/
[16:07] <elfy> balloons: when you're up and about - got a bit of an issue with the tracker
[17:05] <balloons> elfy, shoot
[17:05] <elfy> balloons: can you go here http://iso.qa.ubuntu.com/qatracker/milestones/308/builds/57247/testcases
[17:05] <elfy> we have the same issue going on with 32bit too
[17:06] <elfy> but basically reports are being duplicated across the normal upgrade and the LTS upgrade test
[17:06] <elfy> as always elfy finds something strange to upset balloons day with ;)
[17:07] <elfy> I'm juts going afk for 30 minutes or so
[17:26] <disc0tech> balloons, when you have a few minutes, DanChapman and I were talking earlier about the best way to install packages required for the test (e.g. icecast for setting up a local internet radio station, to test rhythmbox's ability to play internet radio
[17:26] <disc0tech> )
[17:26] <disc0tech> Can be done via test-runner, but we were thinking it should be done in the test using a call to a bash script
[17:30] <balloons> disc0tech, ohh.. interesting. I suppose I would list it as a dependency perhaps
[17:31] <balloons> elfy, ohh. I see now, yes thats a problem
[17:33]  * elfy is pleased that it's not his eyes :)
[17:33] <disc0tech> Where would you list such a dependency, balloons?
[17:37] <elfy> balloons: I don't suppose anyone else has noticed that - only ubuntu and us have upgrade tests for the LTS and the normal upgrade
[17:37] <balloons> stgraber, can you have a look at elfy's issue? Is there something odd about why we're duplicating results in both places? It is using the same testcase for both
[17:39] <stgraber> seems perfectly fine to me
[17:39] <stgraber> results are stored on a buildid+testcaseid basis
[17:40] <elfy> mmmm
[17:40] <stgraber> if you have the same testcase linked twice through two testsuites, it's normal that you see the duplication
[17:40] <elfy> so we'll have to create new ones just for the lts to lts upgrade test?
[17:41] <stgraber> yep
[17:41] <elfy> ok
[17:43] <balloons> elfy, stgraber ty.. so that's it
[17:43] <elfy> balloons: I'll try and do a MP later for two new testcases for upgrade and upgrade(image) so that we can use the new ones for LTS perhaps
[17:43] <balloons> elfy, sounds perfect. thanks for noticing
[17:46] <elfy> balloons: are agreed that we use the new ones for LTS?
[17:51] <elfy> balloons: https://code.launchpad.net/~elfy/ubuntu-manual-tests/upgrades/+merge/209514
[17:51] <elfy> I'm back off for a bit now
[17:59] <balloons> elfy, these are simply duplicates?
[17:59] <elfy> yep
[17:59] <elfy> if there's anything wrong - it's wrong in the originals :p
[17:59] <balloons> elfy, I would suggest simply changing to only check for lts
[18:00] <balloons> + <dd>If you have upgraded from a lts release to lts release, terminal will show Prompt=lts</dd>
[18:00] <balloons> and tweak the normal ones to only check for normal
[18:00] <balloons> make sense?
[18:01] <elfy> none at all - that just means we've got testcases that say something but the tracker still won't differentiate - they need to have different testcaseid
[18:01] <balloons> elfy, ?
[18:02] <elfy> I'm trying to do half a dozen things here - mostly in real life - I don't understand what you mean - and if it means fiddling with the mp then it will have to wait
[18:02] <elfy> bbl
[18:04] <elfy> what I'm not sure of is why we need to write anything in the testcase when the testcase will be in the tracker under LTS and the name is LTS
[18:12] <balloons> elfy, we'll chat later. .I'm feeling the same. I was asking you to modify the expectations for the test check at the end to only refer to lts. And for the other test case, to only refer to normal releases. I'll try and leave a helpful comment
[19:08] <forestpiskie> kids trying to guess passwords, turn machines off in a panic thinking you'd not notice ...
[19:20] <elfy> balloons: I think I see what you were getting at - I pushed it again
[19:56] <robotfuel> elopio: I've approved your MP from earlier.
[20:01] <elfy> balloons: and again when I saw the second comment ... should be right now
[21:53] <balloons> ty elfy :-) approved