[03:33] Sarvatt: /me is going to test as well [06:41] did tangerine changes its host key? [06:44] kees...are you asking that...from blackhat? :-P [06:44] broder: haha, yes, but I see the same host key change from home too :) [06:44] "you just think you're seeing the same host key change from home" [06:45] if so, I'm a certainly doomed :) [06:46] s/ a/ [06:47] is it really kees asking that? :-) [06:47] hehe === Quintasan_ is now known as Quintasan === smb` is now known as smb [07:33] Morning [07:35] kees, In case still interested, yes it did change. And for your convenience we erased all you data in /home === kentb-out is now known as kentb [14:08] * ogasawara back in 20 [14:30] smb: where can I find the new host key? [14:30] kees, i emailed you the fingerprints [14:30] (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] apw: ah, heh, just saw that now :) [14:32] why not keep the host keys when reinstalling? [14:33] kees, heh [14:44] <_ruben> and use the same keys on all hosts just to be on the "safe" side [14:46] kees, of course you'll be phoneing me to confirm _my_ fingerprint [14:46] and set it to 123456 so one can remember [14:59] <_ruben> apw: but how will you know it's kees calling? [15:00] luckily i'd be giving out public information so if its the wrong person it doesn't matter [15:00] <_ruben> true [15:26] sforshee, man, you rox! lol [15:27] ogasawara, apw - could one of you take a pass at https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview and update the linux kernel info? [15:27] skaet: yep [15:27] thanks ogasawara ! [15:27] I will try the lucid backport [15:27] I only need more time here :) [15:32] 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] ogasawara, please do. [15:32] heh [15:32] mfilipe, thanks, but all I did was backport :) [15:33] ogasawara, put it in the new features section. [15:33] skaet: ack [15:33] sforshee, I know but it is 2.6.32 [15:33] backport of natty need be 2.6.38, no? [15:33] mfilipe, did you test it? is it working for you? [15:33] mfilipe, yep, natty is 2.6.38 [15:34] not yet [15:34] I need get free time in work [15:34] tonight I will test it [15:35] 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] ok, certainly I will talk with you about the results [15:36] mfilipe, thanks! [15:48] skaet: https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview#Ubuntu_Kernel [15:49] ogasawara, looks good. Thanks! :) [16:04] Hello! [16:04] maybe sconklin, or bjf can help a bit [16:05] ara, ? [16:05] ara, ask, you never know who might answer [16:05] we had a Lucid kernel SRU released just last week and another one is now in the testing phase [16:06] are we losing the three week cadence? [16:06] (this would be less than 3 weeks) [16:06] ara, no [16:07] ara, give me a sec to find out what is going on [16:09] herton, it looks like you've uploaded a new lucid kernel to fix a single regression, is that correct? [16:09] bjf: yep, was about to tell this [16:09] it was just a new release for 811745 [16:09] *bug 811745 [16:09] Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [High,Fix committed] https://launchpad.net/bugs/811745 [16:09] bug #811745 [16:10] did the previous one make it out to -updates already ? [16:10] yes [16:10] 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] bjf: indeed [16:16] 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] herton, do you know who this was discussed with? [16:17] 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] I told to him about the regression, and he pushed the update [16:20] * herton -> lunch [16:21] ara, ^ [16:22] herton, the lucid that went to -updates last week, was that from this cycle or the previous cycle? [16:22] 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] bjf, is it necessary to do a full testing if it was only 1 fix? [16:23] ara, isn't this the week for cert. testing in the current cycle? [16:25] 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] bjf, with all the changes that we have been doing to adapt to the different uploads, really, we lose track [16:26] ara, not sure i'm following that, you are saying that there have been a number of unanticipated uploads (of kernels)? [16:31] bjf, there must be. If not, how we could have tested last week and also this one? [16:31] (or 2 weeks ago) [16:33] the kernel calendar only shows "one path" where, actually, every series follow their own cadence [16:34] ara, that is true to a point, we try to keep them all in sync and as part of the same cadence [16:35] 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] The next update will be large, and I didn't want to hold this fix for it. [16:36] 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] bjf: previous cycle [16:36] sconklin, could you send to the mailing list the testing that you would be happy with? [16:37] yep [16:37] sconklin, awesome, thanks [16:38] * ara needs to log off now [17:15] * bjf -> quick errand === bjf is now known as bjf[afk] [17:24] * smb -> gone === bjf[afk] is now known as bjf [17:40] * bjf -> back [18:29] * apw performs extensive keyboard surgery [18:38] 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] can you pastebin the output of the pull please [18:39] and when did you last pull? as there may well have been some rebases [18:39] for the derivative branches [18:40] i pulled yesterday and it already downloaded 170mb at 40% [18:40] so it is still loading [18:42] apw, http://paste.debian.net/125127/ [18:42] the hash is from master branch [18:42] when did this pull start [18:43] like 15min ago [18:43] i think the natty lts backport may have been rebased today, but that seems like a lot of objects none the less [18:44] if you are happy to let it finish i'd like to see which refs changed and from and to what [18:44] yeah will do [18:50] apw, http://paste.debian.net/plain/125130 [18:51] ricotz, what do you use as transport? git:// or http:// ? [18:51] the odd thing about that output is all of the updates are fast-forward updates, much as i would expect [18:51] a few commits on any one branch. why you got all those other objects is a mystery [18:53] using git:// [18:54] 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] weird, i need to check the repo config [18:57] ricotz, its not at all obvious how it could be your fault [18:57] i use to define references to save download === med_out is now known as med [19:03] 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] apw, i have no idea, after a rebase it seems normal to a larger diff, but that seems not normal [19:08] anyway thanks for looking at it === hggdh_ is now known as hggdh === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan