[12:14] <zul> later
=== Seveas [n=seveas@seveas.demon.nl]  has joined #ubuntu-kernel
=== dmk [n=dmk@host81-156-29-150.range81-156.btcentralplus.com]  has joined #ubuntu-kernel
=== dmk [n=dmk@host81-156-29-150.range81-156.btcentralplus.com]  has left #ubuntu-kernel ["Leaving"] 
=== rtcm [n=jman@217.129.142.72]  has joined #ubuntu-kernel
=== Efwis [n=Ed@colo-02-199.dsl.netins.net]  has joined #ubuntu-kernel
[03:53] <Efwis> i need to find out the location for the C header files in ubuntu that match the kernel, can someone tell me where they are located?
[03:56] <rtcm> Efwis: linux-headers-2.6.12-7 I guess
[03:56] <Efwis> I'll look thanks, need the location to install vmware for linux
=== Efwis [n=Ed@colo-02-199.dsl.netins.net]  has left #ubuntu-kernel ["Leaving"] 
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
[07:09] <fabbione> morning
=== chmj [n=chmj@196.36.161.235]  has joined #ubuntu-kernel
=== Seveas [n=seveas@ksl403-uva-132.wireless.uva.nl]  has joined #ubuntu-kernel
=== chmj [n=chmj@196.36.161.235]  has joined #ubuntu-kernel
=== JaneW [n=JaneW@196.36.161.235]  has joined #ubuntu-kernel
=== chmj [n=chmj@196.36.161.235]  has joined #ubuntu-kernel
=== mdke [n=matt@unaffiliated/mdke]  has joined #ubuntu-kernel
[01:14] <mdke> hi all
[01:15] <mdke> is it intentional that kernel upgrades leave me with multiple entries in grub? I have 2.6.10, 2.6.12-6 and 2.6.12-7 on a machine with a breezy installed at colony 2
[01:16] <chmj> you can remove the others 
[01:16] <fabbione> mdke: yes.
[01:16] <fabbione> that's a normal procedure
[01:17] <fabbione> once you boot in the new one, you can safely remove the old one
[01:17] <mdke> oh
[01:17] <fabbione> it's complex to explain in few words, but that's the correct thing :)
[01:17] <chmj> mdke: in case the new one doesnt work, see ?
[01:17] <mdke> yeah
[01:17] <mdke> will that happen for breezy release too?
[01:17] <fabbione> chmj: no, that's not the reason
[01:18] <fabbione> mdke: the 2.6.12-7 or 2.6.12-9 are not binded to release
[01:18] <fabbione> they are related to some specific changes in the code
[01:18] <mdke> so hoary->breezy updaters will get multiple grub entries?
[01:18] <fabbione> mdke: hoary has 2.6.10-whatever...
[01:18] <fabbione> upgrading you will get 2.6.10-whatver and the 2.6.12-something that will be there at release time
[01:19] <mdke> ouch
[01:19] <fabbione> 2.6.10 will be marked as obsoleted
[01:19] <fabbione> but it can't and won't be removed automatically
[01:19] <mdke> imo users don't really want that stuff
[01:19] <mdke> especially those who don't know what the numbers mean
[01:19] <fabbione> mdke: there is no way to remove it
[01:19] <fabbione> because when you are upgrading hoary -> breezy, you are running 2.6.10
[01:20] <fabbione> and you REALLY REALLY so much do NOT want to remove the running kernel
[01:20] <mdke> is there anyway to have the title of the entry a bit more user friendly? marking one as obsolete will help, perhaps the default one could be titled "ubuntu breezy badger"
[01:20] <mdke> yeah i see the reason
[01:20] <fabbione> mdke: pointless.. aptitude will tell you that
[01:20] <mdke> users don't use aptitude
[01:20] <fabbione> or synaptic
[01:20] <fabbione> or whatever
[01:21] <fabbione> the package is marked as obsolete after the upgrade
[01:21] <mdke> hmm
[01:21] <mdke> so you don't think that the grub titles will bother users who don't know what the numbers mean?
[01:22] <fabbione> mdke: the latest kernel available is always the default in grub
[01:22] <mdke> okay
[01:22] <fabbione> so if a user doesn't touch anything.. it just boots with the most recent one
[01:22] <mdke> sure
[01:22] <fabbione> + you get to have a known to work kernel if the new one doesn't
[01:22] <fabbione> and the latter can unlikely happen
[01:22] <mdke> but when users see the others, they will get confused IMO
[01:23] <fabbione> noone has been complaining till now about it..
[01:23] <fabbione> so i really see no problem in it
[01:23] <mdke> ok
[01:23] <fabbione> the user thinks as 2.6.12-7 is higher than 2.6.12-6 .. it must be better..
[01:24] <fabbione> that's the only thing they see
[01:24] <chmj> normal users hardly ever look at the boot process anyway 
[01:24] <mdke> chmj, they do if they dual boot windows
[01:25] <chmj> hmmm, I suppose 
[01:25] <mdke> anyway, fair enough, i just wanted to ask
[01:34] <mdke> thanks fabbione, chmj 
=== mdke [n=matt@unaffiliated/mdke]  has left #ubuntu-kernel [] 
=== doko [n=doko@dsl-084-059-085-062.arcor-ip.net]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
[02:08] <zul> heylo
=== doko [n=doko@dsl-084-059-085-062.arcor-ip.net]  has joined #ubuntu-kernel
=== rtcm [n=jman@217.129.142.72]  has joined #ubuntu-kernel
=== rtcm [n=jman@217.129.142.72]  has joined #ubuntu-kernel
=== doko [n=doko@dsl-084-059-085-062.arcor-ip.net]  has joined #ubuntu-kernel
=== doko [n=doko@dsl-084-059-085-062.arcor-ip.net]  has joined #ubuntu-kernel
[03:23] <mjg59> BenC: Hmm. The sk gigabit ethernet stuff is proving to be an issue.
[03:23] <mjg59> BenC: We could ship the vendor driver but neuter it so it only binds to devices that aren't supported by the in-kernel one?
[03:24] <BenC> that's a possibility
[03:25] <BenC> has there been any reported issues with the vendor driver for all cards?
[03:25] <BenC> I know it's ugly code (backported it a long time ago to 2.0.34), but it works everywhere I tried it
[03:25] <BenC> not really ugly, but you can tell that it was ported from the win32 driver
[03:29] <mjg59> I haven't /seen/ any reports, but we know that the kernel driver works for most people
[03:29] <mjg59> It may be a bit late to start playing with that and risking instability
[03:41] <zul> mjg59: is that the yukon ethernet?
[03:43] <zul> *sigh* i just love it when a log file fills up a partition
[03:46] <mjg59> zul: Yeah
[03:47] <zul> ah...yeah i think that would be a good idea
[03:48] <zul> then you might want to call it yukon or something and remove it when there is better support for it in the kernel
[03:48] <mjg59> Hmm
[03:48] <mjg59> Oh argh, I'd forgotten what a nightmare of crap this driver is
[03:49] <mjg59> (In terms of its build tree)
[03:49] <zul> because i saw somewhere that yukon support is coming
[03:49] <mjg59> Yeah. With luck, we'll be able to drop it for Breezy+1
[03:49] <zul> BenC: i could look at it tonight if you want
[03:50] <zul> we will need to find someone to test it though
[03:50] <mjg59> zul: I'm hacking a patch to the sk98 driver now. I don't have time to do the kernel integration, though.
[03:50] <mjg59> I'll feed you the diff and you can take a look at it
[03:50] <zul> sure
[03:54] <mjg59> zul: http://www.srcf.ucam.org/~mjg59/tmp/sk98.diff
[03:54] <mjg59> It removes all the IDs that the skge driver supports
[03:55] <mjg59> So apply that to sk98 and merge sk98 into the tree and things should be happy
[03:58] <BenC> sweet
[03:59] <BenC> shoot me an email when it's ready. I wont be doing much more today other than looking at email and IRC every so often
[04:10] <zul> okie dokie ill do it tonight
=== doko [n=doko@dsl-084-059-085-062.arcor-ip.net]  has joined #ubuntu-kernel
[04:26] <zul> BenC: when are you going to do the next upload?
[05:09] <fabbione> re
[05:09] <fabbione> BenC: we need to get OCFS2 1.1.1 in asap
[05:09] <fabbione> can you please coordinate with mdz for when to upload with an ABI bump?
[05:09] <fabbione> because he is stalling us again with some CD issues
[05:22] <fabbione> http://fabrice.bellard.free.fr/tcc/tccboot.html
[05:22] <fabbione> i wonder why gentoo didn't implement this 31337 bootloader yet
=== rtcm [n=rui@217.129.142.72]  has joined #ubuntu-kernel
[05:37] <zul> because they suck..
=== Seveas [n=seveas@seveas.demon.nl]  has joined #ubuntu-kernel
[05:53] <BenC> fabbione: ok
[06:11] <mdz> fabbione: pardon?
[06:50] <fabbione> BenC: perfect
[06:50] <fabbione> mdz: yesterday you told me to wait because you needed a working CD.. 
[06:51] <fabbione> i managed to test the install and it's go for me
[06:51] <fabbione> but not the live :/
[06:51] <BenC> I'm downloading i386 and ppc live cd's to make sure they work
[06:51] <fabbione> i need to send a super rant mail to my ISP
[06:51] <fabbione> BenC: great
[06:52] <mdz> fabbione: the live is the one which was broken
[06:52] <mdz> and the one I asked you to test
[06:53] <BenC> * Node and architecture local files using Context Dependent Symbolic Links (CDSL)
[06:53] <fabbione> it's still rsyncing from this morning and yes i do run rsync at night
[06:53] <mdz> I need to know that we got one working build before another ABI change
[06:53] <BenC> is that like DFS cpu/arch/os symlinking?
[06:53] <mdz> and this needs to be the last ABI change unless there is a security issue
[06:53] <mdz> at least until preview
[06:53] <fabbione> BenC: not sure.. i think so.. but kernel guys didn't like it much
[06:54] <BenC> that's a cool feature
[06:54] <fabbione> mdz: it's not like we like ABI changes.. they are required ...
[06:54] <BenC> will make for some nice v9/v9b stuff on sparc :)
[06:54] <fabbione> mdz: and we can't always avoid them
[06:54] <mdz> fabbione: in this case, it is only needed for OCFS2, right?
[06:54] <fabbione> BenC: eheh
[06:54] <fabbione> mdz: for the changes i did, yes.
[06:54] <mdz> ok, so we need to freeze it after this one
[06:54] <fabbione> mdz: but after you bump the abi, no other checks are done
[06:55] <fabbione> mdz: this is final.
[06:55] <fabbione> for ocfs2 i mean
[06:55] <fabbione> mdz: so BenC or zul might have committed other code that changes the ABI
=== mxpxpod [n=BryanFor@unaffiliated/mxpxpod]  has joined #ubuntu-kernel
[07:12] <BenC> mjg59: ping?
[07:12] <mxpxpod> who is in charge of the linux-wlan-ng patches to the kernel?
[07:13] <mjg59> BenC: Hi
[07:13] <BenC> mjg59: any idea id vga16fb has been tested in 8bpp mode?
[07:13] <BenC> s/id/if
[07:13] <mjg59> Uhm. The "16" in the name is a giveaway :)
[07:13] <BenC> with usplash it is coming up in 4bit
[07:13] <mjg59> It's 16 colour legacy VGA only
[07:14] <BenC> the driver supports 8bpp
[07:14] <mjg59> Seriously?
[07:14] <BenC>         if (info->var.bits_per_pixel == 4) {
[07:14] <BenC>         } else if (info->var.bits_per_pixel == 0) {
[07:14] <BenC>         } else {        /* 8bpp */
[07:14] <mjg59> Uhm.
[07:14] <BenC> checkes for it all over the place
[07:15] <mjg59> Oh
[07:15] <mjg59> In 320x200 it might support 256 colours
[07:16] <BenC> doesn't look like it forces any certain resolution
[07:16] <fabbione> AH GREAAAATTTTT!!!
[07:16] <BenC> vga16fb_check_var() looks like it will accept it
[07:16] <fabbione> rsync.. connection timeout...
[07:16] <fabbione> blabla
[07:16] <mjg59> VGA hardware doesn't support more than 16 colours in 640x480, TTBOMK
=== fabbione starts to write an RFC to his ISP
[07:17] <mjg59> BenC: But if you want to test it, please feel free :)
[07:18] <BenC> I'm not too fluent on vga specs, but the driver is reading like VGA 8bpp is possible
[07:18] <BenC> if the windows installer can do it, we can do it, right? :)
[07:19] <mjg59> Windows installer does 16 colours in that resolution
[07:19] <mjg59> I think, anyway
[07:19] <mjg59> Kconfig says:
[07:19] <mjg59> "This is the frame buffer device driver for VGA 16 color graphic cards"
[07:19] <mjg59> But, well.
[07:20] <BenC> I'll see if it allows fbset to change the bpp
[07:21] <BenC> if it does, and it works, I'll get you a patch for usplash to call the correct ioctl's, and we'll see if it fixes things for folks having problems
[07:21] <mjg59> Ok
[07:21] <BenC> if it does, then debian-installer can use the ioctl's aswell
[07:39] <mxpxpod> if I want to file a bug against the kernel, what package do I put in my bug report?
[07:56] <jbailey> Does qemu actually fire up grub and all that, or does it just chain to the new running kernel?
[07:57] <zul>  if i remember it does the grub 
[07:57] <jbailey> Cool, thanks.
[08:08] <fabbione> <seklos> we ll drop the cdsl stuff out of ocfs2
[08:08] <fabbione> BenC: don't rely on that CDSL feature for too long :(
=== fabbione -> offline
[08:10] <zul> mxpxpod: linux
[08:10] <mxpxpod> zul: thanks
[08:19] <jbailey> zul: Aren't you just Mr. Information today? =)
=== Seveas [n=seveas@seveas.demon.nl]  has joined #ubuntu-kernel
[08:40] <BenC> l
[08:49] <zul> jbailey: heh..i try :)
[09:24] <mxpxpod> zul: know who takes care of the wlan-ng patch?
[09:36] <zul> uh...i made the patch in the first place so i guess i do
=== doko [n=doko@dsl-084-059-092-216.arcor-ip.net]  has joined #ubuntu-kernel
[09:52] <mxpxpod> zul: I just filed bug #14103 relating the the wlan-ng patch
[09:56] <zul> ok
[09:57] <mxpxpod> zul: I hope it's not too late to get an update of that patch into breezy
=== mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net]  has joined #ubuntu-kernel
=== {Seb} [n={Seb}@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
[09:58] <{Seb}> hi people
[09:58] <{Seb}> i've got a kernel module problem with ndiswrapper
[09:58] <{Seb}> anyone around?
[09:58] <{Seb}> i've installed ndiswrapper-utils
[09:59] <{Seb}> and added 'ndiswrapper' to my /etc/modules
[09:59] <{Seb}> but when i boot up, i don't think the module is loading
[10:00] <{Seb}> because it will only continue IF i remove the adaptor?
[10:00] <{Seb}> any ideas?
[10:02] <jbailey> mjg59: I got this at support@canonical.com: "I found your support page that talks about a special version of Ubuntu
[10:02] <jbailey> for the HP NC-6220 laptops."  Any idea what he's talking about? =)
[10:06] <Mithrandir> jbailey: http://www.ubuntulinux.org/support/custom/hplaptops
[10:07] <jbailey> Mithrandir: Ah, thanks. =)  Didn't know about this.
=== Mithrandir waves his l33t google sk1llz
[10:08] <Mithrandir> google://site:*.ubuntulinux.org NC-6220
[10:08] <{Seb}> can anyone help me with this one?
[10:08] <jbailey> *blink* Right.
[10:08] <jbailey> I hate being sick.  I can't think straight.
[10:08] <jbailey> Mithrandir: Thanks.
[10:09] <Mithrandir> (ok, I had to check canonical.com and ubuntu.com first, but still)
[10:16] <{Seb}> who do i need to speak to about this?
[10:21] <jbailey> {Seb}: BenC probably.  zul might be able to help you.  It's mostly a matter of waiting for someone who's around (I don't know what BenC's hours are).  If noone has answered by the time you want to go, I'd suggest filing something in bugzilla.
[10:21] <{Seb}> ok
[10:38] <zul> im heading home...c ya later