=== asac__ is now known as asac === asac_ is now known as asac === asac_ is now known as asac [02:37] Is there a way to use menuconfig to configure a kernel and still use debian/rules to build it? [02:45] goldphish: I usually run menuconfig (or whatever) first and then do "fakeroot make-kpkg --initrd kernel_headers kernel_image". [02:47] I tried that but then linux-restricted-modules and linux-ubuntu-modules fails in random ways [02:48] 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] goldphish: So just build that single module, then. [02:59] how? [03:00] Which module is it? [03:00] keyspan [03:01] it's in the kernel source [03:01] so there is no seperate package for it [03:01] there was some political drama over licensing and Debian decided not to include it. Everyone else is fine with it [03:02] goldphish: That implies that this isn't really the right place to be asking... [03:02] mjg59: why not? [03:02] Or is it also disabled in Ubuntu? [03:02] We don't use Debian's kernels [03:02] yeah [03:03] whoops, I meant to say it's not included in Ubuntu kernels either [03:03] but the problem originated with Debian [03:03] There is a module named keyspan in the Feisty kernel I'm running right now. [03:04] interesting; it's missing in the gutsy kernel [03:04] aka 2.6.22-14-generic [03:06] 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] Launchpad bug 132106 in linux-source-2.6.22 "[gutsy] keyspan serial adapter not detected" [Low,Triaged] [03:07] nice [04:44] how would one go about finding what git revision a released kernel comes from? [05:38] 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 === XSource_ is now known as XSource === asac_ is now known as asac === fabbione is now known as thegodfather [08:05] moin === XSource_ is now known as XSource === luka74 is now known as Lure === amit1 is now known as amitk === chuck_ is now known as zul [13:15] um...http://launchpadlibrarian.net/11049559/buildlog_ubuntu-hardy-powerpc.linux-restricted-modules-2.6.24_2.6.24.2-2.8_FAILEDTOBUILD.txt.gz === \sh_away is now known as \sh [15:40] It seems https://lists.ubuntu.com/archives/kernel-team/2007-November/001891.html was never applied. Could someone do that please? [15:41] 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] soren: got it [15:46] rtg: Thanks very much! === chuck is now known as zul [16:41] sbader: Welcome...how was your holiday? [16:42] Thanks. Holiday was quite well (but catched a cold at the end) [16:49] sbader: glad to have you on board. === \sh is now known as \sh_away [16:52] 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] shouldn't it be sema_init(..., 1) ? [16:53] crispin: that's possible...any chance you could test that? === BenC__ is now known as BenC [16:53] yeah, it boots [16:53] (with 1) [16:53] does the driver work though? [16:53] not quite - it claims I have a 'generic sg1 type 0' scsi device [16:54] it doesn't find the partitions [16:55] 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] hi, did somebody test a kernel with # CONFIG_IDE is not set [17:03] thats the one and only way to boot for some systems [17:05] 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] samsung x65 can not boot with a "generic" kernel [17:06] no way [17:11] heylo === allee_ is now known as allee [18:01] BenC: did the care package arrive ok? === \sh_away is now known as \sh [18:42] lamont: yes, thanks...I'm hoping to get time today to mess around with it [18:59] BenC: ok. the machines both think that they're $mumble.lamont, and fetch an addr from dhcp [19:00] and if you want, I have mac addrs [19:00] np, I have open dhcp on my lan [19:09] BenC: I see that ia64 has section conflict errors similar to powerpc64-smp [19:10] rtg: yeah, starting to sound like a 64-bit issue, but sparc64/hppa64 seem unaffected [19:10] 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] BenC: sounds good. [19:11] rtg: somehow the linux-headers-2.6.24-x-powerpc64 package needs to depend on gcc-4.1 [19:12] rtg: so we don't have to force that build-dep in lum/lrm/lbm [19:12] which is what I did temporarily [19:14] BenC: right. [19:27] 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] rtg: yeah, it should [19:27] then we can remove those hardcoded build-deps from lum/lrm/lbm too [19:28] 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] rtg: no, it is already setup that way [20:59] Are Ubuntu kernel modules digitally signed such that they will load if Ubuntu boots with "enforcemodulesig" [22:32] 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] but there's a bug report about nvidia not being uninstallable that I need to check before I'd upload it [22:35] if you don't mind me doing that, I mean [22:46] fglrx 7.12 seems to have some issues with widescreen resolutions though, but on the other hand the current version leaks memory === Lure_ is now known as Lure [23:16] tjaalton: well best wait for 8-1 [23:20] Kano: no idea what the marketing name is, but apparently 8.45 is the next "traditional" version [23:20] i know [23:21] i still would prefer 8.39.4, because gl2benchmark works with it [23:21] and googleeath too [23:21] we have 8.43 already [23:21] but thats a crappy version [23:22] they all are :) [23:22] 8.40 had that googleearth bug [23:22] all newer can not render correctly [23:22] besides, whatever the version, it needs to work with 2.6.24rc kernel and xserver-1.4 [23:22] it does [23:23] my script can show it to you ;) [23:23] no point to go back [23:23] http://kanotix.com/files/install-fglrx-debian.sh [23:23] install-fglrx-debian.sh -v 8.39.4 [23:23] it can install ANY version [23:23] for 2.6.24 down to 8.39.4 [23:24] tjaalton: excellent, thanks [23:24] 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] and with 7-11 and below with firegl cards ;) [23:25] until you patch it and replace the control file [23:32] 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] also it has CONFIG_IDE unset.. [23:33] it seems you have fear to use this [23:34] 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] http://kanotix.com/files/thorhammer/kernel-2.6.24/linux/linux_2.6.24-3.5+c0.kanotix.1.tar.gz [23:36] patched up to 2.6.24-rc6-git7 - extra patches the custom kernel way [23:37] all ubuntu standard kernels disabled [23:39] also i set the default to concurrency level 4 [23:39] for faster compile with standard pbuilder [23:40] 1 is a bad fallback