=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
=== jml [n=jml@220-253-100-63.TAS.netspace.net.au]  has joined #ubuntu-kernel
=== zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@16-145.dsl.iskon.hr]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-kernel
=== ivoks_ [n=ivoks@1-0.dsl.iskon.hr]  has joined #ubuntu-kernel
=== Amaranth [n=travis@ubuntu/member/Amaranth]  has joined #ubuntu-kernel
=== someone [n=someone@adsl-71-135-189-174.dsl.pltn13.pacbell.net]  has joined #ubuntu-kernel
=== kunwon1 [n=kunwon1@unaffiliated/kunwon1]  has joined #ubuntu-kernel
=== jml [n=jml@ppp108-61.static.internode.on.net]  has joined #ubuntu-kernel
=== orangey [n=orangey@bas5-london14-1088884563.dsl.bell.ca]  has joined #ubuntu-kernel
[06:10] <orangey> hey all!
[06:10] <orangey> I'm having an issue with suspend/resume on an NC6400
[06:10] <orangey> the keyboard stops working until a command is issued..
[06:10] <orangey> I was wondering how I could propose a patch for something like this without actually fixing the kernel problem..
=== varka [n=varkatop@p54A5F79F.dip.t-dialin.net]  has joined #ubuntu-kernel
=== doko [n=doko@dslb-088-073-088-011.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #ubuntu-kernel
=== varka [n=varkatop@p54A5F79F.dip.t-dialin.net]  has joined #ubuntu-kernel
=== rikai [n=rikai@unaffiliated/rikai]  has joined #ubuntu-kernel
=== mjg59_ [n=mjg59@cavan.codon.org.uk]  has joined #ubuntu-kernel
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-kernel
=== Amaranth [n=travis@ubuntu/member/Amaranth]  has joined #ubuntu-kernel
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-kernel
=== m0rg0th [n=manugarg@220.225.228.97]  has joined #ubuntu-kernel
=== abogani [n=abogani@adsl203-157-083.mclink.it]  has joined #ubuntu-kernel
=== cassidy [n=cassidy@host-213-189-171-21.brutele.be]  has joined #ubuntu-kernel
=== jml [n=jml@59.167.202.141]  has joined #ubuntu-kernel
=== smurf [n=smurf@debian/developer/smurf]  has joined #ubuntu-kernel
=== varka [n=varkatop@p54A5F79F.dip.t-dialin.net]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@35-241.dsl.iskon.hr]  has joined #ubuntu-kernel
=== varka [n=varkatop@p54A5F79F.dip.t-dialin.net]  has joined #ubuntu-kernel
=== sky_walkie [i=czzhrd02@xdsl-563.lodz.dialog.net.pl]  has joined #ubuntu-kernel
=== fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk]  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
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-kernel
=== EtienneG [n=etienne@ubuntu/member/EtienneG]  has joined #ubuntu-kernel
=== stgraber [n=stgraber@ubuntu/member/stgraber]  has joined #ubuntu-kernel
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-kernel
=== Amaranth [n=travis@ubuntu/member/Amaranth]  has joined #ubuntu-kernel
=== zul__ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== rpereira [n=rpereira@ubuntu/member/rpereira]  has joined #ubuntu-kernel
=== cassidy [n=cassidy@host-213-189-171-21.brutele.be]  has joined #ubuntu-kernel
[03:03] <Mithrandir> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97325 ; any idea about this?
=== cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-kernel
[03:08] <rtg> Mithrandir: bug 97325 is so convoluted its hard to tell what he has. Get him to just boot from the live CD and see what his disk arrangement looks like.
[03:09] <Mithrandir> it would probably be better if some kernel person talks to him and gets the needed information from him; he's andersja@gmail.com on jabber.
[03:10] <mjg59_> rtg: I've been looking at the wireless/n-m issue again. As far as I can tell, wpa_supplicant never gets the association message from netlink, despite iwevent showing it
[03:10] <rtg> So, since I touched it last, I'm stuck :)
=== kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu]  has joined #ubuntu-kernel
[03:10] <zul> rtg: pretty much :)
=== orangey [n=orangey@bas5-london14-1088884563.dsl.bell.ca]  has joined #ubuntu-kernel
[03:11] <orangey> hey all!
[03:12] <BenC> rtg: Get dmesg from -14, and lspci -vvn
[03:12] <Mithrandir> would anybody mind if I nuke any kernel modules < 2.6.20 (< 2.6.19 for xen modules) from feisty?
[03:12] <Mithrandir> we seem to ship stuff like the vmware-player-modules for 2.6.15
[03:13] <zul> xen-source uses 2.6.19
[03:14] <maks_> xen is pretty unstable on 2.6.20
[03:14] <zul> but I would kill linux-source-2.6.19 ;)
[03:14] <_ion> benc: It was intentional to put nvidia_new as the last item in the nvidia_supported line in debian/rules, right?
[03:14] <BenC> _ion: Is ordering importing?
[03:14] <BenC> err, important
[03:15] <BenC> I need another lrm upload to fix the ppc ftbfs anyway
[03:15] <BenC> _ion: should I make _new first?
[03:15] <BenC> Mithrandir: for feisty, there should be only 2.6.20
[03:16] <BenC> well, and 2.6.19 for xen I guess
[03:16] <Mithrandir> BenC: yup, just wanted to make sure
[03:17] <orangey> hmmm. I know it's a basic question, but this is the first time I use linux on a multi-core.. do I use -generic for it? or 686-smp?
[03:17] <Mithrandir> orangey: -generic
[03:17] <zul> BenC: the 2.6.20 xen patch from fedora doesnt work too well
[03:17] <BenC> Mithrandir: in regards to the kernel plans for release, I was hoping the kernel-team could work on release-critical bugs this week, and we could do a non-abi changing upload this weekend post-RC
[03:17] <BenC> Mithrandir: That sound ok?
[03:17] <_ion> benc: I should have commented it more, but there was a comment in nvidia_supported itself. The first argument describes the preferred driver and the ones that follow are fallbacks. With the current state, nvidia_new is only used if neither nvidia or nvidia_legacy support a given PCI ID. To prefer nvidia_new whenever it supports the card, use nvidia_supported $(rbuilddir)/$$i/nv-new/nv-kernel.o nvidia_new $(rbuilddir)/$$i/nv/nv-kernel.o nvidia ...
[03:17] <BenC> orangey: -generic is SMP
[03:17] <_ion> ... $(rbuilddir)/$$i/nv-legacy/nv-kernel.o nvidia_legacy
[03:18] <BenC> _ion: That's not so bad really
[03:18] <Mithrandir> BenC: ugh, not very happy about that.
[03:18] <Mithrandir> BenC: give me a bit of time to discuss it?
[03:18] <mjg59_> Mithrandir: Right now the HPA stuff is still a serious regression
[03:19] <BenC> Mithrandir: well, we have some fixes to get out, and getting an upload done in time for RC is just not possible
[03:19] <_ion> benc: Kind of true, since 97xx hasn't received as much testing as 96xx.
[03:20] <BenC> Mithrandir: we will make every effort to ensure it wont change ABI though, so we can pretty much guarantee that -14 will be the released ABI...with an upload this weekend, it still gives us plenty of time to CD test the new kernel
[03:21] <_ion> benc: But at least for feisty+1, the drivers probably should be prefered in the order of descending version number.
[03:23] <orangey> Mithrandir and BenC: Thank you.
[03:23] <orangey> now to try to fix Bug #105155 : )
[03:23] <BenC> _ion: right...for not, I'll leave it, and just let 9755 be chosen for cards so new they need it
[03:23] <BenC> erg, "for now"
[03:23] <_ion> benc: All right.
[03:24] <BenC> _ion: guess it was a decent mistake to make...oh, and thanks for all your help with it
[03:24] <BenC> pity it took me so long to get things out
[03:24] <BenC> it's was a horrid mess
[03:24] <_ion> Thanks for your trouble. I realize you have a lot to do, especially just before a release. :-)
[03:25] <_ion> I take it the patch that actually modifies the modules' alias lists is also going to get to feisty+1?
[03:26] <_ion> Just installing the override files to /usr/share/l-r-m is okay, restricted-manager has already been modified to read them.
[03:26] <_ion> But it would naturally be quite nice to get the accurate lists from the modules themselves.
[03:29] <BenC> _ion: I'm not sure of the side effects of putting actual module aliases in there
[03:30] <BenC> worried about autoloading and such
[03:30] <BenC> kylem: Do you have a comparison handy of the ABI changes from the HPA patch?
[03:30] <kylem> yeah
[03:30] <_ion> benc: The current aliases in the modules are only *broader*. If the modules are being autoloaded with the modified patterns, they're *definitely* being autoloaded with the current patterns.
[03:31] <cjwatson> not massively happy about overriding abichecker warnings - nearly every time we've done that before it's bitten us, and we swore not to do it again
[03:31] <BenC> cjwatson: well, before we ignored actual ABI changes
[03:31] <kylem> iirc this one only effects libata-core symbols
[03:31] <kylem> there should be no binary modules like that...
[03:32] <BenC> cjwatson: the problem with the checker is that it is not smart enough to tell when a function moves without change
[03:32] <BenC> cjwatson: moving without change really isn't a problem so long as all the symbols stay in the same package
[03:33] <_ion> benc: But anyway, the current way is fine for feisty.
[03:33] <BenC> but I worry that HPA does more than move the symbols
[03:33] <kylem> BenC, it doesn't change function prototypes or anything
[03:33] <BenC> _ion: I'm following KISS right now :)
[03:33] <_ion> benc: Yeah. :-)
=== shawarma [n=sh@atlas.linux2go.dk]  has joined #ubuntu-kernel
=== giangiva [n=giangiva@adsl203-157-083.mclink.it]  has joined #ubuntu-kernel
=== giangiva [n=giangiva@adsl203-157-083.mclink.it]  has joined #ubuntu-kernel
=== shawarma [n=sh@atlas.linux2go.dk]  has left #ubuntu-kernel [] 
=== AlinuxOS [n=vsichi@host216-173-dynamic.61-82-r.retail.telecomitalia.it]  has joined #ubuntu-kernel
[03:48] <rtg> mjg59_: I'm not ignoring you. I just have too many balls in the air. I'm also looking at wpasupplicant source. 
[03:49] <mjg59_> rtg: No problem
=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
[03:54] <kylem> BenC, kyle.mcmartin.ca/abi
=== abogani [n=abogani@adsl203-157-083.mclink.it]  has joined #ubuntu-kernel
[04:00] <mjg59_> kylem: Good to go with the HPA code and the lba48 fix
[04:01] <kylem> you're sure?
[04:01] <mjg59_> Yes
[04:01] <kylem> and it's using piix?
[04:01] <mjg59_> It's coming up with ata_piix and I'm getting good values
[04:01] <kylem> can you try a cold boot?
[04:01] <mjg59_> That was a cold boot
[04:01] <mjg59_> Want me to try a warm one?
[04:02] <kylem> sure.
[04:05] <mjg59_> kylem: Still good. Ship it.
[04:05] <kylem> thanks.
=== giangiva [n=giangiva@adsl203-157-083.mclink.it]  has joined #ubuntu-kernel
=== Starting logfile irclogs/ubuntu-kernel.log
=== Starting logfile irclogs/ubuntu-kernel.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #ubuntu-kernel
=== Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-14.22 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 352 Open, 6 Unconfirmed, 6 Unassigned
=== Topic (#ubuntu-kernel): set by BenC at Sun Apr  1 19:07:28 2007
[04:28] (rtg/#ubuntu-kernel) BenC: looking...
[04:33] <zul> yay..
[05:00] <BenC> maks_: ping
[05:01] <maks_> BenC: around
[05:01] <maks_> btw i switched initramfs-tools repo to git
[05:01] <BenC> maks_: Hey, where's the patch that makes update-initramfs pull the .bak when it fails for kernel version?
[05:01] <maks_> yes
[05:02] <maks_> directly out of LP, let me dig the bug nr
[05:02] <maks_> -> http://git.debian.org/?p=kernel/initramfs-tools.git;a=commitdiff;h=5dfd85f416a10b1c41ca7005de38b58715c04472;hp=c4343742b3bf028e467ac8a58ead95c9bfefc628
[05:03] <BenC> maks_: thanks
[05:03] <kylem> mjg59_, do we want to keep my reprogram piix as ahci patch anyway or should i turf it?
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== johanbr [n=j@JBrannlund.MathStat.Dal.Ca]  has joined #ubuntu-kernel
[05:32] <kylem> ok good
[05:32] <kylem> it wasn't me who broke the abi now. ;-)
[05:32] <kylem> something is friggity fucked, i'm getting the same abi differences with the patches reverted.
[05:33] <kylem> and i know they actually reverted since i'm getting the kvm diff too
[05:34] <rtg> BenC: I just emailed a proposed patch for bug #96480. Lemme know if it seems reasonable.
[05:43] <maks_> BenC: np, patch works for given testcase :)
=== Eruantalon [n=hans@5634185c.rev.stofanet.dk]  has joined #ubuntu-kernel
[05:50] <BenC> rtg: reviewing
[05:53] <BenC> rtg: I think the missing element is setting adapter.name...all the other i2c_add_adapter() uses I see don't need to call device_initialize(), but they do set .name
[05:55] <rtg> BenC: You might be right. device_register() calls device_initialize().
[05:57] <pkl_> The "**WARNING** I2C adapter driver []  forgot to specify physical device; fix it!" message itself is harmless
[05:57] <rtg> pkl: except for the name which is NULL.
[05:58] <pkl_> yeah
[05:58] <pkl_> I've chery-picked a patch from 2.6.21-rc1 that remove that warning.
[05:59] <BenC> that shows up for nvidia too
[05:59] <pkl_> s/chery/cherry/
[05:59] <BenC> or maybe it was ati
[05:59] <BenC> rtg: Could you see about getting a built kernel to that person for testing?
[05:59] <BenC> rtg: Might be able to get away with just sending them the module compiled for -generic if they seem capable enough to add it in /lib/modules/...
[06:00] <rtg> BenC: Yes. I'm still trying to figure out what the name should be.
[06:00] <BenC> "ACPI EC HC smbus driver"
[06:00] <BenC> seems ok
[06:00] <rtg> Isn't there an instance number?
[06:01] <BenC> snprintf(smbus->adapter.name, I2C_NAME_SIZE,
[06:01] <BenC>                 "SMBus nForce2 adapter at %04x", smbus->base);
[06:01] <BenC> guess you can do something like that
[06:01] <rtg> BenC: I'm looking upstream to see what they have done.
[06:01] <BenC> ok
[06:05] <mjg59_> kylem: Eh, depends if you think it's worth it. It's certainly not high-risk.
[06:05] <mjg59_> Sorry, certainly not high-priority
=== pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl]  has joined #ubuntu-kernel
[06:16] <kylem> yeah
=== _MMA_ [n=mma@cpe-071-070-203-016.nc.res.rr.com]  has joined #ubuntu-kernel
[06:26] <BenC> ok, I've had my morning burn in time, need lunch
=== AlinuxOS [n=vsichi@host216-173-dynamic.61-82-r.retail.telecomitalia.it]  has joined #ubuntu-kernel
=== _MMA_ [n=mma@cpe-071-070-203-016.nc.res.rr.com]  has left #ubuntu-kernel [] 
[06:40] <BenC> Looks like today might be a good day to start on feisty+1 kernel tree
[06:40] <zul> yay!
[06:40] <BenC> looking forward to dumping kernel-package from build-deps
[06:41] <zul> BenC: I think everybody is
=== kylem really thinks we should re-evaluate the effectiveness of git though...
[06:41] <zul> *cough* mercurcial *cough*
[06:41] <BenC> kylem: I think removing the ubuntu/* stuff from our main tree will help alleviate most of our problems
[06:42] <kylem> no. but it really makes it quite difficult to see precisely what code we changed.
[06:42] <BenC> git-diff-tree upstream-linux..HEAD
[06:42] <zul> BenC: the cp build/vanilla build/ubuntu-xen idea is still ok isnt it?
[06:42] <kylem> that doesn't work nearly as well as you'd think
[06:42] <kylem> and provides no context
[06:43] <BenC> kylem: I think if I also started enforcing a rebase instead of just merging, it would go a long way to help that too
=== AlinuxOS [n=vsichi@host216-173-dynamic.61-82-r.retail.telecomitalia.it]  has joined #ubuntu-kernel
[06:44] <kylem> keeping all patches in quilt and keeping the quilt-with-all-patches tree in git would not be too bad...
[06:45] <kylem> but yea, i agree
[06:45] <kylem> ubuntu/ out of the maintree would help phenomenally.
[06:45] <cjwatson> building in .diff.gz mode way earlier would help
[06:46] <BenC> cjwatson: we might be able to do that for feisty+1 with ubuntu/* in a separate package
[06:46] <BenC> it's all our third part drivers that kept that from being sane
[06:46] <BenC> *party
[06:47] <cjwatson> well, also basing on 2.6.20 before it was out
[06:47] <zul> keeping an ubuntu/patches list would be cool for 3rd party crack (ie: xen openvz)
[06:47] <BenC> the other problem is the amount of actual patches we have to the main repo
[06:47] <BenC> we have patches we've been carrying around since breezy because upstream wont take it, or the real fixes are "being worked on"
[06:48] <kylem> well, with a bigger kernel team, it's possible we'll actually be able to do proper fixes for some of them, no?
[06:48] <BenC> yeah, I'm hoping that's what happens :)
[06:48] <zul> community can help as well ;)
[06:49] <BenC> once I get feisty+1 tree open, we can identify them, and work to have them upstream for next kernel
[06:50] <BenC> based on release times, I think feisty+1 will end up being 2.6.22, so that gives us that merge window to send things to linus et al
[06:52] <BenC> it's cool that feisty will end up releasing with the latest stable kernel version instead of a 1 or 2 out version :)
[06:52] <cjwatson> I think that's worked out relatively well and will work well for feisty+1 too, but maybe not for feisty+2
=== doko [n=doko@dslb-088-073-088-011.pools.arcor-ip.net]  has joined #ubuntu-kernel
[06:53] <cjwatson> or whichever ends up being LTS (but current projection is feisty+2 I think)
[06:53] <kylem> so next october would be LTS?
[06:53] <BenC> yeah, we'll need more cooking time on that one
[06:54] <cjwatson> feisty+2 == April 2008
[06:54] <kylem> ah, right
[06:55] <BenC> FYI, I'll be moving ubuntu-2.6.git over to ubuntu-feisty.git sometime in the next few days
[06:56] <BenC> so if ubuntu-2.6 goes missing, or shows up as not of the same parent, you'll know why :)
[06:56] <kylem> would it not be easier just to name them ubuntu-${mascot} from the beginning :)
=== kylem ducks & runs.
[06:57] <BenC> that would be like intuitive or something...not really my style
[06:57] <zul> hah
[06:57] <kylem> :P
=== AlinuxOS [n=vsichi@host216-173-dynamic.61-82-r.retail.telecomitalia.it]  has joined #ubuntu-kernel
[06:57] <BenC> problem is I don't know $mascot for feisty+1 yet :P
[06:58] <kylem> i don't think it's been announced yet, so you have a point there, :\
[06:58] <zul> how about ubuntu-dev
[06:58] <BenC> not really much better than ubuntu-2.6
[06:59] <zul> ubuntu-im-going-to-break-it-nyeah-nyeah.git
[07:03] <BenC> ubuntu-good-bear.git
[07:03] <kylem> BenC, *shudder*
[07:04] <BenC> And anyone that corrects me on why that isn't a good bear, gets the award for being most pedantic :)
=== btse [n=BTSE@c83-253-228-44.bredband.comhem.se]  has joined #ubuntu-kernel
=== kkubasik [n=kjk38@kjk38-laptop.student.cwru.edu]  has joined #ubuntu-kernel
=== lamont` [i=lamont@nat/hp/x-b4f37b0b86ac179e]  has joined #ubuntu-kernel
=== varka [n=varkatop@p54a5dc2e.dip.t-dialin.net]  has joined #ubuntu-kernel
=== m0rg0th [n=manugarg@219.64.120.181]  has joined #ubuntu-kernel
=== stgraber [n=stgraber@ubuntu/member/stgraber]  has joined #ubuntu-kernel
=== Traveler2345 [n=Traveler@cable-dynamic-87-245-85-85.shinternet.ch]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
[08:20] <rtg> BenC: I still think bug #96480 is because of an uninitialized device structure. I'm betting it is an uninitialized parent in device_add():464. Could this be a race with platform_bus_init()? I'm almost sure that could be the case in 2.6.20-20.12 when folks get the "forgot to specify physical device" message.
=== doko_ [n=doko@dslb-088-074-012-109.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== JanC [n=janc@dD5764BF4.access.telenet.be]  has joined #ubuntu-kernel
=== JanC_ [n=janc@dD5764BF4.access.telenet.be]  has joined #ubuntu-kernel
=== sacater_ [n=sacater@213.131.245.105]  has joined #ubuntu-kernel
=== bleinmono [n=toffel@ppp91-76-75-145.pppoe.mtu-net.ru]  has joined #ubuntu-kernel
=== sacater_ [n=sacater@host81-152-157-46.range81-152.btcentralplus.com]  has joined #ubuntu-kernel
=== arun_ [n=arun@chobie.cs.Virginia.EDU]  has joined #ubuntu-kernel
=== arun_ is now known as arun
=== kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu]  has joined #ubuntu-kernel
=== rpereira [n=rpereira@ubuntu/member/rpereira]  has joined #ubuntu-kernel
=== infinity2 [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
=== Eruantalon [n=hans@5634185c.rev.stofanet.dk]  has joined #ubuntu-kernel
=== jbailey [n=jbailey@modemcable178.77-70-69.static.videotron.ca]  has joined #ubuntu-kernel
[10:46] <jbailey> BenC: Around?
=== _fs [i=fs@213.178.77.100]  has joined #ubuntu-kernel
=== JanC [n=janc@lugwv/member/JanC]  has joined #ubuntu-kernel
=== Keybuk [n=scott@82.108.80.247]  has joined #ubuntu-kernel
=== _fs is now known as fs
=== _fs [i=fs@213.178.77.100]  has joined #ubuntu-kernel
=== anti_pop [n=anti_pop@p54b0991e.dip0.t-ipconnect.de]  has joined #ubuntu-kernel
[11:25] <BenC> jbailey: yeah
[11:27] <anti_pop> sorry, i know its not a support channel. but i cant find an answer: should i use the -generic kernel oder -386 (my cpu is amd athlon xp)
[11:27] <jbailey> BenC: Heya, I don't think we ever finished talking about the best way for out-of-tree modules to get updated.
[11:27] <jbailey> BenC: Is now a good time?
[11:27] <BenC> jbailey: given the recent experience with vbox, I'm leaning toward not putting them in the kernel :)
[11:28] <Nafallo> anti_pop: generic, as the description says.
[11:29] <jbailey> BenC: Right, so I think we were last stuck at the fact that I was concerned that building them on boot meant that boot time wouldn't be deterministic after an upgrade.
[11:29] <BenC> jbailey: ah, right
[11:29] <BenC> jbailey: should we reserve some topic time at UDS?
[11:30] <anti_pop> ok, thats what i used to. but somehow im running -386 now, will return to generic. thanks to the team for providing nvidias 9631 driver now (!)
[11:30] <BenC> will you be there?
[11:30] <jbailey> I won't be.  I'm giving a talk at JavaOne this year.
[11:30] <BenC> jbailey: will anyone from support be there?
[11:30] <jbailey> Besides, after the stories of the last trip to Spain, I think this vegan can stay home. =)
[11:30] <jbailey> Yup, Etienne and Fabian will both be there.
[11:31] <BenC> Ok, from what I understand the kernel team will have a room reserved for adhoc discussions, so maybe this is a good topic for rounding those two up
[11:31] <jbailey> Etienne will certainly want it fixed, I'm not sure if he cares much what the solution is, so long as there's something standard he can plug into.
[11:31] <jbailey> Ah, nice.
[11:31] <jbailey> If you're gobbied up and I'm not on the west coast at that particular moment,  I'll try to tune in.
[11:31] <jbailey> I suspect I will be.  I'm in the bay area for a week.
[11:31] <BenC> the feisty+1 kernel build system will be built from scratch and we plan to implement some hooks for different things
[11:32] <jbailey> Ooo.  Are we doing the no-more-make-kpkg dance?
[11:32] <BenC> yes, amen
[11:32] <jbailey> 'cause making those hppa patches was really miserable. =)
[11:33] <BenC> I have an hppa here that I need to get back up, so I should be able to keep it building this time
[11:33] <BenC> I stopped messing with it after edgy stopped booting for me :)
=== anti_pop [n=anti_pop@p54b0991e.dip0.t-ipconnect.de]  has left #ubuntu-kernel ["Kopete] 
[11:33] <jbailey> Nice.  Hppa should generally work well for feisty+1 I think.
=== kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu]  has left #ubuntu-kernel [] 
=== _fs is now known as fs
=== infinity [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@32-56.dsl.iskon.hr]  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
=== infinity2 [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel