[03:33] <vanhoof> Sarvatt: /me is going to test as well
[06:41] <kees> did tangerine changes its host key?
[06:44] <broder> kees...are you asking that...from blackhat? :-P
[06:44] <kees> broder: haha, yes, but I see the same host key change from home too :)
[06:44] <broder> "you just think you're seeing the same host key change from home"
[06:45] <kees> if so, I'm a certainly doomed :)
[06:46] <kees> s/ a/
[06:47] <diwic> is it really kees asking that? :-)
[06:47] <kees> hehe
[07:33] <smb> Morning
[07:35] <smb> kees, In case still interested, yes it did change. And for your convenience we erased all you data in /home
[14:08]  * ogasawara back in 20
[14:30] <kees> smb: where can I find the new host key?
[14:30] <apw> kees, i emailed you the fingerprints
[14:30] <apw> (and even signed them)
[14:31]  * smb is much more careless and trusts the key to be right knowing the machine had been reinstalled...
[14:31] <kees> apw: ah, heh, just saw that now :)
why not keep the host keys when reinstalling?</sysadmin>
[14:33] <apw> kees, heh
[14:44] <_ruben> and use the same keys on all hosts just to be on the "safe" side
[14:46] <apw> kees, of course you'll be phoneing me to confirm _my_ fingerprint
[14:46] <smb> and set it to 123456 so one can remember
[14:59] <_ruben> apw: but how will you know it's kees calling?
[15:00] <apw> luckily i'd be giving out public information so if its the wrong person it doesn't matter
[15:00] <_ruben> true
[15:26] <mfilipe> sforshee, man, you rox! lol
[15:27] <skaet> ogasawara, apw - could one of you take a pass at https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview and update the linux kernel info?
[15:27] <ogasawara> skaet: yep
[15:27] <skaet> thanks ogasawara !
[15:27] <mfilipe> I will try the lucid backport 
[15:27] <mfilipe> I only need more time here :)
[15:32] <ogasawara> skaet: should I add an "Ubuntu Kernel" section to the "New features in Oneiric" area? or would you prefer I put our info under a different section?
[15:32] <skaet> ogasawara, please do.
[15:32] <skaet> heh
[15:32] <sforshee> mfilipe, thanks, but all I did was backport :)
[15:33] <skaet> ogasawara,  put it in the new features section.
[15:33] <ogasawara> skaet: ack
[15:33] <mfilipe> sforshee, I know but it is 2.6.32
[15:33] <mfilipe> backport of natty need be 2.6.38, no?
[15:33] <sforshee> mfilipe, did you test it? is it working for you?
[15:33] <sforshee> mfilipe, yep, natty is 2.6.38
[15:34] <mfilipe> not yet
[15:34] <mfilipe> I need get free time in work 
[15:34] <mfilipe> tonight I will test it
[15:35] <sforshee> mfilipe, cool. I'm a little uncertain of the lucid backport since that code has changed quite a bit, so I'm interested to hear if it works.
[15:36] <mfilipe> ok, certainly I will talk with you about the results
[15:36] <sforshee> mfilipe, thanks!
[15:48] <ogasawara> skaet: https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview#Ubuntu_Kernel
[15:49] <skaet> ogasawara, looks good.  Thanks!  :)
[16:04] <ara> Hello!
[16:04] <ara> maybe sconklin, or bjf can help a bit
[16:05] <bjf> ara, ?
[16:05] <apw> ara, ask, you never know who might answer
[16:05] <ara> we had a Lucid kernel SRU released  just last week and another one is now in the testing phase
[16:06] <ara> are we losing the three week cadence?
[16:06] <ara> (this would be less than 3 weeks)
[16:06] <bjf> ara, no 
[16:07] <bjf> ara, give me a sec to find out what is going on
[16:09] <bjf> herton, it looks like you've uploaded a new lucid kernel to fix a single regression, is that correct?
[16:09] <herton> bjf: yep, was about to tell this
[16:09] <herton> it was just a new release for 811745
[16:09] <herton> *bug 811745
[16:09] <ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [High,Fix committed] https://launchpad.net/bugs/811745
[16:09] <apw> bug #811745
[16:10] <apw> did the previous one make it out to -updates already ?
[16:10] <herton> yes
[16:10] <bjf> herton, so I think a little more communication should have been done, we probably should have put that information into the tracking bug and given qa/cert a heads up
[16:10]  * apw wonders if its worth handling that single fix as an upload given the regresion made it into -updates
[16:14] <herton> bjf: indeed
[16:16] <bjf> herton, we decided that since a regression went out in -updates, we wanted to do a quick turn to "fix" that regression and get that into -updates as quickly as possible, correct?
[16:16] <bjf> herton, do you know who this was discussed with?
[16:17] <herton> exactly. Also worth to note that we are in the regression testing week, and thus lucid syncs again with calendar if testing is done this week I think. bjf, sconklin did the packaging
[16:17] <herton> I told to him about the regression, and he pushed the update
[16:20]  * herton -> lunch
[16:21] <bjf> ara, ^
[16:22] <bjf> herton, the lucid that went to -updates last week, was that from this cycle or the previous cycle?
[16:22] <ara> bjf, the problem is that it is very difficult to plan this. We hadn't planned to test this week (nor in the next two weeks)
[16:23] <ara> bjf, is it necessary to do a full testing if it was only 1 fix?
[16:23] <bjf> ara, isn't this the week for cert. testing in the current cycle?
[16:25] <bjf> ara, i've not looked at what was done to fix this regression, so i don't know how much testing is required
[16:25] <ara> bjf, with all the changes that we have been doing to adapt to the different uploads, really, we lose track
[16:26] <bjf> ara, not sure i'm following that, you are saying that there have been a number of unanticipated uploads (of kernels)?
[16:31] <ara> bjf, there must be. If not, how we could have tested last week and also this one?
[16:31] <ara> (or 2 weeks ago)
[16:33] <ara> the kernel calendar only shows "one path" where, actually, every series follow their own cadence
[16:34] <bjf> ara, that is true to a point, we try to keep them all in sync and as part of the same cadence
[16:35] <sconklin> ara: I should have communicated this better. The intention was that with a single fix, this could receive light testing, and we could turn it quickly.
[16:35] <sconklin> The next update will be large, and I didn't want to hold this fix for it.
[16:36] <sconklin> I'm pretty sure I discussed this with someone, but I didn't put it out to your team, as I should have.
[16:36] <herton> bjf: previous cycle
[16:36] <ara> sconklin, could you send to the mailing list the testing that you would be happy with?
[16:37] <sconklin> yep
[16:37] <ara> sconklin, awesome, thanks
[16:38]  * ara needs to log off now
[17:15]  * bjf -> quick errand
[17:24]  * smb -> gone
[17:40]  * bjf -> back
[18:29]  * apw performs extensive keyboard surgery
[18:38] <ricotz> apw, hello, what happened to the lucid kernel repos? it looks like there are only a few new commits, but pulling it results in  a massive download like after multiple rebases
[18:39] <apw> can you pastebin the output of the pull please
[18:39] <apw> and when did you last pull?  as there may well have been some rebases
[18:39] <apw> for the derivative branches
[18:40] <ricotz> i pulled yesterday and it already downloaded 170mb at 40%
[18:40] <ricotz> so it is still loading
[18:42] <ricotz> apw, http://paste.debian.net/125127/
[18:42] <ricotz> the hash is from master branch
[18:42] <apw> when did this pull start
[18:43] <ricotz> like 15min ago
[18:43] <apw> i think the natty lts backport may have been rebased today, but that seems like a lot of objects none the less
[18:44] <apw> if you are happy to let it finish i'd like to see which refs changed and from and to what
[18:44] <ricotz> yeah will do
[18:50] <ricotz> apw, http://paste.debian.net/plain/125130
[18:51] <apw> ricotz, what do you use as transport?  git:// or http:// ?
[18:51] <apw> the odd thing about that output is all of the updates are fast-forward updates, much as i would expect
[18:51] <apw> a few commits on any one branch.  why you got all those other objects is a mystery
[18:53] <ricotz> using git://
[18:54] <apw> then that is just bizarre, as i suspect if you got log --oneline | wc -l  on each of those xxx..yyy it won't add up to more than 3 or 4 commits
[18:57] <ricotz> weird, i need to check the repo config
[18:57] <apw> ricotz, its not at all obvious how it could be your fault
[18:57] <ricotz> i use to define references to save download
[19:03] <apw> ricotz, there are three commits in those ..'s, so why you didn't get those three and only those three i have no idea
[19:07] <ricotz> apw, i have no idea, after a rebase it seems normal to a larger diff, but that seems not normal
[19:08] <ricotz> anyway thanks for looking at it