[00:30] hi, did you notice the nv 71.86.04 and 96.43.05 drivers? [00:31] also i man not sure if completely disabling alsa in the kernel is a good a idea [00:31] there are several modules which have alsa build-deps [00:32] CONFIG_VIDEO_SAA7134_ALSA=m [00:32] CONFIG_VIDEO_CX88_ALSA=m [00:33] i dont think you get those externally [00:51] also how about adding em8300 cvs to lum... [01:00] hda-intel is really better in new alsa but you miss modules [01:09] btw. compiled 386 kernel,as this does not use smp you can use hostap_pci, that module is not smp save [01:35] Kano: lum already has newer alsa. [01:36] i know, i compiled it [01:36] but you miss modules! [01:36] these have depends on alsa in the kernel [01:36] which are not in external alsa === reynaldo_ is now known as reynaldo === asac_ is now known as asac === lamont` is now known as lamont === fabbione is now known as thegodfather [08:04] moin === doko_ is now known as doko [09:39] rtg: why do you completely disable alsa? then modules with alsa depend does not build! [10:45] how should we handle dapper->hardy upgrades? I assume -686 should transitioned to -generic. what would be people with -386? should we move them to -generic, leave them with -386? there is some code in the release-ugrader already that will move multi-core people from 386 to generic. [11:38] As there are some cases where -386 is needed (very old computers), I don't think moving everyone to -generic is a good idea as it may break some system. [11:38] You could also detect the CPU (as you probably do for multi-core CPU) and based on that move them to -generic or keep them on -i386 [11:39] just uname -m [11:40] if itis not i586 or i686 then keep it [11:41] i guess it is very rarely needed. i just tested the kernel, and did not really like it, had shutdown problems. ok the system was a e6600 ;) [13:12] stgraber: thanks, the current strategy is to not change it unless its a multicore cpu, but I was wondering if that is wise given that a lot of people will have -386 on their dapper install. but if the only disadvantage is that they won't have multicore, then that sounds not too bad [13:39] I like the idea of kano === \sh_away is now known as \sh [16:59] with the US awake now, maybe I can ask my earlier question again: how should we handle dapper->hardy upgrades? I assume -686 should transitioned to -generic. what would be people with -386? should we move them to -generic, leave them with -386? there is some code in the release-ugrader already that will move multi-core people from 386 to generic. I like the suggestion of simply checking uname -m [16:59] but I wonder what machine will not work with -generic and what the installer does in this case [16:59] (or how it detect which ones need -386) === reynaldo_ is now known as reynaldo [17:19] mvo_: -generic requires at least a 586 class CPU. [17:41] rtg: so uname -m and checking for i586 is safe? everything iwth i586 or i686 can get -generic then and the rest remains untouched [17:42] mvo_: that is my belief. [17:42] rtg: great, thanks === clever is now known as clever[rev] [19:15] whats mask in the linux-ubuntu-modules commit message for external driver? [19:17] zul: dunno [19:17] zul: comment it out [19:17] ok === \sh is now known as \sh_away === clever[rev] is now known as clever [23:44] BenC: still around? [23:46] bdmurray: in some vague way, yeah :) [23:48] I've suspended and resumed using the Live CD and discovered some SQUASHFS errors in dmesg right after some "Buffer I/O error on device sr0". Is that worth reporting? [23:48] the live CD shouldn't allow suspend. [23:49] I thought it should allow suspend and not hibernate. [23:51] your CD reader might well be connected over USB, in which case you'll go boom [23:53] hmm, that's true. having it seems like a good way to get people to test suspend w/o having to install the development release though