[12:17] <Mez> aq: you tried the daily kernel?
[12:17] <aquarius> In a bang-up-to-date dapper, I don't seem to have the bcm43xx module, but CONFIG_BCM43XX=m in /boot/config-2.6.15-17.386. Have I done something wrong?
[12:17] <aquarius> what's a daily kernel?
[12:18] <Mez> see topic
[12:18] <Mez> ah
[12:18] <Mez> they dont have a recent one
[12:19] <aquarius> I don't understand how /boot/config can say it's a module but the module not be present
[12:19] <Mez> aquarius, what kernel? -386? -686?
[12:19] <aquarius> -386
[12:21] <Mez> BenC is the guy to ask. ... lol
[12:21] <Mez> I'm just checking why I have it
[12:21] <aquarius> BenC: ping?
[12:45] <aquarius> BenC: Kamion says the following is broken in latest dapper kernel:
[12:45] <aquarius> Kamion obj-$(CONFIG_NET_BCM43XX)       += bcm43xx/
[12:45] <aquarius> Kamion from drivers/net/wireless/Makefile
[12:45] <aquarius> Kamion that needs to be CONFIG_BCM43XX now
[01:03] <infinity> BenC: I could test OldWorld booting, but I've always just used BootX from MacOS (ever since quik and I discovered we had irreconcilable differences), so I've never much cared.
[01:03] <BenC> does BootX from MacOS boot the standard vmlinux kernel file?
[01:08] <mjg59> Awh, I miss quik
[01:08] <mjg59> And the fact that my oldworld machine had no graphics driver in the firmware
[01:08] <mjg59> Actually, I don't
[01:12] <heatxsink> hello all, which version of the kernel are those Bluez patches in?
[01:24] <infinity> BenC: Yes, I only build the one kernel, I don't do anything wonky.
[01:24] <infinity> BenC: Though, I've never tested an Ubuntu kernel on the machine.  I should probably try that at least once, to satisfy curiosity and see if it works.
[01:25] <infinity> BenC: (It's just running my own build of vanilla 2.6.15.4 right now)
[01:38] <BenC> infinity: if it boots the prebuilt kernel, then it should be ok
[01:38] <BenC> heatxsink: 17.24
[01:55] <zul> heylo
[01:56] <heatxsink> BenC:  is tha twhat I have now?
[01:57] <heatxsink>  2.6.15-17-686
[01:57] <BenC> I have no idea what you have
[01:57] <BenC> looks like it
[01:57] <heatxsink> WOOT
[01:57] <heatxsink> BenC:  how would I confirm it?
[01:57] <BenC> uname -a
[01:57] <heatxsink> so the 17 = 17.24?
[01:57] <BenC> yeah, 17.24 was the first -17
[01:58] <heatxsink> oops
[01:58] <heatxsink> haha
[03:05] <psusi> man... I still can't quite wrap my head around gitk
[03:39] <BenC> don't think I could use gitk...I just use the git-core tools
[03:39] <BenC> oh, gitk is that graphical thingy that tries to make sense of all the clone/merges for trees and stuff
[03:40] <BenC> yeah, that's a bit too much information :)
[03:54] <psusi> yes
[03:54] <psusi> if I just do a cg-log -c, that's nice for linear development, but whenever there's a merge, the commit just says merge from xxx
[03:54] <psusi> well, WTF got merged in?
[03:54] <psusi> heh
[03:55] <psusi> so I fire up gitk to see what sort of patches were in that branch that was merged
[03:55] <psusi> but all the forks and merges make a rather complex graph that is hard to follow
[03:58] <psusi> I think I'm starting to get it sorted out though
[04:04] <Mez> BenC, the kernel should use bzr ;)
[05:18] <BenC> Mez: when Linus uses it, I will :)
[05:21] <Mez> ;)
[06:00] <psusi> is there some easy way to throw emacs into the correct code style mode for the kernel?
[06:27] <tiefox> why the new version of the kernel, 2.6.15-17 does not have the bcm43xx wireless drivers?
[06:41] <psusi> hrm... cg-diff -c fails because it can't find gawk... bug?
[06:48] <crimsun> sounds like a missing depends on gawk, since we have mawk by default
[06:48] <psusi> yea... I noticed, we have mawk... wonder why cg doesn't just use that?
[06:49] <psusi> especially since cg-log -c can colorize without gawk
[07:20] <mxpxpod> what heppened to the bcm43xx module in the kernel?
[07:21] <mxpxpod> s/heppened/happened/
[07:27] <mjg59> mxpxpod: It fell out by accident
[07:27] <mjg59> Should return soon
[07:27] <mxpxpod> :(
[07:27] <mjg59> The config name changed, but Ben forgot to update the makefiles to match
[07:28] <mxpxpod> so, 18.25 will have it, eh?
[07:28] <mjg59> Should do
[07:28] <mxpxpod> how soon?
[07:28] <mjg59> Not sure
[07:28] <mxpxpod> darn
[07:30] <bigon> Hi, I have bugrepported https://launchpad.net/distros/ubuntu/+bug/23010 for about 5 mouths, is it possible that this problem comes from a broken kernel header under ppc?
[08:05] <psusi> ok, so I have my kernel patch... I committed it to my local git tree, and git-format-patch'ed it... now how do I post it to lkml?  I don't want to just paste it into thunderbird right?
[08:10] <mjg59> Hmm.
[08:10] <mjg59> I'm onto 32 kernel builds now.
[08:11] <cjb> psusi: Thunderbird is the mailer least likely to not screw up your patch, I'm afraid.
[08:12] <cjb> You do want to just send it inline, with a changelog entry and Signed-off-by:, so pasting it would work if your mailer were sane, but it's difficult to get Thunderbird to leave preformatted text alone.
[08:13] <psusi> what if I just attach it?
[08:19] <psusi> is there an easy way to get an old fashioned mail program set up so I can just pipe it there?
[08:28] <cjb> psusi: Patches are preferred inline, not attached.
[08:29] <cjb> You can just use mail(1), if it's installed.  Send a mail to yourself first to check it comes out okay.
[08:29] <psusi> don't have it installed
[08:30] <psusi> but it looks like I got thunderbird to not munge it
[08:33] <psusi> I can't believe email still has these problems
[08:33] <psusi> you are't supposed to send lines longer than 72 chars because the readers don't rewrap, but then sometimes you want to so data doesn't get munged.. 
[08:34] <psusi> I don't see why you don't just let the reader wrap at 72 if it wants to, at the user's option...
[08:37] <cjb> Yes.  Patches should be MIME attachments, really.  There's nothing problematic about it.  But people like to comment on them, and when there are comments we want them to be inline and quoted properly etc.
[08:37] <psusi> mime disposition = inline?
[08:39] <psusi> looks to me like when it's attached, thunderbird marks it as inline, so it shows inline when read, and is quoted properly when I reply
[08:44] <cjb> psusi: Mime disposition is just a hint to the mailer; not all mailers will present an attached patch as inline.
[08:44] <psusi> if it says it should be presented inline, and is text/plain, then wouldn't it be broken not to do so?
[08:45] <psusi> even for plain text readers like mutt
[08:47] <cjb> I think it may be the case that mutt presents it inline, but then doesn't include it in a quoted reply when you press 'r'.  I think the real reason this stuff doesn't change is that Linus uses pine, and pine is more broken than most mailers about it.
[08:47] <psusi> omfg, you're kidding?
[08:47] <psusi> how the hell can anyone use that pile of shit?
[08:47] <psusi> at least, anyone who gets more than 10 message a day?
[08:47] <cjb> I honestly don't know.  :)
[08:48] <cjb> He uses a text editor (microemacs) that's a decade or two old, too.
[08:48] <psusi> seriously.... unless they've rewritten it since I last used it, pine chokes on large mailboxes because it has to read and parse the entire spool when you open it every time
[08:49] <psusi> does it even handle threading?  heh...
[08:49] <cjb> I think it's possible to achieve everything people want with pine.  I just don't think it's *fun*.
[08:51] <psusi> or easy
[08:51] <psusi> or efficient
[08:53] <psusi> pine would shit itself if it tried to open my lkml mailbox... 23,019 messages that take up a bit over 100 MB
[10:15] <dilinger> hm
[10:15] <dilinger> wtf?
[10:16] <dilinger> kernel packaging no longer includes patches?