[13:08] <didrocks> hey fginther, how are you?
[13:12] <fginther> didrocks, good morning. I'm good, how are you?
[13:13] <didrocks> fginther: I'm fine thanks!
[13:13] <didrocks> fginther: FYI, I changed slightly customise_preseed_file to support "full ppa arg"
[13:14] <didrocks> fginther: I was thinking we should start deprecating preseed.cfg and only have one autopilot job in the end, what do you think?
[13:15] <fginther> didrocks, I'll need to take a closer look. I'm not as familiar with the utah config files as the others
[13:16] <didrocks> fginther: ah, do you think the UTAH config changes?
[13:20] <fginther> didrocks, not necessarily, I rarely modify it, which is probably why I'm a little behind on what it's doing
[13:21] <didrocks> fginther: do you think you will have time to have a deeper look this week?
[13:21] <didrocks> I think a good target is:
[13:21] <didrocks> - just one autopilot job
[13:21] <didrocks> - we pass ppa (no ppa or CHECK_WITH_WHOLE_PPA means full dist-upgrade)
[13:21] <fginther> didrocks, yes, of course. I just can't give an opinion right now :-)
[13:21] <didrocks> - we can pass installed_package
[13:21] <didrocks> - and a tests list
[13:23] <fginther> didrocks, Oh, then are you thinking of creating a 'generic' autopilot job, which is then called by multiple 'check' jobs?
[13:23] <didrocks> fginther: exactly
[13:23] <didrocks> with different parameters
[13:24] <didrocks> we track the regressions/number of failures per job
[13:24] <fginther> didrocks, then yes. I agree it's a good idea. Will need to study the implementatino
[13:24] <didrocks> great ;)
[13:24] <didrocks> fginther: especially as we have raring/ and head/
[13:24] <didrocks> meaning, doubling the number of jobs
[13:24] <didrocks> so better to have a generic one
[13:25] <fginther> didrocks, speaking of regressions. Have you considered basing regressions on a 'known test failures' list?
[13:25] <fginther> or is that how it works now.
[13:26] <didrocks> basically, we record the number of test failing by $release/$stack/$config
[13:26] <didrocks> so we already have that tracking
[13:26] <didrocks> (the -check job is doing the distribution)
[13:27] <fginther> didrocks, got it
[13:28] <didrocks> fginther: do you have some xml template example to pass parameters to another job?
[13:29] <fginther> didrocks, yes, one moment
[13:31] <fginther> didrocks, we have templates that pass all parameters to another job and a predefine list of parameters...
[13:31] <fginther> in ci/jenkins-templates/autolanding-config.xml.tmpl
[13:31] <didrocks> fginther: the predefine is what I would need. Looking at that, thanks! :)
[13:31] <fginther> The project defined in the builder section passes all parameters
[13:32] <didrocks> ok, CurrentBuildParameters
[13:33] <didrocks> otherwise
[13:33] <didrocks> parameterDefinitions?
[13:33] <didrocks> or rather PredefinedBuildParameters
[13:33] <fginther> yes, PredefinedBuildParameters
[13:33] <didrocks> the separator is \n?
[13:34] <fginther> yes
[13:34] <fginther> didrocks, When using CurrentBuildParameters, any parameter that is not defined in the target job is ignored
[13:35] <didrocks> fginther: ah excellent, so I can even parameterize them right now
[13:35] <didrocks> fginther: even if we didn't merge the "unity autopilot jobs" yet
[13:35] <fginther> didrocks, yes
[13:37] <didrocks> fginther: ok, tell me once you'll have the time to have a look at the rest of the jobs, we can coordinate and planning changing that ;)
[13:37] <didrocks> fginther: right now, I'm changing the triggering template already
[13:37] <fginther> didrocks, good idea. that will make it easier
[13:37] <didrocks> exactly!
[13:42] <dandrader> paulliu, that's the blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-testing
[13:43] <dandrader> paulliu, so after you find the component you wanna test, make sure it's not already being worked on by someone else and add an entry with your task there
[13:46] <dandrader> paulliu, if I'm not mistaken the components under the Panel suddir don't have tests yet. so you might wanna start there.
[13:47] <paulliu> dandrader: ok.. got it
[14:23] <cyphermox> mterry: hey
[14:23] <cyphermox> http://10.97.0.1:8080/view/cu2d/view/Raring/view/Indicators/job/cu2d-indicators-raring-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_hud_13.04.0daily13.04.01-0ubuntu1.diff
[14:24] <cyphermox> didn't we already release this kind of changes?
[14:24] <mterry> cyphermox, I sure thought so
[14:25] <mterry> cyphermox, archive has those changes
[14:25] <cyphermox> weird
[14:25] <mterry> cyphermox, oh
[14:25] <cyphermox> well, I'm going to wait before publishing that anyway, bamf has changes that aren't closing a bug :/
[14:25] <mterry> cyphermox, I think we manually pushed those to archive.  So this may be the automerger catching up
[14:26] <cyphermox> should have been merged in hud a long time ago :)
[14:26] <mterry> cyphermox, I would have thought that too...
[14:26] <cyphermox> anyway, cool, I'll investigate to see why it gets pcked up now
[14:27] <didrocks> mterry: cyphermox: if that was manually uploaded, and was manually merged back, it can appear in the diff
[14:27] <didrocks> mterry: cyphermox: as the diff is bzr diff -r <last autolanding rev> debian/
[14:27] <cyphermox> didrocks: yeah, but if it was manually merged back, that should have happened more than a month ago ;)
[14:28] <didrocks> cyphermox: not if we didn't get anything more to release for bamf?
[14:28] <cyphermox> didrocks: not looking at bamf right now, but hud
[14:29] <didrocks> ah ok ;)
[14:29] <cyphermox> yeah, no extra changes either
[14:30] <cyphermox> perhaps there was not publish of indicators since, but I find that hard to believe
[14:32] <didrocks> fginther: https://code.launchpad.net/~didrocks/cupstream2distro-config/autopilot-jobs-factorization-step1/+merge/156357, do you mind having a look?
[14:32] <didrocks> fginther: some examples of deployement:
[14:32] <didrocks> http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-2.2check/configure
[14:33] <didrocks> http://10.97.0.1:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/configure
[14:33] <didrocks> http://10.97.0.1:8080/view/cu2d/view/Head/view/OIF/job/cu2d-unity-head-2.2check/configure
[14:33] <didrocks> (last one have no parameter, just the ppa one)
[14:33] <didrocks> cyphermox: before you go on manual publishing, I'm deploying a small change for the -check job on indicators
[14:34] <didrocks> cyphermox: done
[14:34] <cyphermox> didrocks: ok
[14:34] <cyphermox> not going to publish this until bamf is fixed
[14:34] <didrocks> ok :)
[14:34] <didrocks> maybe mterry can still publish unity though ;)
[14:34] <didrocks> mterry: btw, I've added the "force manual publishing mode"
[14:34] <fginther> didrocks, taking a look
[14:34] <mterry> didrocks, for raring?
[14:35] <didrocks> mterry: no, in daily release, it's a parameter on the stack, I just need to write the doc ;)
[14:35] <didrocks> so if you want to force that at some point, it's possible :)
[14:35] <mterry> didrocks, yeah, I suppose I can publish unity.  the indicator stack doesn't have any weird FFe API changes or anything, right cyphermox?
[14:35] <mterry> :)
[14:35] <cyphermox> mterry: nope
[14:35] <cyphermox> it's some small bug fixes
[14:36] <mterry> didrocks, ah...  you're talking for unity-greeter.  Cool
[14:36] <didrocks> mterry: yeah, we can build that stack if you feel it and force manual publishing ;)
[14:36] <mterry> didrocks, cool, thanks.  Not urgent now, but maybe post raring
[14:37] <didrocks> yep ;)
[14:37] <cyphermox> urr, wait a second
[14:38] <mterry> didrocks, so are we ready for enabling the "apps" stack for head?  I had it disabled, but if the infrastructure is ready for it...
[14:40] <cyphermox> ok
[14:40] <didrocks> mterry: yeah, it would be good to have an autopilot job (or the factorized one, see my discussion with fginther) for the -check steps
[14:40] <didrocks> mterry: as you know which commands to list and which packages needs to be installed
[14:41] <mterry> didrocks, that's something I can specify in the config file?  OK, will look
[14:41] <didrocks> mterry: see the MP above ^
[14:41] <didrocks> mterry: fresh from the press! :-)
[14:42] <mterry> oh
[14:43] <mterry> didrocks, ah I see, awesome
[14:43] <didrocks> mterry: before those infos were hardcoded in the jenkins job
[14:43] <didrocks> mterry: the goal is just to have one
[14:43] <mterry> indeed, good
[14:44] <didrocks> mterry: I still don't like the fact that we have to hardcode the binaries we want to install (in the not "check with whole ppa") case
[14:46] <mterry> didrocks, couldn't these be moved to dep8 tests?  That way, the info would be in the packaging, in the same branch
[14:46] <didrocks> mterry: dep8 tests are just per packages, not for a whole stack, right?
[14:46] <didrocks> mterry: we can't have autopkgtests with a real machine
[14:46] <didrocks> (so with opengl)
[14:46] <didrocks> which is an issue for unity for instance
[14:48] <mterry> didrocks, oh.  Why can't we test on real machine?
[14:48] <didrocks> mterry: that's why jibel told me, the infra is just on vm and it's not trivial to get a real machine provisionned apparently
[14:48] <mterry> didrocks, weird.  OK.  And yeah, dep8 is per-package
[14:49] <didrocks> mterry: but I agree, I would prefer way more having a per stack/something like dep8
[14:49] <mterry> didrocks, but those tests all live in one package.  And dep8 can specify other packages to be installed
[14:49] <mterry> (I mean, each test lives in exactly one package)
[14:49] <didrocks> that's interesting, we can do that
[14:49] <mterry> didrocks, it's still hardcoding binaries, but you're doing it in the source at least
[14:50] <mterry> didrocks, but the non-real machine is kind of a blocker
[14:50] <didrocks> mterry: indeed, but we need to think of a way of dealing with that better, I agree
[14:50] <didrocks> mterry: the hardcode is used multiple times btw:
[14:50] <didrocks> - only apt-get install <those packages>
[14:51] <didrocks> - filters then that you only get those packages in the pre-seed
[14:51] <didrocks> (if you didn't use "check with whole ppa")
[14:51] <didrocks> that enables us to ensure that you didn't transition an ABI in a stack
[14:51] <didrocks> depending on another stack
[15:03] <didrocks> mterry: FYI, unity is in approved. It will be interesting to see how in production the daily release will handle it tomorrow even if I designed for it :)
[15:04] <didrocks> (basically, it should only collect the new listed bugs, but still -v<last_published_version_in_distro>)
[15:05] <mterry> didrocks, ah.  so the changelog and the changes file have different contents finally.  :)
[15:06] <didrocks> mterry: yep ;)
[15:07] <didrocks> thanks fginther :)
[15:07] <didrocks> fginther: should we discuss and go ahead for the factorization tomorrow together?
[15:08] <didrocks> fginther: I think I'll have some cycles to help
[15:08] <fginther> didrocks, yes. I will have studied up on the utah configuration by then
[15:09] <didrocks> fginther: excellent, thanks!
[15:09] <fginther> didrocks, you're welcome
[15:14] <kgunn> paulliu: i know you were looking for possible area to dig into some testing....nothing's been done for panel/indicators
[15:16] <paulliu> kgunn: yeah. But that's completely new. I'd like to dig into some area that I can read and mimic first to get used to the code.
[15:26] <kgunn> paulliu: you could also look for low hanging fruit of fixme/todos  in the code base
[15:27] <paulliu> kgunn: ok.
[15:27] <kgunn> paulliu: this sheet....has a little map i created....with comments on big/small/prioirty etc
[15:27] <kgunn> paulliu: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoGvOYxwuvpFdEJ5dURFb3Y0cnlKeEcxc0piNDZrWXc#gid=0
[15:27] <paulliu> ok
[16:10] <luv> mardy: moi, Im working on the logout functionality for ubuntu online accounts - so I have put together a python script which simulates the functionality: http://pastebin.blesmrt.net/3135/
[16:11] <luv> though, it looks like signon_identity_signout and signon_identity_remove are pretty much broken ... also UOA plugin for gnome control center can't really deal with an account with deleted identity (and there is more issues :-/),  but that's something I would eventually take care of
[16:12] <luv> btw are you based in Finland? I spent one year in Espoo :-)
[16:13] <luv> (the interesting bits are around lines 35 - 55  )