=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-kernel
[01:34] <Kamion> kylem_: yes, feel free to ping me about stuff in edgy d-i
[01:39] <Kamion> kozz: the mkvmlinuz hook problem isn't mkvmlinuz' fault - it's because the kernel's postinst calls update-initramfs, which outputs to stdout and confuses debconf
[01:39] <Kamion> BenC: what's the right answer there, do you think? fix kernel-package to redirect the update-initramfs call 1>&2, or fix update-initramfs to update everything to stderr?
[01:40] <Kamion> from update-initramfs' point of view, it's status information and should go to stdout, so my inclination would be to redirect in the kernel postinst since that's the one with unusual requirements
[01:41] <Kamion> kozz: (20 is debconf's syntax error code; put 'set -x' at the top of /etc/kernel/postinst.d/mkvmlinuz and you'll see the error from debconf which goes '20 Unsupported command "update-initramfs:" (full line was "update-initramfs: Generating /boot/initrd.img-2.6.17-5-powerpc") received from confmodule.')
[01:46] <Kamion> confirmed, sticking >&2 on the end of the kernel's update-initramfs invocation makes debconf-using postinst hooks happy again, will stick that in the relevant bug
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== BenC_ [n=bcollins@72.169.114.90]  has joined #ubuntu-kernel
[05:04] <BenC_> infinity: ping
=== sevrin [n=sevrin@202.75.186.154]  has joined #ubuntu-kernel
[06:25] <infinity> BenC: Pong.  Sorry, was having a much-needed nap.
[06:26] <BenC> infinity: no problem...just wondering, I have a friend with a new toshiba laptop, and the atheros card in it reports "hardware revision too new" when new_ath_pci is loaded
[06:26] <BenC> any ideas?
[06:26] <infinity> We probbaly want a new upstream version, which I was going to pull RSN.
[06:27] <BenC> ok
[06:27] <infinity> By RSN, I mean later today.
[06:27] <infinity> Since I need to make fglrx happy and some other things too.
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #ubuntu-kernel
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #ubuntu-kernel
=== lloydinho [n=andreas@192.38.119.63]  has joined #ubuntu-kernel
[10:46] <kozz> Kamion: yep, you where right, works for me with your patch
=== doko [n=doko@dslb-088-073-097-194.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-212-144-131-067.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== lloydinho_ [n=andreas@192.38.119.63]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-145-254-252-135.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== alleeHol [n=ach@dialin-212-144-130-248.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
[04:42] <BenC> infinity: I'm going to download and try the latest madwifi-ng to see if it works with this
[05:01] <fabbione> hey BenC !
[05:05] <zul> congrats again
[05:05] <fabbione> thanks zul 
[05:06] <fabbione> BenC: can you please pull from my edgy branch? i have a gfs/gfs2/dlmfs update pending from before i left for leave
=== kbyrd [n=Miranda@mailout1.vmware.com]  has joined #ubuntu-kernel
[05:41] <BenC> fabbione: sure thing
[05:41] <BenC> infinity: BTW, the latest madwifi-ng doesn't work with this atheros card still :/
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
[05:54] <fabbione> BenC: great thanks. btw i assume you did pull from me also for the upload i did while you were in holidays
[06:00] <BenC> yeah, got that, thanks
[06:04] <fabbione> no problem at all
[06:04] <fabbione> BenC:  i didn't fix some missing headers on sparc tho
[06:04] <fabbione> that problem still needs to be addressed
[06:09] <BenC> what headers?
[06:10] <fabbione> the one for Xorg at least
[06:10] <fabbione> (that i remember..)
[06:11] <fabbione> we should really cross check with infinity and see.. he has a better access to logs than i do
[06:16] <BenC> fabbione: from what I recall, the one in xorg could be fixed more easily in xorg
[06:16] <BenC> was a bogus include
[06:16] <fabbione> ok.. i don't really care till it gets fixed somehow
[06:16] <fabbione> :)
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
[07:17] <dilinger> BenC: hey, could you pull the changeset that's in #55234 into dapper's kernel when you get the chance?
[07:23] <BenC> dilinger: done
[07:25] <zul> BenC: people have been asking me about xen and 2.6.17 i have a patch without the smp-alt that im currently in the proccess of doing, ill let you know.
[07:40] <dilinger> BenC: thanks :)
=== jbailey [n=jbailey@209.217.74.66]  has joined #ubuntu-kernel
=== lloydinho [n=andreas@rosinante.egmont-kol.dk]  has joined #ubuntu-kernel
[09:46] <jbailey> Something came up while looking at the linux test project with someone at hp.  linux/limits.h defines NGROUPS_MAX, but the value is now available from /proc/sys/kernel/ngroups_max
[09:47] <jbailey> Glibc has supported giving a value through sysconf for some time (although until the 2.4 kernel, the value given was hardcoded from the kernel headers)
[09:47] <jbailey> I suspect that the constant should now be removed from linux/limits.h, since it runs a reasonable chance of being wrong.
[09:48] <jbailey> How do patches like that which aren't for specific subsystems submitted?
[10:05] <BenC> jbailey: not sure, probably wrap it in __KERNEL__ or something
[10:23] <Kamion> jbailey: http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html appears to say that it has to be there anyway
[10:23] <Kamion> "The magnitude limitations in the following list shall be fixed by specific implementations. An application should assume that the value supplied by <limits.h> in a specific implementation is the minimum that pertains whenever the application is run under that implementation. A specific instance of a specific implementation may increase the value relative to that supplied by <limits.h> for that implementation. The actu
[10:23] <Kamion> other sections in that page say that the definition can be omitted if the value is indeterminate, but not that section
[10:56] <jbailey> Kamion: Right, that's value needs to have a minimum guarnateed value, which posix specifies as 8.
[10:56] <jbailey> It looks like the glibc bits/posix1_lim.h file is already setup to provide that if the kernel doesn't.
[10:58] <jbailey> Our headers are setup right now to essentially provide a fixed value that we can't promise from the kernel.  Having the low value there would be sucky, but I wonder if there's a buffer overrun risk by having mismatched values between the kernel and the headers.
[10:58] <jbailey> (This came up somewhat because someone noted that the shipping kernel in Sarge and the shipping headers in Sarge have differing values for this)
[11:30] <Kamion> jbailey: ah right, didn't know glibc provided it
[11:30] <Kamion> I would prefer not massively reducing that value though, if possible
[11:34] <jbailey> I wonder how many programs actually rely on the constant instead of using sysconf correctly?
=== HarrySprocket [n=sam@219-89-12-160.dialup.xtra.co.nz]  has joined #ubuntu-kernel
[11:55] <HarrySprocket> hello
[12:02] <mjg59> BenC: How many patches did you forward-port from 2.6.15?
[12:04] <crimsun> (at least the jack sense blacklist, but that's the only one I know offhand. I know the quiesce-ipw2200 one got dropped)
[12:07] <mjg59> Yeah, I'm just trying to work out how many I need to check out myself