[00:14] <angie> how do i build nvidia support into my xconfig for a ubuntu gresec kernel setup
[00:30] <angie> how do i select the kernel i want to use in ubuntu
[00:31] <angie> lik eeselect
[07:15] <jonpackard> Hello. I'm testing the jaunty-armel 2.6.28-4-versatile kernel in qemu and seem to be running into problems. I've been comparing it against the debian-armel 2.6.26-1-versatile kernel. I can boot the debian kernel fine but I can't even get a kernel panic out of the ubuntu kernel. Could anybody please offer any suggestions?
[10:49] <soren> keybuk: What is your suggested course of action wrt. bug 314879? You don't want udev's initramfs hook to create /etc/udev/rules.d, and I feel it would be wrong for lvm2, dmsetup, mdadm, etc. to move to /lib/udev/rules.d without a versioned dependency on udev, but you just /removed/ lvm2's dependency on udev, so I'm a bit confused where we're going here?
[10:49] <ubot3> Malone bug 314879 in udev "root on LVM broken since latest udev 136-2" [High,Confirmed] https://launchpad.net/bugs/314879
[10:49] <soren> New debhelper will make sure the rules files are installed in the right place, but the initramfs hooks all hardcode the location.
[10:50] <Keybuk> soren: the removing the dep was a mistake, the dep can go back
[10:50] <Keybuk> I'd assumed the dep was simply there for watershed
[10:50] <Keybuk> so changed it to one on watershed
[10:51] <Keybuk> btw, devmapper doesn't depend on udev - so there's no way to introduce a versioned dependency on it ;)
[10:51] <soren> Ok. So a versioned dependency on udev (>> 134) ?
[10:51] <Keybuk> udev (>= 136-1)
[10:52] <soren> Hmm... Ok. So for devmapper we just change the path and pretend everything is fine?
[10:52] <soren> (which it is, but still)
[10:52] <Keybuk> yeah
[10:52] <Keybuk> there's no configure-order dependency with udev
[10:53] <soren> Ok. I can do lvm2, mdadm and devmapper.
[10:53] <soren> (devmapper needs a no-change upload to move to /lib/udev/rules.d)
[10:53] <Keybuk> no change?
[10:53] <Keybuk> at least bump the b-d on debhelper?
[10:55] <soren> Erm.. No, I didn't mean to do that, actually.
[10:56] <soren> It doesn't need the newer debhelper to work. If people want to use the source package on older versions of Ubuntu, debhelper will DTRT.
[10:57] <soren> The dependency is for the binary package, really, but there's really no useful way to express that.
[10:57] <soren> Hmm...
[10:57] <soren> Unless, of course..
[10:58] <soren> We could make the new dh_installudev add the versioned udev dependency to a misc:Depends?
[10:58] <soren> Oh, right, you said devmapper couldn't depend on udev.
[10:59] <soren> brb
[11:01] <Keybuk> well, I think it can
[11:01] <Keybuk> but Debianistas do that silly "but you can use devmapper without udev, I want to uninstall udev, it should only be a Recommends" thing
[11:02] <Keybuk> and of course, you can't have versioned Recommends
[11:03] <Keybuk> honestly, I don't worry about it much
[11:03] <Keybuk> they'll have the new udev anyway
[11:05] <soren> Blargh, dmsetup's hook of course needs the new path.
[11:08]  * soren needs to reboot
[11:54] <smb_tp> Keybuk, BTW, forget my mail then. It was just about the same issue with rules.d
[12:28] <Keybuk> anyone feel brave enough to set CONFIG_USB_DEVICEFS=n ?
[12:35] <Keybuk> soren: have uploaded a version of watershed that installs into the initramfs, you'll want to depend on that too (>= 2)
[12:40] <soren> Keybuk: Ah, yes. Will do.
[12:49] <soren> Keybuk: Pushed devmapper, lvm2, and mdadm.
[13:11] <redondos> hi. what is the reasoning behind disabling CONFIG_SND_DYNAMIC_MINORS in -generic and -server but not in -virtual?
[13:16] <soren> Which Ubuntu version?
[13:25] <redondos> soren: 8.04
[13:26] <soren> No particular reason. Sounds like a mistake.
[13:27] <redondos> the mistake being not having it enabled in all kernels?
[13:27] <redondos> (or the other way around)
[13:55] <soren> redondos: Mistake being that the virtual kernel differs.
[14:15] <jonpackard> Hello. I'm testing the jaunty-armel 2.6.28-4-versatile kernel in qemu and seem to be running into problems. I've been comparing it against the debian-armel 2.6.26-1-versatile kernel. I can boot the debian kernel fine but I can't even get a kernel panic out of the ubuntu kernel. Could anybody please offer any suggestions?
[14:35] <marijus> hello is there a testing ppa for 2.6.29?
[14:38] <rtg> jonpackard: wait until Monday when Amit is back. 
[14:38] <rtg> marijus: no test kernel yet
[14:40] <redondos> thanks, soren
[14:41] <jonpackard> Thanks rtg!
[15:23] <Kano> hi rtg , do you want to include a backport of rt2860/70 from 2.6.29/staging? those wifi chips are very common
[15:23] <Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=91980990527258a075361490cecadbb7356fc0d2
[15:23] <Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c55519ff75224222f4668c92ae3733059269f575
[15:26] <rtg> Kano: do those drivers actually work? I'm not interested in a bunch of bug reports on what greg refers to as "utter garbage"
[15:26] <Kano> rtg: well i know one with one of those chips, could be simply tested when you add it
[15:28] <rtg> Kano: I'll tell you what, you add it to your kernel and report back. I'm not really interested in a development driver.
[15:28] <Kano> even if lots of netbooks already use em and those cheap draft-n sticks?
[18:26] <maxb> Is it documented anywhere why linux-restricted-modules works the way it does? I am curious why linking the modules at boot-time is useful
[18:32] <rtg> maxb: I've argued that it is a legal fiction. I'm trying to get that runtime link step removed based on boot time performance.
[18:32] <maxb> I'm quite curious as to the rationale of the fiction even if it is fiction! :-)
[18:33] <mjg59> maxb: Issues with the legalities of distributing binary-only modules that are linked against GPLed components
[18:34] <maxb> where the gpl components are other .o files that make up the same module?
[18:35] <rtg> maxb: metaphorically, its the difference of shipping with a loaded gun v.s. shipping a gun with the ammo packed in the same box.
[18:35] <maxb> nice analogy :-)
[18:37] <mjg59> maxb: Yeah
[18:38] <maxb> ok, thanks. I'm happy now that I know why this crazy dance is happening :-)
[18:39] <mjg59> (Note: Not legal advice, not in a position to speak on behalf of Canonical, blah blah blah)
[19:34] <pwnguin> if linking at runtime is a legal fiction, then how is removing that step acceptable?
[19:38] <maxb> I assume rtg was implying "fictionally legal"
[19:40] <pwnguin> usually, "legal fiction" denotes a legal theory believed to not stand up in court
[19:42] <maxb> Well, it probably doesn't matter too much. Intrepid's l-r-m only contains two wireless drivers, and one of those (madwifi) is becoming properly free
[19:42] <pwnguin> i believe nvidia has a similar problem?
[19:42] <maxb> That seems to have been migrated to dkms
[19:43] <pwnguin> right. hrm
[19:44] <pwnguin> which is sort of a link on package install or kernel upgrade, no?
[19:45] <maxb> s/link/build-from-source/
[19:45]  * maxb chuckles at cking's quit message
[19:47] <pwnguin> i have join/parts on ignore on this channel, since a lot of activity is basically just that =/
[19:47] <maxb> * cking has quit ("Me transmitte sursum, caledoni")
[19:47] <pwnguin> and i can't figure out how to get irssi's activity monitor to ditch the boring activity status
[19:48]  * maxb hunts for that setting in his own irssi config
[19:48] <maxb> /set activity_hide_level JOINS PARTS QUITS
[19:49] <pwnguin> there's two levels; one is people saynig things, which is white for me. the other is joins etc and is blueish
[19:50] <pwnguin> maxb: if that works, thanks!
[19:50] <maxb> wfm :-)
[20:41] <pwnguin> maxb: I think adding NICKS helps, too