[12:38] <BenC> [g2] : They only get crazier from here out :)
[12:40] <[g2] > BenC, when's release ?
[12:41] <BenC> April 21st
[12:41] <BenC> kernel freeze is coming up too
[12:41] <[g2] > when's the freeze ?
[12:41] <BenC> April 4th
[12:41] <[g2] > thx
[12:42] <JoseStefan> !schedule
[12:42] <JoseStefan> ubotu :(
[12:43] <[g2] > lazy bots
[12:58] <[g2] > BenC is netconsole supported by Feisty ?
[12:58] <[g2] > or usb serial console ?
[12:59] <BenC> No idea, never used either
[02:11] <zul> BenC: ping is the meeting tomorrow?
[02:11] <mjg59> BenC: http://article.gmane.org/gmane.linux.ide/17444/raw looks relevant
[02:12] <BenC> zul: No, next week
[02:12] <zul> sweet, have a good night
[05:12] <crimsun> [g2] : hi
[05:13] <[g2] > hey crimsun :0
[08:51] <ivoks> odd...
[08:51] <ivoks> dapper's doesnt recognize modem on ttyS0, while debian's kernel does
[10:35] <raffytaffy> hi guys ; do the generic kernels for buntu have SpeedStep enabled as module?
[10:57] <kkubasik> not as a single module exactly, but yes, in the generic kernels speedstep is supported
[12:29] <jsaw> hi, anybody around that can help me booting the install CD on a computer with a Promise SX6000...?
[12:33] <jsaw> or how to avoid that the ata subsystem probes harddisks/loads the pdc202xx driver...?
[12:36] <abogani> jsaw: Put the name of the driver in /etc/modprobe.d/blacklist
[12:36] <jsaw> eh, boot-CD?
[12:36] <jsaw> (I'm trying the Feisty-Beta,i386,alternate)
[12:37] <jsaw> ah, ic
[12:37] <jsaw> mount image, edit... ?
[12:38] <abogani> jsaw: It is a very rough way(but works): debootstrap
[12:38] <jsaw> ...damn...
[12:39] <jsaw> btw, will the 2.6.20 be the final kernel for end of April, or is there a chance for 2.6.21, even rc?
[12:43] <jsaw> (because the sx6000 issue seems to be related to commit ca4266359d0c1199af088447f209ab5bcc32a989, http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.21-rc4)
[12:43] <fabbione> .20
[12:43] <fabbione> no way we will change kernel now
[12:43] <jsaw> anyway, I'll try editing the boot CD.
[12:43] <jsaw> ok
[12:44] <jsaw> thanks, I'll come back and report.
[12:44] <jsaw> bye
[01:24] <anti_pop> BenC, around ?
[01:56] <badpsyche> who
[04:02] <rikai> Internets been down for 7 hours. ~.~
[05:07] <thotz> BenC: Am I correct: We only do not want to release the 96xx driver because it does _not_ appear on the nvidia driver download page? Or have I misunderstood something yesterday?
[05:07] <BenC> thotz: no decision is made yet, we are actually discussing what we are going to do
[05:09] <thotz> BenC: I have contacted nvidia support. I can send you the answer they gave me about this driver. I think this will be supported through nvidia as a "new" legacy driver. sending you the mail...
[05:10] <BenC> thotz: thanks, that's useful information
[05:11] <thotz> BenC: This should give you the answer :-)
[05:11] <BenC> thotz: +10 points for following up with the vendor, thanks :)
[05:15] <thotz> BenC: No problem. Hopefully we can find a good solution for this soon.
[05:20] <ivoks> BenC: have some time for dapper kenel debugging? :)
[05:21] <BenC> ivoks: not at the moment (meeting), but for dapper, kylem is da man
[05:21] <ivoks> oh, sorry
[07:21] <mvo> hi kernel team! I'm currently working on making sure in the release upgrader that a new kernel is installed. I got some reports that didn't happen during a upgrade (they were left with 2.6.17 that didn't boot anymore for some reason). what is the most sensible thing to check against? linux-image-generic? this seems to be ok for amd64 and i386, but what about the other arches?
[07:39] <mvo> BenC, kylem: do you have a opinion about the kernel upgrades handling?
[07:40] <kylem> i don't think we renamed any flavours for feisty
[07:40] <BenC> mvo: they need one of the linux-image-* or linux-* or linux meta-packages installed
[07:40] <BenC> mvo: In most cases, linux-image-generic, the linux-generic will include the lrm stuff
[07:41] <BenC> linux for amd64 and i386 is just the same as linux-generic
[07:45] <mvo> ok, thanks. I will ensure that its linux-image-generic if possible 
[07:46] <mjg59> mvo: -386 is also acceptable on i386
[07:48] <mvo> thanks
[08:29] <mvo> [Arch-powerpc] 
[08:29] <mvo> Kernel=linux-image-generic
[08:29] <mvo>  ^--- does that make sense on ppc as well? 
[08:31] <mjg59> mvo: linux-image-powerpc
[08:31] <mjg59> mvo: I'm a little worried about this approach - what about machines using server or bigiron kernels and so on?
[08:31] <mjg59> There isn't a right kernel per architecture, as such
[08:32] <mvo> mjg59: I can give it a list, this is the approach I plan
[08:32] <mjg59> mvo: In that case, just check what packages are built from linux-meta?
[08:32] <mvo> mjg59: but I'm open for suggestions of course. I want to ensure that after the upgrade there is a updated kernel as well
[08:33] <mjg59> Installing a -generic kernel on a system that's been using -386 may break stuff
[08:33] <mjg59> And installing a -powerpc kernel on a system that's running -powerpc64 isn't a good plan
[08:36] <mvo> right. I'm trying to solve the case if the user does not have any linux-image-$flavour package installed (but just linux-image-$ver-$flavour),  does it make sense to auto-install linux-image-$flavour (+ dependencies) in this case?
[08:36] <mjg59> If $flavour is the same in both cases, yes
[08:36] <mvo> the idea with the kernel-arch-list was to check if any of the kernels is installed, fine do nothing. otherwise do something
[08:37] <mvo> ok, I think that is the better approach then
[08:37] <mjg59> $flavour is probably best taken from the running kernel, if possible
[08:38] <mvo> that should be possible, yeah
[08:41] <AnAnt> Hello, I got a question, if there is an application that can enables reading & writing arabic  in virtual console, it used to work in  Edgy, but not in Feisty, can that be kernel related or what ?
[08:41] <mvo> thanks mjg59!
[09:01] <AnAnt> ping
[10:12] <anti_pop> tepsipakki, i tested 2.0 of nv driver, no success. see Bug #96833 for the logfile and let us know, if you need more log's or stuff like that
[11:27] <bdmurray> BenC: ping
[11:27] <BenC> bdmurray: yo
[11:28] <bdmurray> I'm probably late to the party about the nvidia drivers, bug 96430 but one comment mentioned restricted-manager in it.
[11:28] <bdmurray> That seems like it could be an issue to me.
[11:29] <BenC> It wont be
[11:30] <bdmurray> Okay, the restricted-manager won't recommend the nvidia driver for "legacy" cards?
[11:30] <BenC> pitti, mvo and I already discussed the implementation and it will actually be invisible to users whether they are using 9631 or the 9755 driver
[11:30] <bdmurray> okay, cool.  I am late then.