| === smspilla2 is now known as smspillaz | ||
| === _salem is now known as salem_ | ||
| === hikiko is now known as hikiko_lunch | ||
| didrocks | hey fginther, how are you? | 13:08 |
|---|---|---|
| fginther | didrocks, good morning. I'm good, how are you? | 13:12 |
| didrocks | fginther: I'm fine thanks! | 13:13 |
| didrocks | fginther: FYI, I changed slightly customise_preseed_file to support "full ppa arg" | 13:13 |
| 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:14 |
| === hikiko_lunch is now known as hikiko | ||
| fginther | didrocks, I'll need to take a closer look. I'm not as familiar with the utah config files as the others | 13:15 |
| didrocks | fginther: ah, do you think the UTAH config changes? | 13:16 |
| fginther | didrocks, not necessarily, I rarely modify it, which is probably why I'm a little behind on what it's doing | 13:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| fginther | didrocks, got it | 13:27 |
| didrocks | fginther: do you have some xml template example to pass parameters to another job? | 13:28 |
| fginther | didrocks, yes, one moment | 13:29 |
| 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:31 |
| didrocks | ok, CurrentBuildParameters | 13:32 |
| 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:33 |
| fginther | yes | 13:34 |
| fginther | didrocks, When using CurrentBuildParameters, any parameter that is not defined in the target job is ignored | 13:34 |
| 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:35 |
| 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:37 |
| dandrader | paulliu, that's the blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-testing | 13:42 |
| 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:43 |
| 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:46 |
| paulliu | dandrader: ok.. got it | 13:47 |
| === francisco is now known as Guest14513 | ||
| === mfisch` is now known as mfisch | ||
| === mfisch is now known as Guest93183 | ||
| 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:23 |
| cyphermox | didn't we already release this kind of changes? | 14:24 |
| mterry | cyphermox, I sure thought so | 14:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| didrocks | ah ok ;) | 14:29 |
| cyphermox | yeah, no extra changes either | 14:29 |
| cyphermox | perhaps there was not publish of indicators since, but I find that hard to believe | 14:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| didrocks | yep ;) | 14:37 |
| cyphermox | urr, wait a second | 14:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| mterry | oh | 14:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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 | 14:51 |
| === Pici is now known as ZarroBoogs | ||
| 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:03 |
| didrocks | (basically, it should only collect the new listed bugs, but still -v<last_published_version_in_distro>) | 15:04 |
| mterry | didrocks, ah. so the changelog and the changes file have different contents finally. :) | 15:05 |
| didrocks | mterry: yep ;) | 15:06 |
| didrocks | thanks fginther :) | 15:07 |
| didrocks | fginther: should we discuss and go ahead for the factorization tomorrow together? | 15:07 |
| 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:08 |
| === Guest93183 is now known as mfisch | ||
| === mfisch is now known as Guest81908 | ||
| didrocks | fginther: excellent, thanks! | 15:09 |
| fginther | didrocks, you're welcome | 15:09 |
| === Guest81908 is now known as mfisch | ||
| kgunn | paulliu: i know you were looking for possible area to dig into some testing....nothing's been done for panel/indicators | 15:14 |
| 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:16 |
| kgunn | paulliu: you could also look for low hanging fruit of fixme/todos in the code base | 15:26 |
| 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 | 15:27 |
| === jhodapp is now known as jhodapp|lunch | ||
| 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:10 |
| 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:11 |
| luv | btw are you based in Finland? I spent one year in Espoo :-) | 16:12 |
| luv | (the interesting bits are around lines 35 - 55 ) | 16:13 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!