[12:22] <mjg59> BenC: bcm430x people just announced working transmit/receive
[12:40] <mjg59> BenC: With gawk, I get "Error in source file"
[01:19] <BenC> mjg59: you have to delete the bad file
[01:19] <BenC> then one that was attempted by mawk
[01:26] <mjg59> BenC: Ah
[01:26] <mjg59> BenC: Is there any way of enforcing this in the build?
[01:27] <BenC> would be better if we can fix up the awk script to work more compatibly
[01:27] <mjg59> Yeah
[01:28] <mjg59> I've managed to get the bcm43xx driver to associate, but not yet to bring up an interface
[01:35] <BenC> will we be able to put some bcm43xx firmware in l-r-m?
[01:43] <mjg59> Nf.
[01:43] <mjg59> That's awkward.
[01:43] <mjg59> Currently, I'd say "no"
[02:06] <BenC> any ideas on the ability to distribute bcm4xxx firmware at all? :)
[02:07] <BenC> I know we have some bcm firmware already in our kernel tree
[02:21] <mjg59> The bcm ethernet stuff is fine - they've given us permission
[03:08] <infinity> We can put firmware in LRM if we have the driver in the kernel.
[03:08] <infinity> (if we can distribute the firmmware, that is)
[03:09] <infinity> We do that for acx100 firmware.
[03:09] <mjg59> The firmware is ripped out of the Windows driver right now
[03:09] <BenC> yeah, there's a tool to extract it
[03:09] <infinity> Same story with the acx100 firmware.
[03:09] <BenC> infinity: why do we do that for acx100 and no others?
[03:09] <infinity> The tool actually goes and downloads a bunch of random drivers and extracts the firmware.
[03:10] <BenC> we will need that same functionality for bcm43xx
[03:10] <mjg59> The Broadcom one extracts stuff from the Windows or MacOS drivers
[03:10] <infinity> BenC : Perhaps because of the extreme sketchiness of how we obtain the firmware? :)
[03:10] <mjg59> But we still need permission to distribute it
[03:10] <infinity> (And the fact that it's obviously not Free)
[03:10] <BenC> yeah, wonder if the bcm43xx folks have visited this issue yet
[03:11] <infinity> Some firmware is kindly licesnsed in a way that pretends ot be Free, and we look the other way, I think.
[03:11] <BenC> yeah, like the ones that are in "source code, binhex style"
[03:12] <BenC> "This binhex-to-C-array dump is GPL'd" :)
[03:12] <mjg59> I'd be surprised if Broadcom would let us ship the firmware for a device that we've reverse engineered a driver for
[03:12] <BenC> it's not really reverse engineered, is it?
[03:12] <BenC> or is the spec reverse engineered?
[03:12] <mjg59> The driver? Well, it's based on reverse engineered specs
[03:12] <infinity> The latter, i think.
[03:12] <mjg59> So it's probably legal, but I can't see them being keen
[03:13] <BenC> broadcom isn't keen on too many things
[03:13] <BenC> I used to have access to their docbase
[03:14] <BenC> wonder if that login still works
[05:56] <infinity> ARGH.
[05:56] <infinity> BenC : Still around?
[05:56] <infinity> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=1e737e269db99fbf01a5436910ae1aef99e9e075;hp=0631074954f75b6351a6c13769e03be5ce87139a;hb=b135c4815051bad6b2472e4ad0152f205918d2c5;f=include/linux/pci_ids.h
[05:57] <infinity> -#define PCI_DEVICE_ID_ATT_L56XMF 0x0440
[05:57] <infinity> Apparently, I need that for ltmodem to build.
[05:57] <mjg59> infinity: You could define it locally
[05:58] <mjg59> infinity: Also, see http://www.livejournal.com/users/mjg59/55488.html
[05:58] <mjg59> That's the sort of fucking shit I'm dealing with
[05:59] <infinity> mjg59 : Oh, I will define it locally, but it still seems a bit wrong that it got removed.
[05:59] <mjg59> infinity: I'm really unconvinced by that title. There's stuff removed there that isn't duplicated by anything else in the file.
[06:00] <mjg59> I wish I knew why people keep removing stuff from the kernel
[06:00] <mjg59> You'd think they could write a useful patch instead
[06:01] <infinity> Yeah, I did a quick grep and came to the same conclusion as you.
[06:01] <infinity> It may as well have read "Remove PCI IDs for devices I don't like" or something.
[06:02] <mjg59> It's probably "Remove PCI IDs that aren't referenced in the kernel"
[06:02] <mjg59> Someone should bitch
[06:02] <mjg59> Preferably not me, this time
[06:03] <mjg59> I did it for the last bit of useful stuff that got ripped out
[06:04] <infinity> Meh.  That seems braindead to me, but what do I know?
[06:05] <infinity> I like the ("Open Source" code) bit in your license.
[06:05] <infinity> Just in case we weren't sure.
[06:06] <mjg59> I hate Linuxant
[06:06] <mjg59> Deep, visceral hate
[06:33] <calc> so what does vbetool 0.5 do for amd64 over i386?
[06:33] <calc> er i meant over 0.4
[06:33] <calc> i brainoed ;)
[06:34] <mjg59> It builds properly
[06:34] <calc> something that would have made 0.4 not work right on amd64 or just build time issues?
[06:34] <mjg59> Basically just build time issues
[06:35] <calc> ah ok
[07:40] <infinity> mjg59 : Any drivers to shove at me for LRM yet?... I'm rolling a new release.
[07:45] <TheMuso> 
[07:45] <TheMuso> 
[07:45] <TheMuso> 
[08:56] <infinity> Can someone buy me an OS that makes sense for Christmas?  kthx.
[08:57] <infinity> I rebooted, initramfs claimed that /dev/sda3 (my root device) didn't exist.  Sure enough, it had been created as /dev/hda[*]  instead.
[08:57] <infinity> Another reboot, and it's back to /dev/sda[*] , and I'm rocking myself to sleep in the foetal position in the corner.
[09:02] <fabbione> infinity: is that machine SATA?
[09:03] <infinity> Yes.
[09:03] <fabbione> it's a load module order problem
[09:03] <infinity> I blame udev.
[09:03] <fabbione> sometime the ide driver (hda*) is loaded before the sata (sda*)
[09:03] <infinity> Note that I didn't touch anything between reboots.
[09:05] <fabbione> yeah
[09:05] <fabbione> it still can happen
[09:06] <fabbione> 2 drivers handling the same device
[09:06] <fabbione> BAD BAD BAD
[09:06] <infinity> Yeah.  Just wonder why I've never seen it until today.
[09:06] <infinity> Moon phase, I guess.
[09:07] <fabbione> possibly
[09:55] <makx> infinity i had that frequently with udev = 0.74
[09:55] <makx> it was solved that time with a nasty timeout.
[09:55] <makx> that was prior udev with /dev/.udev/udevqueue you can test against
[10:04] <infinity> Well, this is with the shiney new udev here.
[10:26] <infinity> Our systems and packages may be cleaner, but they only boot every second try, so don't be TOO envious. :)
[10:29] <makx> infinity you seem to use udevplug, which is not even in our udev package.
[10:29] <makx> we need to use udevsynthesize.
[10:59] <fabbione> BenC: please pull from my archive when you wake up (RedHat cluster kernel modules update)
[11:09] <CataEnry> hi all
[12:52] <chmj> is stuff like fixing FTBFS becouse of missing headers worth pushing to kernel  upstream ?
[12:53] <fabbione> chmj: where do you get that?
[12:56] <chmj> fabbione: linux-2.6/kernel/irq/handle.o 
[12:56] <chmj> include/asm/acpi.h:67: error: boot_cpu_data undeclared (first use in this function)
[12:56] <fabbione> from which tree?
[12:57] <fabbione> and on what arch are you building?
[12:57] <chmj> i386 
[12:57] <fabbione> from which tree?
[12:57] <chmj> upstream tree with some test patches 
[12:57] <fabbione> probably worth a shot, but check if the patch hasn't been submitted already
[12:58] <fabbione> acpi is common enough to trigger an alarm when it doesn't build
[12:58] <chmj> fabbione: hmm, thanks 
[01:54] <BenC> fabbione: ok
[02:04] <fabbione> BenC: thanks dude.. test builded on amd64 and it's fine
[02:13] <fabbione> jbailey, BenC: should we have the meeting now?
[02:13] <fabbione> or do you prefer to wait?
[02:13] <fabbione> both ways work for me
[02:14] <jbailey> fabbione: I'm fine now.  I jjust need to remember what it was about.
[02:14] <fabbione> something about specs?
[02:15] <jbailey> I need logrotate for these things.
[02:18] <jbailey> ah, here we are.
[02:18] <jbailey> KernelServerRoadmap
[02:19] <jbailey> The idea being that the spec currently defines servers are pretty exclusively things that high end admins would need (clusters, fibber channel raid arrays, etc).
[02:20] <jbailey> What came up was that Ben asked if he thougt anyone would notice if USB network cards weren't compiled for that kernel.
[02:20] <jbailey> My comment was that if setup up an office for SME/SoHo, it's very reasonable to do servers with wireless USB.
[02:21] <fabbione> jbailey: it really depends what you consider a "server"
[02:21] <jbailey> So the discussion is really, (I think), how are we defining server
[02:21] <jbailey> Right! =)
[02:21] <fabbione> and at the end the result was: hw drivers all
[02:21] <jbailey> So it needs to be clear, match what actual end user expectations are.
[02:21] <fabbione> we finetune the server for other properties
[02:21] <fabbione> like highmem and premptviness 
[02:21] <jbailey> Well, the definition is less important than what a person will install in their office.
[02:21] <fabbione> and stuff along that line
[02:21] <fabbione> well it is somehow
[02:21] <jbailey> Is it correct for a person in a 5 person office to install the server edition on their fileserver?
[02:22] <jbailey> If it's not, then I think it's misnamed.
[02:22] <fabbione> we might want to support the kernel server only on certified hw
[02:22] <jbailey> And should be "Enterprise computing edition" or something like that, with a note on the side saying what that means.
[02:22] <jbailey> There's no serious chance of that for dapper.
[02:22] <jbailey> Possibly after that, though.
[02:22] <fabbione> i think that what ben and I decided at UBZ was full hw
[02:22] <fabbione> but just tune for server/desktop
[02:22] <fabbione> for example
[02:23] <fabbione> redhat cluster suite doesn't like preempt
[02:23] <fabbione> now..
[02:23] <BenC> ok, here, we can do the meeting now if you like
[02:23] <fabbione> you stick redhat cluster suite module on the server kernel
[02:23] <fabbione> but not on the workstation one
[02:23] <fabbione> given also that desktop prefers preempt generally 
[02:23] <fabbione> BenC: cool
[02:24] <fabbione> it will save me to run this evening
[02:25] <fabbione> i *think* the biggest mistake is that we keep trying to code in a spec the kernel
[02:25] <jbailey> Eh?  If we don't code it into a spec, how are we supposed to do it with enough community feedback?
[02:25] <fabbione> jbailey: keeping an eye on bugzilla? ;)
[02:27] <fabbione> jbailey: seriously i think that the kernel world is too unpreditable to be specced the same way we do for other stuff, imho
[02:27] <fabbione> but does my answer satisfy your curiosity?
[02:28] <fabbione> (in regards of the hw support)
[02:28] <jbailey> It does, but it doesn't answer the real question yet for me - Is the server kernel going to be suitable for a 5 person office running a fileserver?
[02:28] <BenC> fabbione: one thing we weren't sure of, is this going to be server as in "any machine I decide to run as a server" or server a in "expensive NUMA/Summit type systems"?
[02:28] <jbailey> I think it's a yes.
[02:29] <fabbione> BenC: iirc we did agree to fine tune the server flavour to suck in as much server coolness as possible
[02:29] <BenC> but our normal 686 kernel can do that
[02:30] <fabbione> jbailey: it should yes.. 
[02:31] <BenC> and our desktop kernel, currently, isn't full preempt, so it should be suitable for SOHO server situations
[02:31] <fabbione> BenC: i think we should rever that for desktop
[02:31] <BenC> so my opinion was that the "server kernel" would be geared toward the higher end stuff
[02:31] <fabbione> and disable the RH stuff on it
[02:32] <fabbione> BenC: the main problem is that it means shipping even more kernels on -server CD
[02:32] <BenC> and disable NFS server, and other things like that?
[02:32] <fabbione> that's confusing for the user
[02:32] <fabbione> BenC: no, the rh cluster and premept simply conflicts.. it was an example
[02:33] <fabbione> also.. you can't make clustered workstation
[02:33] <BenC> just the line is getting fuzzy
[02:33] <fabbione> it just doesn't work :)
[02:33] <BenC> I'm not really sure what the target of our server kernel is, which is making it hard to decide what should and should not be there
[02:34] <fabbione> hmmmmm
[02:34] <fabbione> i thought we did agree on full hw support
[02:34] <fabbione> and just tune highmem and preempt
[02:34] <fabbione> to start
[02:34] <BenC> but that's the minor issue
[02:34] <BenC> are we not going to do numa/summit/bigsmp right now?
[02:35] <fabbione> do they need to be different flavour?
[02:35] <fabbione> or can they exist in the same kernel?
[02:35] <BenC> there's a generic one that covers all three
[02:35] <BenC> but I don't know if it will run on a normal 686, or if you even want to
[02:35] <fabbione> we can test the former
[02:36] <BenC> the generic one is what I have now
[02:36] <BenC> maybe I can do a server and a enterprise kernel?
[02:36] <fabbione> or server-lowend and server-highend
[02:36] <BenC> server being our 686 tuned for server, and enterprise being the one that supports the big systems?
[02:36] <fabbione> i would avoid enterprise word
[02:37] <BenC> ok
[02:37] <fabbione> that would make sense yes
[02:37] <fabbione> if we stick the word enterprise anywhere we will be classified as RH
[02:37] <BenC> will we need udeb's for those?
[02:37] <fabbione> and we do not want that
[02:37] <fabbione> only for the -686
[02:37] <fabbione> so we could:
[02:37] <fabbione> install the -server CD with the 686-server tuned
[02:38] <fabbione> who needs the big mofo can install it from CD
[02:38] <BenC> ok
[02:38] <fabbione> how should we call them?
[02:38] <fabbione> 686-server and highend-server?
[02:39] <fabbione> we will need to keep a very detailed documentation on the differences
[02:39] <fabbione> for sure people are going to ask
[02:39] <infinity> "highend" is one of those things people will install for "highend features", invariably installing the wrong thing.
[02:39] <infinity> Is there any short word one can think of that unambiguously means "really big hardware you don't own, dumbass"
[02:39] <fabbione> and note that we will need the same counterparts for the other arches
[02:40] <fabbione> 686-forbigfathwyoucanteffordunderyourstinckydesk
[02:41] <infinity> (Also, where is the cutoff between server and fatserver?.. With commodoty hardware as it is these days, I assume server will still support a fair number of CPUs (4, 8?) and a mess of RAM (16G, 32G?) out of the box.
[02:41] <infinity> Just not crazy configs like 512 CPUs and NUMA... Right?
[02:41] <fabbione> infinity: i think that's more or less what i had in mine and didn't say
[02:42] <BenC> yeah, that's basically it
[02:43] <BenC> 8-way, 32Gig is the limit for our normal server
[02:43] <mjg59> Hmm. Dyntick seems to be a bit over-enthusiastic
[02:43] <mjg59> As in, I'm only getting ticks if I actually do something that generates interrupts
[02:43] <infinity> BenC : Oh, hate to take your mind off the pressing business of naming your next baby...
[02:44] <fabbione> we could call it 686-bigmofo
[02:44] <mjg59> And it doesn't actually seem to be saving me any power, either
[02:44] <infinity> BenC : What should we do with "linux-tree" and "linux-patch-ubuntu" from linux-meta?
[02:44] <fabbione> i wonder if they will get it?
[02:44] <fabbione> infinity: kill them
[02:44] <fabbione> linux-patch doesn't exist anymore
[02:44] <infinity> BenC : Are you intending to keep the kernel debian-native from here on in, and we should just drop those?
[02:44] <fabbione> and neither -tree- afair
[02:45] <BenC> infinity: I had them deleted, we just need linux-source now
[02:45] <infinity> Well, -tree = source+patch-ubuntu, so if there's no patch, there's no tree.  Right.
[02:45] <infinity> Kay.
[02:46] <BenC> brb, rebooting to -7.9
[03:08] <cliebow_> could someone elaborate on tagging a vmlinux kernel with initramfs?suggestions were adding initrams.gz to the data section?
[03:10] <Yagisan> reading the scrollback, what about servers that need high interactivity eg edubuntu or other ltsp servers ?
[03:10] <Yagisan> do they have to have a "desktop" kernel ?
[03:12] <fabbione> Yagisan: ltsp servers are workstations
[03:12] <fabbione> so they get the desktop kernel
[03:15] <BenC> yay, my cdrom is working!
[03:16] <BenC> jbailey: I have an interesting tidbit for you, my G4 stopped locking up from the screen-saver after I switched LCD panels
[03:17] <jbailey> BenC: It's an Apple Cinema Display.  No chance of me swapping it out. =)
[03:17] <BenC> hehe
[03:17] <mjg59> BenC: Did you have a chance to ask jgarzik about the ata_piix pata support?
[03:18] <BenC> mjg59: he never came back around
[03:18] <mjg59> Ah, ok
[03:18] <Yagisan> fabbione: Ok, but that would still have the driver support of say "server" versions ?
[03:18] <fabbione> Yagisan: please read all the scroll back
[03:18] <fabbione> Yagisan: the hw support will be the same in terms of drivers
[03:18] <fabbione> and no ltsp does NOT need a server kernel
[03:19] <BenC> fabbione: so on i386 (the only server kernel atm) I will disable all the cluster stuff except in the server kernels, correct?
[03:19] <BenC> should I disable gfs aswell?
[03:20] <fabbione> BenC: yes correct.
[03:20] <fabbione> gfs/clustering can go away from the desktop
[03:20] <fabbione> and you could reenable pre-empt
[03:20] <fabbione> but that's up to you
[03:22] <fabbione> gfs depends on CMAN iirc
[03:22] <BenC> ok
[03:22] <fabbione> do it should autodisable
[03:22] <Yagisan> fabbione: ok. I just thought I read that nfs was proposed to be disabled in desktop kernels, and that's needed for ltsp/edubuntu
[03:22] <fabbione> s/^d/s
[03:22] <fabbione> Yagisan: read carefully ;)
[03:23] <fabbione> BenC: when do you plan to upload 7.9 ?
[03:23] <Yagisan> fabbione: I know, I need more coffee (and sleep - my babies won't let me do that).
[03:24] <BenC> hopefully today
[03:24] <fabbione> BenC: perfect
[03:24] <BenC> maybe tomorrow since I want to get the server kernel building aswell
[03:24] <fabbione> i am waiting for the new rh modules to test the new userland
[03:24] <fabbione> too lazy to build it myself on 3 arches
[03:25] <fabbione> did you remember to enable the ABI script?
[03:26] <CataEnry> hi all 
[03:40] <BenC> yeah, abi is working again
[03:40] <fabbione> cool
[04:20] <mjg59> BenC: Hm. The ata_piix driver doesn't provide PCI IDs for a lot of the devices that piix.c will drive
[04:20] <mjg59> I'm playing with it a bit now
[05:16] <lamont__> BenC: either I deleted it, or something else caused your patch email to not reach me... could you send it to lamont.jones@hp.com?
[05:16] <lamont__> (elilo/gnuefi)
[05:17] <BenC> I didn't send it
[05:17] <BenC> it's not booting
[05:17] <BenC> the fix is simple enough, just use the linker scripts from gnu-efi 3.0b
[05:17] <BenC> it's like a two line change
[05:18] <BenC> I even tried building with gcc-3.4, and it still doesn't work (as soon as it tries to run elilo, it drops back to the EFI menu, almost instantly)
[05:23] <jbailey> BenC: Amusingly enough, I switched back to sparc/2.6.12-9 and started a gdb build earlier.  I just checked and it has not crashed yet.
[05:23] <BenC> yeah, that is odd
[05:24] <BenC> I've been doing some fairly frequent builds of the kernel on my e3k (-j20)
[05:24] <BenC> maybe I should try a gdb build :)
[05:28] <jbailey> BenC: It's in the testsuite that it's dying.
[05:28] <jbailey> So the two thoughts I have are memory pressure, or some syscall exercising.
[05:28] <BenC> I have 6 gigs, so memory pressure is difficult for me
[05:28] <BenC> I need to get my U2 out for testing some of this
[05:28] <jbailey> I understand.  I have the same problem with my ppc64 box. =)
[05:29] <BenC> poor us :)
[05:29] <jbailey> Isn't our life hard? =)
[05:52] <lamont__> BenC: so we just need a newer gnu-efi, and then figure out why it doesn't boot, eh?
[05:53] <lamont__> and pulling ram is painful, too.
[05:54] <lamont__> BenC: does it play a pretty tune first, or just exit?
[05:54] <BenC> tune?
[05:55] <BenC> I hadn't noticed any tunes coming from my i2k :)
[05:55] <BenC> I see "Loading Ubuntu", then "Starting Ubuntu", and then back to EFI, the "Starting Ubuntu" goes so fast I somtimes don't even see it
[05:56] <BenC> so it's like exiting pretty damn early
[05:56] <BenC> lamont: is there any debugging I can put in elilo?
[05:57] <BenC> I'm almost thinking it is exiting in crt0 or something
[06:01] <BenC> ah, it has verbose and debug  options
[06:01] <BenC> I'll try enabling that
[07:11] <mdz> BenC: I get a BUG on 2.6.15-5 triggered by the pcmciautils init script
[07:11] <mdz> is pcmciautils not doing the same checks that pcmcia-cs did, to avoid loading the drivers on systems which don't have pcmcia?
[07:11] <BenC> fixed in -6
[07:11] <mdz> (this is on my desktop)
[07:11] <mdz> ok, am doing that upgrade now
[07:11] <BenC> you got a softlock, correct?
[07:11] <mdz> correct
[07:11] <mdz> init_i82365 ... _spin_lock_irqsave
[07:12] <BenC> yeah, fixed
[07:12] <mdz> thanks
[07:12] <BenC> patch from breezy causing that
[07:12] <BenC> just removed it
[07:15] <mdz> BenC: any guesses as to my via/irqpoll problem? (#5234)
[07:15] <mdz> that's the real issue with 2.6.15 on my desktop currently
[07:15] <BenC> same problem from breezy, right?
[07:15] <BenC> I left out your patch to see if you'd complain, so I guess I'll still need it :)
[07:16] <BenC> I'll put it in -7.9
[07:16] <mdz> not exactly; irqpoll no longer works around it now
[07:16] <BenC> maybe irqpoll is broken
[07:17] <BenC> x86 or amd64?
[07:18] <mdz> x86
[07:19] <BenC> I was going to upload -7.9 today, but it got put off because a driver is failing to build
[07:19] <BenC> since I have to put it off anyway, I can get your via patch in and check irqpoll
[07:20] <BenC> when is flight 2 supposed to be done?
[07:20] <CataEnry> hi
[07:44] <jbailey> BenC: I asked Colin for a not-sooner-than this morning and he said Thursday.
[07:44] <BenC> cool, so tomorrow shoudl be ok for a -7.9 upload
[07:44] <BenC> thanks
[07:48] <mdz> BenC: flight 2 is tentatively later this week
[07:48] <mdz> thurs or fri
[08:19] <fabbione> mjg59: are you aware of any problem with the ipw2x00 driver in the latest breezy kernel?
[08:19] <fabbione> (or if you heard something about it)
[08:26] <mjg59> What sort of problem?
[08:27] <fabbione> basically it happens only to cvd
[08:27] <fabbione> when there are 3 or 4 APs around
[08:27] <fabbione> the card becomes unstable to death
[08:27] <fabbione> do you happen to have one of them around to test in a similar situation?
[08:28] <fabbione> the problem happens with breezy kernels
[08:30] <mjg59> I've seen vaguely similar stuff
[08:30] <fabbione> workarounds?
[08:30] <mjg59> Nope
[08:31] <fabbione> ok thanks :/
[08:35] <dilinger> breezy's kernel keeps crashing on my opteron machine :/
[08:37] <mjg59> Fucking ay
[08:37] <jbailey> dilinger: Your opteron and my sparc can go cuddle.
[08:38] <fabbione> dilinger: your opteron is crap.. :)
[08:38] <dilinger> fabbione: my opteron rocks :p
[08:38] <dilinger> fabbione: i'm not even using SMP, since that crashes on bootup
[08:39] <trevilor> hi guys
[08:40] <dilinger> it may very well be the 3ware driver
[08:40] <dilinger> since it's been doing a lot of i/o when it hangs
[08:40] <fabbione> dilinger: what about trying to see if it is something else?
[08:40] <dilinger> fabbione: well, the machine's in boston right now, and i'm not
[08:40] <dilinger> so trying stuff is kind of hard
[08:40] <fabbione> dilinger: sucks to be you
[08:41] <dilinger> :P
[08:41] <dilinger> not really.  it's a 2TB machine :)
[08:41] <dilinger> once it's stable, i will be very very happy
[08:42] <BenC> mjg59: just did a sync for bcm43xx and softmac for -7.9, so let me know if it works stock
[08:42] <dilinger> the sunfire should be going out to davem today
[08:42] <dilinger> assuming that the UPS pickup happens correctly
[08:42] <fabbione> dilinger: cool
[08:43] <mjg59> BenC: I needed to add a PCI ID
[08:43] <fabbione> BenC: dunno if you are reading #u-d but we might not need udeb for -server at all
[08:43] <mjg59> But other than that, it seems good
[08:43] <fabbione> softmac as in the Airport Extreme support?
[08:43] <BenC> fabbione: ok, I have them enabled, so it's easy to turn off (or ignore them)
[08:43] <mjg59> Softmac provides 802.11 management stuff in software
[08:43] <BenC> mjg59: email me the id's
[08:43] <mjg59> Which the Broadcom driver needs
[08:43] <fabbione> ok
[08:44] <fabbione> BenC: ok, if they don't build, just disable them
[08:44] <BenC> bcm43xx as in airport extreme though
[08:44] <fabbione> BenC: i totally forgot to ask to Kamion before saying yes
[08:44] <mjg59> BenC: 4318 with VENDOR_HP, ID_ANY in the subvendor/device fields
[08:44] <BenC> mjg59: ok, they'll be there
[08:45] <mjg59> Rock
[08:53] <dilinger> jbailey: what kind of sparc, btw?
[08:53] <jbailey> dilinger: U5
[08:54] <dilinger> ah
[10:12] <mdz> BenC: kernel-wedge and kernel-package merges seem to still be pending; if there's something blocking them, please note in the status whiteboard, otherwise please get them merged soonest
[11:49] <jbailey> Is it expected that there's no linux-headers-2.6.15-# package yet?