[02:27] <holycow> hello
[02:27] <holycow> would anyone be able to comment on whether or not backporting nforce drivers to dapper would make sense
[02:28] <holycow> the 405 nforce chipset doesn't seem to be supported until the 2.6.18 kernel (still testing via feisty)
[02:28] <holycow> and it would be nice to have that chipset supported under 2.6.15 if possible
[02:28] <holycow> any comments?
[02:28] <holycow> i would be willing to pay for the work
[02:31] <BenC> holycow: How much? :)
[02:31] <holycow> lol hi BenC 
[02:31] <kylem> did you go to space too?
[02:31] <kylem> :P
[02:32] <BenC> holycow: Actually it does make sense, it's just a matter of time and testing
[02:32] <holycow> well i don't know, i guess the question would be if its a reasonable idea and then if someone could kinda go okay it will take x many hours or so we can see if i can afford it
[02:32] <BenC> if it's an easy backport, we can get it into dapper-proposed, and after some testing, move it into dapper proper
[02:32] <holycow> okay reasonable idea taken care of i guess
[02:32] <holycow> i would be willing to test of course
[02:32] <holycow> i have 5 boxen here with that damned chipset ... i didn't do enough research before buying
[02:33] <kylem> holycow, which parts of the chipset? you want forcedeth, intel8x0?
[02:33] <kylem> i can't think of anything else that would be needed...
[02:33] <BenC> yeah, I was going to ask that
[02:33] <kylem> updating forcedeth is a reasonable request.
[02:33] <holycow> kylem, the problem is nothing actually works on it ... not sound, not network card
[02:33] <BenC> kylem: Want to look into the doing the dapper/edgy backport of that?
[02:33] <holycow> nv drivers either but i can get away with vesa
[02:33] <kylem> BenC, yeah, sure.
[02:34] <kylem> i was doing tg3 for edgy-proposed (and then to dapper-proposed) for enablement.
[02:34] <kylem> (and i've already done sky2, so forcedeth should be able to use the same compatibility wrappers i wrote for those two)
[02:34] <holycow> well if you could tell me how many hours of work it is we can see if i can afford it i guess
[02:34] <BenC> holycow: Best bet is to file a bug, target linux-source-2.6.15(dapper-updates) and linux-source-2.6.17(edgy-updates), and provide lspci -vv, lspci -vvn output for the board
[02:34] <holycow> k
[02:35] <BenC> holycow: We can't accept payment for doing work that we are already getting paid to do :)
[02:35] <holycow> oh
[02:35] <holycow> >_>
[02:35] <holycow> thats not a bad proposition :)
[02:35] <holycow> lol
[02:35] <kylem> beer is good if you're ever in the same city though. :)
[02:35] <BenC> you can make a donation to your favorite charity in Kyle's name though
[02:35] <BenC> I think he likes the Good Bear Foundation
[02:35] <holycow> only thing is i kinda need it soonish so was hoping to find out like what the work is like and if anyone can help out i can reciprocate of course
[02:35] <kylem> www.childsplay.org :)
[02:36] <holycow> i can donate indeedy :)
[02:36] <kylem> oh. that's not it.
[02:36] <holycow> i love charities
[02:36] <kylem> www.childsplaycharity.org
[02:36] <kylem> :)
[02:36] <holycow> i work for a company that runs social service programs for the govt here ... i get what that whole thing is about
[02:36] <holycow> i know others are buying this damned board so a lot of good will be solved for them
[02:37] <holycow> lots and lots of posts on the boards about this chipset too
[02:37] <holycow> http://www.asrock.com/product/AM2NF6G-VSTA.htm
[02:37] <holycow> that would be the board
[02:37] <BenC> holycow: Cool, then it is in our best interest to help support it
[02:37] <holycow> NVIDIA NF6100-405 Chipset
[02:37] <kylem> wow. they're on nforce6 already? :)
[02:38] <holycow> BenC, ultimately yeah, i wouldn't expect anyone to really jump on this tho, hence my willingness to help out as well
[02:38] <holycow> kylem, asrock boards arent bad, great for the super cheapies out there
[02:38] <holycow> but i'm thinking of switching to the intel chipset
[02:38] <kylem> oh. the audio should be supported in dapper-updates when it gets uploaded.
[02:38] <BenC> holycow: One thing we support for sure, is Intel chipsets
[02:38] <kylem> daniel chen already supplied backproted patches for that.
[02:39] <holycow> BenC, so you guys would say go with intel chipsets? least headaches?
[02:39] <holycow> is intel good to you guys? supportive or jerks?
[02:39] <holycow> kylem, so i guess you are in the drivers seat here, i'm at your mercy :)
[02:39] <holycow> lol
[02:40] <holycow> getting sound and network card support is really all we need at the moment.  what sort of timeframes/time commitments might this look like?
[02:40] <holycow> i'm not thinking you can have the answer right now :)
[02:40] <kylem> soonish. :)
[02:41] <holycow> okay, how do i keep in touch?
[02:42] <kylem> best way is to do what benc asked, file a bug, target linux-source-2.6.15 and -2.6.17, and provide the lspci -vv and lspci -vvn (in seperate plain-text attachments preferably)
[02:42] <BenC> holycow: This channel is where we dwell
[02:42] <holycow> and let me know what you think is a fair donation to the charity, it should reflect something in the way of fairness for the work
[02:42] <holycow> kylem, oh okay
[02:42] <holycow> in other words not in the  next few days of course but probably couple of weeks is typical way of dealing with this?
[02:43] <kylem> well, for an official fix it might be a while, but i can give you a test kernel in a day or so.
[02:43] <BenC> holycow: If you really want to do that (and it's not required) then wait till the work is done, and base the donation on work performed
[02:43] <holycow> that would be fine too, i will install separate supported network cards in the mean time.
[02:44] <holycow> kylem, test kernel would be fine :)
[02:44] <holycow> kylem, i didn't realize you had to make a new kernel, isn't everything modular?  no matter just curious
[02:44] <holycow> BenC, cool i'll be here
[02:45] <holycow> submitting bug now
[02:54] <holycow> haveto make sure i have current dapper updates to give the correct lspci info
[03:23] <BenC> holycow: lspci shouldn't change with whatever system you are running
[03:23] <holycow> okay. right makes sense
[03:26] <kylem> BenC, well, pci.ids would for decoding it.
[03:27] <BenC> eh, we go by the -n output for driver matching anyway :)
[03:27] <kylem> right.
[03:29] <holycow> okay logged in ... forgot my launchpad pass for a bit
[03:29] <holycow> :)
[03:29] <holycow> am i posting a bug for a specific package?
[03:29] <holycow> oh nm
[03:30] <holycow> linux-source-2.6.15 and -2.6.17,
[03:30] <holycow> got it
[03:37] <holycow> #74745
[03:39] <holycow> #7476
[03:39] <holycow> oops
[03:39] <holycow> #74746
[03:41] <holycow> allrighty, i hope that is helpfull
[03:41] <holycow> i'm greatfull you guys are willing to look into this
[03:41] <holycow> kylem, thanks again
[03:44] <BenC> holycow: You only need one bug report
[03:45] <holycow> :/ sorry
[03:45] <holycow> lets see if i can delete/close one
[03:45] <kylem> we can merge them, it's fine.
[03:45] <holycow> coolness
[03:46] <holycow> thanks guys, greatly appreciate it
[03:46] <holycow> i'm gonna get some sleep, if you need me feel free to msg me to test or whatever
[05:10] <kylem> git is so much more pleasant when you give it its own u320 15krpm spindle to play on.
[05:11] <infinity> And sex is more pleasant when you're not covered in paper cuts and dipped in lemon juice.
[05:11] <infinity> Tell us something we don't know. :)
[05:12] <kylem> unless you're into that sort of thing.
[05:12] <infinity> If you are, you've crossed the line from "fetish" to "need your head checked".
[05:14] <BenC> kylem: I've found that a raid5 with 4 10k drives works well too
[05:15] <BenC> sucks when min hw req for a command line program exceeds that of vista :)
[05:15] <infinity> Stop it.  You guys are upsetting my poor little laptop drive.
[05:15] <kylem> 714M    ../nfs-shite.diff
[05:15] <infinity> It has feelings, you know.
[05:15] <kylem> ok. git whatchanged -p ${sha} >../foo.diff didn't do what i hoped ;-)
[05:15] <BenC> infinity: atleast it can say it doesn't need a small nuclear plant to power itself
[05:15] <BenC> kylem: git-diff-tree -p <sha>
[05:16] <kylem> BenC, diff sha^..sha works too.
[05:17] <BenC> I'm about to shoot 2.6.20
[05:17] <BenC> in 2.6.17+ there's a pci quirk that reserves 0x1f0 ioport for libata
[05:18] <BenC> and when ata_piix loads, it assumes this pre-reserved space, and pci_request_regions() plays nicely
[05:19] <BenC> in 2.6.20 however, pci_request_regions() is now complaining that it's EBUSY
[05:19] <BenC> even though the code from pci_request_regions() on down to __request_resource() hasn't changed
[05:19] <BenC> and ata_init_one() hasn't changed either
[05:20] <BenC> I'm going to need to do full bisect to figure this shit out
[05:23] <kylem> ick.
[05:35] <lifeless> meep
[06:32] <Catshrimp> I realize this is a developement area (not support), but I was hoping someone could point me to a better place to ask this question.  I'm thinking maybe it's because the vga or vesa modules might not have been compiled into the kernel, but upon setting the vga= flag to my boot options, the screen remains blank throughout most of the boot process and I was wondering why.  No one in #ubuntu seems to know.
[06:33] <infinity> Catshrimp: Which release?
[06:34] <infinity> Catshrimp: And do you have any virtual consoles once the machine is done booting? (Ctrl-Alt-F1)
[06:34] <infinity> Catshrimp: For the record, #ubuntu is the right place to ask this sort of thing, but whatever.  I'm feeling generous today.
[06:35] <Catshrimp> infinity: Thanks.  The 6.06 release.  And It does show that I have multiple virtual consoles (I believe up to 6)
[06:35] <Catshrimp> I only see the end of the boot process (starting at networking)
[06:40] <infinity> Catshrimp: Okay, that has nothing to do with the kernel or the modules not being present/loaded, then, since clearly they work to drive the console.
[06:40] <infinity> Catshrimp: Anything beyond that (like why you feel you're not seeing as much as you should) can head to #ubuntu to be argued. :)
[06:42] <Catshrimp> infinity: no problem. I'll take it back to #ubuntu.  Though I just want you to know that I wasn't debating the modules weren't there.  I was wondering if maybe them being installed as loadable modules rather than being compiled into the kernel would cause them to be loaded late, and thus provide no output until loaded.
[06:42] <infinity> Catshrimp: They certainly won't provide output until loaded, this is true.
[06:43] <infinity> Catshrimp: Oh, wait.  You're not using usplash (or any splash).
[06:43] <infinity> Catshrimp: That's a dapper bug.
[06:43] <infinity> Catshrimp: vga= is meant to load vesafb in the initramfs, but in dapper, it only does so if you also have "splash" on the command line.
[06:43] <infinity> Catshrimp: There.  Mystery solved.
[06:44] <infinity> Catshrimp: I've never bothered to propose a fix to dapper-updates, since the bug is purely cosmetic, and not the sort of thing most people would ever care about (most people who use "vga=" tend to also be the sorts of users who would have usplash installed... places without usplash, like servers, tend to not use framebuffers at all, to avoid possible instability issues)
[06:45] <Catshrimp> infinity: Not quite.  Splash present.  Tell you what, I'll check out .config and then compile a custom kernel.  Then if it's fixed, I'll let you know so that you guys can take whatever course of action you deem desirable.
[06:46] <infinity> Catshrimp: Err, but if the splash is present, I'm heartily confused about the issue, since it sounded like you were referring to textual feedback.
[06:46] <infinity> (And there's no way usplash would even run without some sort of framebuffer being enabled)
[06:46] <Catshrimp> infinity: yep, textual.  it'll be a server, just want to be able to see what I'm doing without HUGE font :).
[06:47] <Catshrimp> The only thing I edited in the original menu.lst was to add vga=792 to the kernel line.
[06:47] <Catshrimp> infinity: let me do what I said and see if the problem is corrected.  I'll get back to you guys :)
[06:47] <infinity> Catshrimp: This still sounds like the bug I was referring to.
[06:48] <infinity> Catshrimp: Recompiling the kernel is serious overkill.
[06:49] <infinity> Oh, wait.  I misremembered the bug, though.
[06:49] <infinity> Catshrimp: Are you using a custom kernel, or one of ours, currently?
[06:50] <Catshrimp> The VESA and VGA modules are both compiled as loadable as I thought.  Now, what is the name of the splash that you are talking of?  I don't get any feedback when I query SPLASH or USPLASH in the config
[06:50] <Catshrimp> infinity: no, this is a basic install, nothing extra yet
[06:50] <infinity> Catshrimp: Kay, if it's one of our kernels, then it's not the bug I was thinking of.
[06:51] <infinity> Catshrimp: Anyhow, feel free to hash it out with others on #ubuntu, and if you find a real bug, file it.
[06:51] <Catshrimp> infinity: no problem.  i'll hopefully be able to contribute more to the project than minor bugs here in a couple months :)
[09:02] <BenC> kylem: Ping, #ubuntu-meeting
[11:05] <Keybuk> oh, cool, .20 does away with struct class_device
[11:45] <thom> Keybuk: will this crack udev stuff mean that udev handles setting sysctls also?
[11:46] <Keybuk> thom: crack udev stuff? :p
[11:47] <thom> the devices/drivers stuff
[11:48] <Keybuk> it's been the plan for a while to move sysctl setting to a udev rule
[11:48] <Keybuk> but needs the fix to the uevent ordering as well
[11:49] <thom> right
[11:50] <thom> cool
[12:56] <gebruiker> what modules are still missing?
[02:04] <gnomefreak> is there any reason why there is no safe mode kernels listed anymore? and would pcmcia be kernel issue or upstart or somethng else?
[03:04] <zul> morning
[03:16] <kylem> it is indeed morning.
[03:17] <kylem> for the second time today.
[03:18] <zul> heh oh yeah you had the meeting this morning how was it?
[03:18] <gebruiker> i want the 2.6.19 latency kernel for edgy
[03:18] <gebruiker> how can I build it on my system?
[03:18] <gebruiker> I assume just modifying stuff in control? (i.e the libc6..)
[03:18] <gebruiker> what further?
[03:19] <gebruiker> s/latency/lowlatency
[03:24] <zul> kylem: flu shots are fun..
[03:26] <kylem> tired.
[03:27] <zul> go have a knap then no one will notice ;)
[03:40] <BenC> kylem: I got 3 hours of sleep, how about you?
[03:40] <zul> hey ben
[03:41] <kylem> heh. pretty much the same.
[03:46] <BenC> hey zul
[03:46] <BenC> kylem: for future reference, it's ok if you sleep in the morning following a meeting like that :)
[03:48] <BenC> 4 revs left on the ata_piix debacle
[03:50] <dade`> haha
[04:04] <kylem> :)
[04:07] <dade`> BenC: is the ata_piix stuff about sleep support ?
[04:08] <BenC> no, it's about not working on my box in 2.6.20pre :)
[04:09] <dade`> /o\
[04:19] <zul> still funny: http://geekz.co.uk/blog/2006/08/26/gpl-nuances
[04:30] <Keybuk> BenC: heh, oh, you're a *nice* manager then? :p
[04:31] <Keybuk> I had the 8am meeting, and have a 10pm phone call
[04:31] <Keybuk> *stretch that body clock*
[04:31] <BenC> lol
[04:32] <BenC> Keybuk: btw, your email on the plan was dead on
[04:32] <Keybuk> good-o
[04:32] <BenC> I finally got ata_piix working, so after I make my P4 stop softlocking, I'll start the kernel implementation
[04:33] <Keybuk> sweet
[04:33] <Keybuk> I'm happy to do lots of testing of your implementation
[04:33] <Keybuk> making sure all the uevents are nice
[04:33] <Keybuk> I assume you'll be basing it on .20 ?
[04:35] <kylem> BenC, which commit ended up breaking it?
[04:36] <BenC> kylem: Unfortunately I wasted my time finding a bug that was already known
[04:36] <BenC> it was an Alan Cox patch to "cleanup legacy PCI quirks"
[04:37] <zul> hah
[04:37] <zul> i say cut AC out
[04:37] <BenC> the fix was just posted yesterday, so I just missed it
[04:38] <BenC> zul: Yeah, who needs those long-haired hippies
[04:38] <zul> damn straight...oh wait...
[04:38] <zul> you are a long haired hippie
[04:38] <kylem> BenC, ah, ouch.
[04:39] <zul> like those hairy beard hippies?
[04:43] <gebruiker> hi guys
[04:43] <gebruiker> how do I just build kernel-headers for lowlatency?
[04:46] <pmjdebruijn> heh?
[04:46] <pmjdebruijn> dat heeft geen zin zeg maar
[04:46] <pmjdebruijn> hoezo?
[04:47] <pmjdebruijn> oh sorry
[04:47] <pmjdebruijn> gebruiker, that has no use? why would you want to do that?
[04:48] <pmjdebruijn> gebruiker, ?
[04:48] <pmjdebruijn> gebruiker, https://wiki.kubuntu.org/KernelCustomBuild
[04:48] <gebruiker> i installed 2.6.19 fine 
[04:48] <pmjdebruijn> huh?
[04:48] <gebruiker> now I just want the kernel headers
[04:49] <pmjdebruijn> how did you install it?
[04:49] <pmjdebruijn> did you package 2.6.19?
[04:49] <pmjdebruijn> anyway, you should
[04:49] <gebruiker> added feisty to sources.list apt-get isntall lowlatency...
[04:49] <gebruiker> it just isntalled the kernel en restricted modules
[04:49] <gebruiker> it boots and works fine
[04:49] <pmjdebruijn> oh
[04:49] <pmjdebruijn> feisty
[04:49] <gebruiker> now I need just the headers so I can build some wifi modules for my card
[04:50] <pmjdebruijn> gebruiker, you need to build your own debs
[04:50] <zul> BenC: you have a wiki page now apparently
[04:50] <gebruiker> i don't want to upgrade my libc6
[04:50] <pmjdebruijn> or just feisty's own debs
[04:50] <pmjdebruijn> gebruiker, you're either running edgy or feisty
[04:50] <gebruiker> i still want to run edgy but just not the 2.6.17
[04:50] <pmjdebruijn> gebruiker, nothing in between, that'll give you a boatload of problems
[04:50] <gebruiker> in debian I always had the possiblity to apt-pin
[04:50] <BenC> zul: I thought I always had one...with a few lines about the DPL
[04:50] <pmjdebruijn> gebruiker, that's not really on option
[04:50] <gebruiker> pmjdebruijn, can i just build headers now?
[04:50] <zul> BenC: https://wiki.ubuntu.com/BenCollins
[04:51] <gebruiker> i have inovked apt-get source headers 
[04:51] <pmjdebruijn> gebruiker, not as far as I know... but I'm not an expert
[04:51] <pmjdebruijn> gebruiker, you're basically breaking your system now, though...
[04:51] <zul> whoever okaratas is
[04:51] <BenC> zul: Just my luck, bad english wiki entry :)
[04:51] <gebruiker> well actually linux-headers doesn't contain any binaries right?
[04:51] <pmjdebruijn> right
[04:52] <gebruiker> and 2.6.19 runs fine all programs work fine etc.. etc..
[04:52] <pmjdebruijn> gebruiker, if you package your custom kernel, the appropriate headers will be generated automatically
[04:52] <pmjdebruijn> gebruiker, sigh... but installing stuff breaks!
[04:52] <gebruiker> yes I know i did that with 2.6.18
[04:52] <zul> BenC: heh its a little shrine :)
[04:52] <gebruiker> but 2.6.18 with usb devices made my kernel panic
[04:52] <kylem> BenC, apparently you're the developer of ubuntu. enjoy.
[04:52] <gebruiker> and i choose ubuntu for a reason
[04:52] <kylem> :)
[04:52] <gebruiker> so i don't have to waste so much time compiling stuff
[04:52] <pmjdebruijn> gebruiker, file bugs
[04:53] <pmjdebruijn> gebruiker, anyway, you can make your own debs of 2.6.19 also
[04:53] <gebruiker> so I can't just make-kpkg kernel-headers?
[04:53] <pmjdebruijn> installing a feisty kernel on edgy is a bad idea
[04:53] <pmjdebruijn> gebruiker, no
[04:53] <gebruiker> or can I just invoke dpkg-rebuildpackage -fakeroot -us -uc ?
[04:53] <pmjdebruijn> gebruiker, you need to build your kernel and headers, to do it properly
[04:53] <gebruiker> so it would build against my edgy libc?
[04:53] <BenC> kylem: I so rock
[04:53] <kylem> hehe.
[04:53] <pmjdebruijn> gebruiker, what does your libc have to do with it?
[04:54] <kylem> and/or roll?
[04:54] <gebruiker> with headers? nothing
[04:54] <pmjdebruijn> gebruiker, anyway, remove the 2.6.19 and your feisty sources/packages@
[04:54] <pmjdebruijn> then roll your own 2.6.19+headers for edgy 
[04:54] <gebruiker> pmjdebruijn, what about the patches that are applied for 2.6.19?
[04:55] <pmjdebruijn> gebruiker, if you read the wiki, you can apply them too
[04:57] <BenC> linux-source-2.6.20-2.6.20$ rgrep INIT_WORK ubuntu/ | wc -l
[04:57] <BenC> 72
[05:02] <kylem> most of them shouldn't be too hard to fix.
[05:03] <kylem> i'm still dubious whether that patchset will remain.
[05:04] <kylem> it's broken by design on a bunch of platforms... (it uses cmpxchg)
[06:01] <kylem> BenC, i'm willing to bet that a whole whack of those are in ipw*.c
[06:01] <holycow> hello
[06:25] <kylem> paravirt is in.
[06:28] <zul> sweet!!
[06:30] <zul> buh bye hair pulling
[06:37] <kylem> damn, this is one big ass pull. it's been 4 minutes and i'm still generating a pack file.
[06:39] <zul> are we going to get ext4 for feisty? ;)
[06:41] <kylem> die.
[06:44] <zul> hehe
[06:45] <kylem> * refs/heads/linus: fast forward to branch 'master' of hera.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
[06:45] <kylem> it works so much better when you cut the mirrors out of the equation.
[06:46] <kylem> where by "better" i mean "at all"
[06:50] <dade`> ext4 is already in .19
[07:22] <holycow> malone is pretty darned cool
[07:33] <joefso> does the kernel-source from feitsy already contain the patches?
[07:35] <joefso> how can I view the changelog of the kernel that is in git a.t.m?
[07:36] <dade`> look in the debian/ dir
[07:37] <dade`> and yes, there are patches too
[07:37] <dade`> if you pulled the git source
[07:37] <joefso> does kernel-source contain them? Are they already applied?
[07:37] <zul> no
[07:38] <joefso> git has?
[07:38] <joefso> so I don't see anywhere on the wikipedia how to get the git linux from ubuntu tree
[07:38] <zul> no it doesnt have the new ext4 patches
[07:38] <dade`> https://wiki.ubuntu.com/KernelGitGuide
[07:39] <dade`> https://wiki.ubuntu.com/KernelCustomBuild read this too
[07:40] <joefso> what is so special about the lowlatency kernel? I.e what patches are applied?
[07:40] <dade`> zul i have a .19 vanilla with ext4, why ?
[07:40] <dade`> joefso: i only know that uses HZ=1000 and real preemption
[07:41] <zul> dade`: im talking about the patches from today for ext4
[07:41] <joefso> real preemption? -rt patch?
[07:41] <dade`> no, RT are real time patches
[07:41] <joefso> you consider -rt ready for production?
[07:42] <joefso> does nobody consider real time patches ready for production?
[07:42] <dade`> boh
[07:43] <joefso> ?
[07:43] <dade`> don't know, I'll try those 'cause I'm a musician. But now I don't know
[07:43] <joefso> what's your opinon on -ck patchset?
[07:44] <dade`> what are you a bot ?
[07:44] <joefso> could it made into ubuntu repository?
[07:44] <bronson> joefso: most people wouldn't even notice if RT is enabled on their system.  Unless it crashes.
[07:45] <joefso1> i mean
[07:45] <joefso1> it would be nice if it would
[07:46] <joefso1> unless you would say there is no bennifit for community
[07:53] <bronson> I've just merged linux-vserver into BenC's Edgy git tree.  It looks great except my kernel is named linux-image-2.6.17-10-ref-generic_2.6.17.1-10.34_i386.deb
[07:53] <bronson> How can I change that -ref- to -vserver-2.2.0- ?
[07:53] <bronson> (kernel *packages* are named...)
[07:56] <bronson> I followed the instructions in https://wiki.ubuntu.com/KernelCustomBuild of course.
[07:57] <kylem> bronson, which set of insns?
[07:57] <kylem> the "building the kernel"?
[07:58] <bronson> kylem: yes, AUTOBUILD=1 fakeroot debian/rules binary-debs
[08:20] <zul> BenC: ping http://lists.osdl.org/pipermail/virtualization/2006-December/001828.html
[08:42] <bronson> No word on how to change "-ref-" in custom-compiled kernel packages?
[09:00] <bronson> When I build the kernel, I don't get a .changes file.
[09:00] <bronson> That makes it harder to use dput.  Am I missing something obvious here...?
[09:48] <BenC> bronson: AUTOBUILD=1 dpkg-buildpackage ...
[09:49] <zul> BenC: when you get a chance can you pull from linus
[09:50] <BenC> zul: So hopefully the only thing you'll be building is a dom0 xen kernel?
[09:50] <zul> yep
[09:51] <zul> probably going to be linux-image-2.6.20-xen or soemthing like that
[09:51] <kylem> BenC, i started fixing up the INIT_WORK stuff
[09:52] <zul> the vmware stuff can probably go into -generic
[09:52] <BenC> kylem: Ok, I'm taking care of ipw3945 since it's the biggest (ab)user
[09:52] <kylem> er. he.
[09:52] <kylem> that's what i was doing, ok. will hit something else.
[09:52] <BenC> no no, keep doing 3945 :)
[09:52] <BenC> have you started?
[09:52] <kylem> (i was looking at ipw3945 anyways, because i want to make it print something more useful when ipw3945d isn't running)
[09:52] <kylem> yeah
[09:53] <BenC> I've done everything except convert the = data to container_of
[09:53] <kylem> oh. might as well continue then.
[09:53] <zul> for ipw3945 can you check to see if the firmware is loaded and if not tell the user to install linux-restricted?
[09:54] <BenC> zul: The firmwar is in the main kernel
[09:54] <kylem> right.
[09:54] <BenC> it's ipw3945d that needs to be checked
[09:54] <kylem> it's a pity we can't get it built against uclibc or something.
[09:54] <kylem> so we could put it in initramfs and just run it from a thread
[09:55] <BenC> kylem: Thing is the module loads before ipw3945d...are you adding a timer to check if it gets started?
[09:56] <kylem> BenC, i'm not sure yet, the thing doesn't register_netdev until ipw3945d is running (because they, for some reason, don't want the WEXT ioctls to fail)
[09:56] <BenC> kylem: I've heard Intel plans on releasing a new driver where all of ipw3945d is in firmware
[09:56] <kylem> yeah, keithp has told me similar.
[09:56] <BenC> the time frame is here things start to get sketchy :)
[09:56] <BenC> s/here/where/
[09:56] <kylem> indeed.
[09:57] <kylem> lol.
[09:57] <kylem> nice nap.
[10:00] <zul_> damn it kicked the powerswitch
[10:01] <zul> i was just thinking of way to cut down on the bugs in launchpad
[10:01] <kylem> oh jesus.
[10:01] <joefso> i got the kernel from git, and I have read both wiki pages(how to get from git, how to build customize kernel) however, where does it say, how to apply all i386 patches for ubuntu on the git tree? Like speakup etc.. etc..
[10:02] <mjg59> joefso: They're applied already
[10:02] <mjg59> If you've got the ubuntu kernel
[10:03] <joefso> I got ubuntu-2.6.git ubuntu-2.6
[10:03] <mjg59> Right
[10:03] <mjg59> The patches aren't available separately
[10:03] <mjg59> They're already integrated into the tree
[10:05] <joefso> So all patches are already applied?
[10:05] <joefso> :)
[10:05] <joefso> No need, if they are applied them I'm fine with it
[10:05] <joefso> great :)
[10:17] <zul> later
[10:58] <bronson> BenC: thanks, I'll give it a shot.
[10:59] <kylem> BenC, oh god, some of these drivers make me cry.
[11:00] <BenC> kylem: They are horrible ugly
[11:01] <kylem> should measure vendor submissions in approximate viro-curses.
[11:18] <BenC> kylem: Have you started on rt2x00?
[11:18] <BenC> if not, I'll move on to that
[11:19] <kylem> no
[11:19] <kylem> i've got everything but that and ipw3945 now
[11:19] <kylem> going through what i've changed and making sure i've caught all the prototypes. :/
[11:21] <gnomefreak> is ther ea reason we dropped the safe mode kernel in feisty?
[11:21] <gnomefreak> s/ther ea/there a
[11:37] <BenC>         INIT_WORK(&master->toggle_work, &rfkill_toggle_radio, NULL);
[11:37] <BenC>         INIT_WORK(&master->poll_work, &rfkill_list_poll, NULL);
[11:39] <kylem> there's some doozies in rt2x00.
[11:41] <kylem> http://people.ubuntu.com/~kyle/workqueue-ubuntu.diff
[11:45] <BenC> kylem: Thanks
[11:46] <kylem> i didn't build test though, you get to keep both pieces of anything breaks. ;-)
[11:46] <BenC> hehe
[11:47] <BenC> son of a bitch
[11:48] <BenC> yeah, I see what you mean about rt2x00
[11:49] <bronson> I just got a warning that my git tree is in a directory of the wrong name.  Scrolled by before I could copy it.
[11:49] <bronson> Is this important?
[11:50] <bronson> Should I keep BenC's git tree in "linux-source-2.6.17-XX" instead of my current "ubuntu-2.6.17"?
[11:50] <BenC> it's just a warning, ignor eit
[11:52] <bronson> cool, thanks.