[02:16] <johanbr> According to the topic, the latest kernel upload seems to have been in progress for about a month now. :)
[02:16] <pwnguin> seems true
[02:17] <pwnguin> at the moment, the package "linux" holds the 2.6.24 kernel
[02:17] <pwnguin> but im missing a few restricted drivers and iwl
[02:17] <johanbr> It does? My mirror doesn't have a 2.6.24 kernel at least.
[02:18] <pwnguin> in hardy?
[02:18] <pwnguin> apt-cache show linux
[02:18] <pwnguin> oh
[02:18] <johanbr> Right. No 2.6.24 kernel.
[02:18] <pwnguin> good point
[02:19] <pwnguin> apt-cache show 2.6.24 does show up though
[02:21] <johanbr> Oh, never mind. I'm stupid. Found it.
[02:21] <pwnguin> but i dont think its finished uploading / building / something
[02:22] <johanbr> No, it's done: https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-1.1
[02:27] <pwnguin> hmm. well i guess once im done updating, i'll go back and see why wireless isnt working
[06:00] <imbrandon> BenC: ping, how much trubble ( or what do you need from me to make is easier/faster ) to get "omfs-source" from the archives into l-u-m
[08:22] <kraut> moin
[08:41] <Kano> hi pkl_ 
[08:42] <Kano> could someone tell me how to check for the kernelversion used in a rules.modules file?
[08:44] <Kano> i have got KVER in there as var...
[10:17] <Kano> ok, found a solution for that, but that only fixes things for 2.6.23 (avm drivers)
[10:41] <gaspa> there's someone with slub/slab experience? i want to understand when to use the first, when the latter...
[10:57] <andres> gaspa: Except for bugs in slab I dont think there are many valid reasons using slab.
[10:58] <andres> Replace first slab with slub.
[10:58] <gaspa> andres: there are no cases in which slab if more efficient?
[11:00] <andres> Maybe there are some, but not out of architectural reasons.
[11:02] <andres> And be aware that there were some bugs making slub way much slower in 24-rc? releases.
[13:44] <pitti> BenC: so, maybe I'm confused
[13:44] <pitti> But https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/57233/comments/12
[13:44] <ubotu> Launchpad bug 57233 in linux-source-2.6.15 "Minor revision 2.6.15-26 doesn't detect attached SCSI disks to LSI 1030ST" [High,In progress] 
[13:44] <pitti> seems to indicate that this bit was a regression:
[13:44] <pitti> linux-source-2.6.15 (2.6.15-51.63) dapper-proposed; urgency=low
[13:44] <pitti>  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
[13:44] <pitti>  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
[13:44] <pitti>     - LP: #57233
[13:44] <pitti> (oops, sorry for the double line)
[13:45] <pitti> BenC: ah, so you do plan to back out that change to get back to the current dapper-security behaviour, and fix the bug in lbm instead?
[13:45] <BenC> pitti: right
[13:45] <pitti> ok, then I just misunderstood you
[13:46] <pitti> BenC: ok, so the backing out of this bit should be easy and do little harm, right?
[13:46] <BenC> pitti: right, now we're on track :)
[13:47] <pitti> let's hope that Vide tests the new lbm then
[13:48] <pitti> BenC: but unless you have some other showstoppers, shall we get this uploaded and new CDs built for testing?
[13:48] <BenC> pitti: I think that's a good idea, ppl can test in the meantime
[13:49] <BenC> pitti: I'll get the uploads done once I've had a cup of coffee
[13:49] <pitti> BenC: enjoy, and thanks
[15:47] <BenC> pitti: lbm-2.6.15 is in dapper-proposed awaiting approval
[15:50] <pitti> BenC: nudged, thanks
[16:17] <BenC> pitti: I'm checking if this megaraid change breaks ABI, after that I'll upload
[16:17] <pitti> BenC: *crossing fingers that it won't* :)
[17:14] <BenC> pitti: good news, no change in ABI
[17:14] <pitti> phew
[17:54] <pitti> BenC: so, dapper.2 meeting in 5?
[17:54] <BenC> pitti: yeah
[20:01] <pitti> BenC: ah, I know why I didn't notice the mpt symbol error in my existing dapper install
[20:01] <pitti> BenC: in d-i, it prefers the driver from lbm, but in an installed system it prefers the one from linux-image
[20:02] <pitti> BenC: at least I get 3.03.04 loaded
[20:05] <pitti> BenC: that's both in my permanent dapper vmware as well as the one I just test-installed
[20:07] <pitti> BenC: modules.dep does not have any "/updates/" in it; after a depmod -a it has
[20:13] <pitti> BenC: might the reason be that the one in /updates had the faulty symbols?
[20:14] <BenC> pitti: make sure depmod -a is run, and update-initramfs -u afterwards
[20:16] <pitti> BenC: right, after depmod -a I get the new version
[20:16] <pitti> BenC: my concern is, if in a fresh install the old version is used, then that sounds like a bug?
[20:16] <pitti> (i. e. the default modules.dep is wrong)
[20:17] <BenC> pitti: lbm should be running depmod, and update-initramfs, at least it did on my system
[20:17]  * pitti upgrades to the new lbm in -proposed and tests further
[20:23] <maks_> BenC: initramfs-tools in unstable has pretty stabilized
[20:23] <maks_> so if you wana go for long term support a merge would be cool
[20:23] <maks_> can lend my eyes to the resulting diff
[20:23] <maks_> :)
[20:24] <pitti> BenC: ah, after upgrading to new lbm I get 3.03.09 by default on boot, so that looks good
[20:24] <pitti> BenC: I'll test it again tomorrow when it's on the CD (the modules.dep issue)
[20:38] <pitti> BenC: hmm: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/56885/comments/6 :(
[20:38] <ubotu> Launchpad bug 56885 in linux-source-2.6.15 "e1000 driver not working properly on x86_64?" [Medium,Fix committed]