[02:37] <goldphish> Is there a way to use menuconfig to configure a kernel and still use debian/rules to build it?
[02:45] <johanbr> goldphish: I usually run menuconfig (or whatever) first and then do "fakeroot make-kpkg --initrd kernel_headers kernel_image".
[02:47] <goldphish> I tried that but then linux-restricted-modules and linux-ubuntu-modules fails in random ways
[02:48] <goldphish> This whole process is way more complex than it needs to be. All I was is a single module that debian was too stubborn to include in their kernel. (it's in the vanilla)
[02:55] <johanbr> goldphish: So just build that single module, then.
[02:59] <goldphish> how?
[03:00] <johanbr> Which module is it?
[03:00] <goldphish> keyspan
[03:01] <goldphish> it's in the kernel source
[03:01] <goldphish> so there is no seperate package for it
[03:01] <goldphish> there was some political drama over licensing and Debian decided not to include it. Everyone else is fine with it
[03:02] <mjg59> goldphish: That implies that this isn't really the right place to be asking...
[03:02] <goldphish> mjg59: why not?
[03:02] <mjg59> Or is it also disabled in Ubuntu?
[03:02] <mjg59> We don't use Debian's kernels
[03:02] <goldphish> yeah
[03:03] <goldphish> whoops, I meant to say it's not included in Ubuntu kernels either
[03:03] <goldphish> but the problem originated with Debian
[03:03] <johanbr> There is a module named keyspan in the Feisty kernel I'm running right now.
[03:04] <goldphish> interesting; it's missing in the gutsy kernel
[03:04] <goldphish> aka 2.6.22-14-generic
[03:06] <johanbr> Bug report, including a link to a deb someone built: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132106
[03:06] <ubotu> Launchpad bug 132106 in linux-source-2.6.22 "[gutsy] keyspan serial adapter not detected" [Low,Triaged] 
[03:07] <goldphish> nice
[04:44] <shenki> how would one go about finding what git revision a released kernel comes from?
[05:38] <goldphish> I created a kernel using make-kpkg. How do I go about rebuilding linux-restricted-modules? It wants to build for "flavours" though there really isn't one
[08:05] <kraut> moin
[13:15] <zul> um...http://launchpadlibrarian.net/11049559/buildlog_ubuntu-hardy-powerpc.linux-restricted-modules-2.6.24_2.6.24.2-2.8_FAILEDTOBUILD.txt.gz
[15:40] <soren> It seems https://lists.ubuntu.com/archives/kernel-team/2007-November/001891.html was never applied. Could someone do that please?
[15:41] <soren> BenC said it's ok (in the e-mail I'm replying to at https://lists.ubuntu.com/archives/kernel-team/2007-November/001895.html)
[15:44] <rtg> soren: got it
[15:46] <soren> rtg: Thanks very much!
[16:41] <BenC> sbader: Welcome...how was your holiday?
[16:42] <sbader> Thanks. Holiday was quite well (but catched a cold at the end)
[16:49] <rtg> sbader: glad to have you on board.
[16:52] <crispin> BenC__: I'm trying to get the fusion driver working in dapper on a Sun x4100, but have found what I think is a bug in the linux-backports-modules package - the mutex_init() wrapper calls sema_init(..., 0), that locks up the booting for me
[16:52] <crispin> shouldn't it be sema_init(..., 1) ?
[16:53] <BenC__> crispin: that's possible...any chance you could test that?
[16:53] <crispin> yeah, it boots
[16:53] <crispin> (with 1)
[16:53] <BenC> does the driver work though?
[16:53] <crispin> not quite - it claims I have a 'generic sg1 type 0' scsi device
[16:54] <crispin> it doesn't find the partitions
[16:55] <crispin> with the 0 in the sema_init it locks up after a line like: "scsi0: ioc0: LSISAS1064: FwRev=...., Ports=1, MaxQ=511, IRQ=16"
[17:03] <Kano> hi, did somebody test a kernel with # CONFIG_IDE is not set
[17:03] <Kano> thats the one and only way to boot for some systems
[17:05] <Kano> kanotix thorhammer rc7 uses this kind of kernel, modified 2.6.24-3 kernel, patched to 2.6.24-rc6-git7, additional dmraid patch and secperm
[17:06] <Kano> samsung x65 can not boot with a "generic" kernel
[17:06] <Kano> no way
[17:11] <zul> heylo
[18:01] <lamont> BenC: did the care package arrive ok?
[18:42] <BenC> lamont: yes, thanks...I'm hoping to get time today to mess around with it
[18:59] <lamont> BenC: ok.  the machines both think that they're $mumble.lamont, and fetch an addr from dhcp
[19:00] <lamont> and if you want, I have mac addrs
[19:00] <BenC> np, I have open dhcp on my lan
[19:09] <rtg> BenC: I see that ia64 has section conflict errors similar to powerpc64-smp
[19:10] <BenC> rtg: yeah, starting to sound like a 64-bit issue, but sparc64/hppa64 seem unaffected
[19:10] <BenC> rtg: possibly forcing gcc-4.1 would be a good idea on ia64 (which I can test once I get this new ia64 up and running)
[19:11] <rtg> BenC: sounds good. 
[19:11] <BenC> rtg: somehow the linux-headers-2.6.24-x-powerpc64 package needs to depend on gcc-4.1
[19:12] <BenC> rtg: so we don't have to force that build-dep in lum/lrm/lbm
[19:12] <BenC> which is what I did temporarily
[19:14] <rtg> BenC: right.
[19:27] <rtg> BenC: should hppa64 have the same Build-Depends as powerpc64 in linux-headers? For example, gcc-4.1-hppa64 [hppa] and binutils-hppa64 [hppa]
[19:27] <BenC> rtg: yeah, it should
[19:27] <BenC> then we can remove those hardcoded build-deps from lum/lrm/lbm too
[19:28] <rtg> BenC: well, we'll have to futz with the kernel arch Makefile for hppa in order to ensure it uses the correct compiler.
[19:29] <BenC> rtg: no, it is already setup that way
[20:59] <bluefoxicy> Are Ubuntu kernel modules digitally signed such that they will load if Ubuntu boots with "enforcemodulesig"
[22:32] <tjaalton> BenC: I've got a new lrm readyish with updated fglrx & nvidia-glx-new (stable releases). I've been running the new nvidia for over a week now without too much trouble
[22:34] <tjaalton> but there's a bug report about nvidia not being uninstallable that I need to check before I'd upload it
[22:35] <tjaalton> if you don't mind me doing that, I mean
[22:46] <tjaalton> fglrx 7.12 seems to have some issues with widescreen resolutions though, but on the other hand the current version leaks memory
[23:16] <Kano> tjaalton: well best wait for 8-1
[23:20] <tjaalton> Kano: no idea what the marketing name is, but apparently 8.45 is the next "traditional" version
[23:20] <Kano> i know
[23:21] <Kano> i still would prefer 8.39.4, because gl2benchmark works with it
[23:21] <Kano> and googleeath too
[23:21] <tjaalton> we have 8.43 already
[23:21] <Kano> but thats a crappy version
[23:22] <tjaalton> they all are :)
[23:22] <Kano> 8.40 had that googleearth bug
[23:22] <Kano> all newer can not render correctly
[23:22] <tjaalton> besides, whatever the version, it needs to work with 2.6.24rc kernel and xserver-1.4
[23:22] <Kano> it does
[23:23] <Kano> my script can show it to you ;)
[23:23] <tjaalton> no point to go back
[23:23] <Kano> http://kanotix.com/files/install-fglrx-debian.sh
[23:23] <Kano> install-fglrx-debian.sh -v 8.39.4
[23:23] <Kano> it can install ANY version
[23:23] <Kano> for 2.6.24 down to 8.39.4
[23:24] <BenC> tjaalton: excellent, thanks
[23:24] <tjaalton> BenC: great, I'll upload it tomorrow, but without the new ati as it seems to have issues with latest 2.6.24rc's and some widescreen resolutions..
[23:25] <Kano> and with 7-11 and below with firegl cards ;)
[23:25] <Kano> until you patch it and replace the control file
[23:32] <Kano> btw. with my new thorhammer iso you can do funny things like: fglrx=v:8.39.4 to dl and install that specific driver on the fly
[23:33] <Kano> also it has CONFIG_IDE unset..
[23:33] <Kano> it seems you have fear to use this
[23:34] <Kano> but it is the best fix to get around some issues like samsung x65 and a nforce 430 board that has only problems with 2.6.24 generic (but not 2.6.22)
[23:36] <Kano> http://kanotix.com/files/thorhammer/kernel-2.6.24/linux/linux_2.6.24-3.5+c0.kanotix.1.tar.gz
[23:36] <Kano> patched up to 2.6.24-rc6-git7 - extra patches the custom kernel way
[23:37] <Kano> all ubuntu standard kernels disabled
[23:39] <Kano> also i set the default to concurrency level 4
[23:39] <Kano> for faster compile with standard pbuilder
[23:40] <Kano> 1 is a bad fallback