=== smspilla2 is now known as smspillaz === _salem is now known as salem_ === hikiko is now known as hikiko_lunch [13:08] hey fginther, how are you? [13:12] didrocks, good morning. I'm good, how are you? [13:13] fginther: I'm fine thanks! [13:13] fginther: FYI, I changed slightly customise_preseed_file to support "full ppa arg" [13:14] fginther: I was thinking we should start deprecating preseed.cfg and only have one autopilot job in the end, what do you think? === hikiko_lunch is now known as hikiko [13:15] didrocks, I'll need to take a closer look. I'm not as familiar with the utah config files as the others [13:16] fginther: ah, do you think the UTAH config changes? [13:20] didrocks, not necessarily, I rarely modify it, which is probably why I'm a little behind on what it's doing [13:21] fginther: do you think you will have time to have a deeper look this week? [13:21] I think a good target is: [13:21] - just one autopilot job [13:21] - we pass ppa (no ppa or CHECK_WITH_WHOLE_PPA means full dist-upgrade) [13:21] didrocks, yes, of course. I just can't give an opinion right now :-) [13:21] - we can pass installed_package [13:21] - and a tests list [13:23] didrocks, Oh, then are you thinking of creating a 'generic' autopilot job, which is then called by multiple 'check' jobs? [13:23] fginther: exactly [13:23] with different parameters [13:24] we track the regressions/number of failures per job [13:24] didrocks, then yes. I agree it's a good idea. Will need to study the implementatino [13:24] great ;) [13:24] fginther: especially as we have raring/ and head/ [13:24] meaning, doubling the number of jobs [13:24] so better to have a generic one [13:25] didrocks, speaking of regressions. Have you considered basing regressions on a 'known test failures' list? [13:25] or is that how it works now. [13:26] basically, we record the number of test failing by $release/$stack/$config [13:26] so we already have that tracking [13:26] (the -check job is doing the distribution) [13:27] didrocks, got it [13:28] fginther: do you have some xml template example to pass parameters to another job? [13:29] didrocks, yes, one moment [13:31] didrocks, we have templates that pass all parameters to another job and a predefine list of parameters... [13:31] in ci/jenkins-templates/autolanding-config.xml.tmpl [13:31] fginther: the predefine is what I would need. Looking at that, thanks! :) [13:31] The project defined in the builder section passes all parameters [13:32] ok, CurrentBuildParameters [13:33] otherwise [13:33] parameterDefinitions? [13:33] or rather PredefinedBuildParameters [13:33] yes, PredefinedBuildParameters [13:33] the separator is \n? [13:34] yes [13:34] didrocks, When using CurrentBuildParameters, any parameter that is not defined in the target job is ignored [13:35] fginther: ah excellent, so I can even parameterize them right now [13:35] fginther: even if we didn't merge the "unity autopilot jobs" yet [13:35] didrocks, yes [13:37] 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] fginther: right now, I'm changing the triggering template already [13:37] didrocks, good idea. that will make it easier [13:37] exactly! [13:42] paulliu, that's the blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-testing [13:43] 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] 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] dandrader: ok.. got it === francisco is now known as Guest14513 === mfisch` is now known as mfisch === mfisch is now known as Guest93183 [14:23] mterry: hey [14:23] 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] didn't we already release this kind of changes? [14:24] cyphermox, I sure thought so [14:25] cyphermox, archive has those changes [14:25] weird [14:25] cyphermox, oh [14:25] well, I'm going to wait before publishing that anyway, bamf has changes that aren't closing a bug :/ [14:25] cyphermox, I think we manually pushed those to archive. So this may be the automerger catching up [14:26] should have been merged in hud a long time ago :) [14:26] cyphermox, I would have thought that too... [14:26] anyway, cool, I'll investigate to see why it gets pcked up now [14:27] mterry: cyphermox: if that was manually uploaded, and was manually merged back, it can appear in the diff [14:27] mterry: cyphermox: as the diff is bzr diff -r debian/ [14:27] didrocks: yeah, but if it was manually merged back, that should have happened more than a month ago ;) [14:28] cyphermox: not if we didn't get anything more to release for bamf? [14:28] didrocks: not looking at bamf right now, but hud [14:29] ah ok ;) [14:29] yeah, no extra changes either [14:30] perhaps there was not publish of indicators since, but I find that hard to believe [14:32] fginther: https://code.launchpad.net/~didrocks/cupstream2distro-config/autopilot-jobs-factorization-step1/+merge/156357, do you mind having a look? [14:32] fginther: some examples of deployement: [14:32] http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-2.2check/configure [14:33] http://10.97.0.1:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/configure [14:33] http://10.97.0.1:8080/view/cu2d/view/Head/view/OIF/job/cu2d-unity-head-2.2check/configure [14:33] (last one have no parameter, just the ppa one) [14:33] cyphermox: before you go on manual publishing, I'm deploying a small change for the -check job on indicators [14:34] cyphermox: done [14:34] didrocks: ok [14:34] not going to publish this until bamf is fixed [14:34] ok :) [14:34] maybe mterry can still publish unity though ;) [14:34] mterry: btw, I've added the "force manual publishing mode" [14:34] didrocks, taking a look [14:34] didrocks, for raring? [14:35] mterry: no, in daily release, it's a parameter on the stack, I just need to write the doc ;) [14:35] so if you want to force that at some point, it's possible :) [14:35] 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] :) [14:35] mterry: nope [14:35] it's some small bug fixes [14:36] didrocks, ah... you're talking for unity-greeter. Cool [14:36] mterry: yeah, we can build that stack if you feel it and force manual publishing ;) [14:36] didrocks, cool, thanks. Not urgent now, but maybe post raring [14:37] yep ;) [14:37] urr, wait a second [14:38] 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] ok [14:40] 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] mterry: as you know which commands to list and which packages needs to be installed [14:41] didrocks, that's something I can specify in the config file? OK, will look [14:41] mterry: see the MP above ^ [14:41] mterry: fresh from the press! :-) [14:42] oh [14:43] didrocks, ah I see, awesome [14:43] mterry: before those infos were hardcoded in the jenkins job [14:43] mterry: the goal is just to have one [14:43] indeed, good [14:44] 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] didrocks, couldn't these be moved to dep8 tests? That way, the info would be in the packaging, in the same branch [14:46] mterry: dep8 tests are just per packages, not for a whole stack, right? [14:46] mterry: we can't have autopkgtests with a real machine [14:46] (so with opengl) [14:46] which is an issue for unity for instance [14:48] didrocks, oh. Why can't we test on real machine? [14:48] 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] didrocks, weird. OK. And yeah, dep8 is per-package [14:49] mterry: but I agree, I would prefer way more having a per stack/something like dep8 [14:49] didrocks, but those tests all live in one package. And dep8 can specify other packages to be installed [14:49] (I mean, each test lives in exactly one package) [14:49] that's interesting, we can do that [14:49] didrocks, it's still hardcoding binaries, but you're doing it in the source at least [14:50] didrocks, but the non-real machine is kind of a blocker [14:50] mterry: indeed, but we need to think of a way of dealing with that better, I agree [14:50] mterry: the hardcode is used multiple times btw: [14:50] - only apt-get install [14:51] - filters then that you only get those packages in the pre-seed [14:51] (if you didn't use "check with whole ppa") [14:51] that enables us to ensure that you didn't transition an ABI in a stack [14:51] depending on another stack === Pici is now known as ZarroBoogs [15:03] 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] (basically, it should only collect the new listed bugs, but still -v) [15:05] didrocks, ah. so the changelog and the changes file have different contents finally. :) [15:06] mterry: yep ;) [15:07] thanks fginther :) [15:07] fginther: should we discuss and go ahead for the factorization tomorrow together? [15:08] fginther: I think I'll have some cycles to help [15:08] didrocks, yes. I will have studied up on the utah configuration by then === Guest93183 is now known as mfisch === mfisch is now known as Guest81908 [15:09] fginther: excellent, thanks! [15:09] didrocks, you're welcome === Guest81908 is now known as mfisch [15:14] paulliu: i know you were looking for possible area to dig into some testing....nothing's been done for panel/indicators [15:16] 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] paulliu: you could also look for low hanging fruit of fixme/todos in the code base [15:27] kgunn: ok. [15:27] paulliu: this sheet....has a little map i created....with comments on big/small/prioirty etc [15:27] paulliu: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoGvOYxwuvpFdEJ5dURFb3Y0cnlKeEcxc0piNDZrWXc#gid=0 [15:27] ok === jhodapp is now known as jhodapp|lunch [16:10] 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] 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] btw are you based in Finland? I spent one year in Espoo :-) [16:13] (the interesting bits are around lines 35 - 55 ) === jhodapp|lunch is now known as jhodapp === racarr is now known as racarr|lunch === kdub is now known as kdub^lunch === racarr|lunch is now known as racarr === kdub^lunch is now known as kdub === bschaefer_ is now known as bschaefer === jhodapp is now known as jhodapp|afk === salem_ is now known as _salem === thomi is now known as thomi|lunch