[02:01] <zul> can someone ask the guy to updating all of these bug reports to stop
[02:06] <kylem> who's this?
[02:07] <zul> forget his name
[02:09] <zul> caravena
[02:33] <mjg59> zul: Done
[11:44] <thotz> this bug should be set to HIGH: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/84964
[11:45] <thotz> there are more such bugs like https://launchpad.net/ubuntu/+source/casper/+bug/86255
[11:48] <thotz> now in: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86255
[11:49] <thotz> I'm not sure where the problem is, but it has something to do with jmicron
[02:49] <Mithrandir> BenC: can you please, please, please, please get 43531 fixed soon?  It should be absolutely trivial.
[02:51] <BenC> Mithrandir: just requires re-uploading every boot loader we have :P
[02:51] <Mithrandir> BenC: why would it do that?  And, if that's needed then do that.
[02:51] <BenC> I had forgotten about it. I'll get to it today
[02:51] <Mithrandir> cheers.
[02:52] <BenC> Mithrandir: Because the fix is to add a Provides boot-loader to every one so the kernel can depend on that
[02:52] <Mithrandir> I considered raising it to critical or something to get your attention, but well, that's slightly excessive
[02:52] <BenC> and then creating a no-boot-loader meta
[02:52] <Mithrandir> why not just make nobootloader produce a deb and not just a udeb?
[02:53] <BenC> I could do that for the latter I guess
[02:53] <cjwatson> it isn't really anything to do with the nobootloader udeb, and the naming would be wacky
[02:54] <cjwatson> but I guess
[02:54] <BenC> I've been procrastinating on it because I'm not sure I'm going to like the outcome of it...worried about deps causing all sorts of unexpected weirdness
[02:56] <BenC> cjwatson: Should I create a new meta package, or use the nobootloader udeb->deb approach?
[02:56] <cjwatson> up to you, I was just sticking my oar in :)
[02:56] <BenC> I can add a no-boot-loader to linux-meta easily enough
[02:57] <cjwatson> actually I'd rather a new metapackage so that at some point in the future nobootloader can be synced again
[02:57] <BenC> ok
[03:07] <Mithrandir> BenC: when do you actually mark bugs as fix committed?  There's a 7-8 bugs milestoned for herd 4 which are fix committed and I am wondering if I can consider those fixed or if I should bring them forward.
[03:07] <BenC> Mithrandir: Most likely fix released
[03:07] <BenC> I'm a little slow still remarking things to released
[03:11] <BenC> Mithrandir: marked all the ones that should be now
[03:11] <Mithrandir> BenC: thanks.
[03:33] <kylem> morning.
[08:33] <Nafallo> s/-/./
[08:43] <Nafallo> qc-usb fwiw
[09:31] <jbailey> Will Feisty grow things to autodetect p4-clockmod/acpi-cpufreq/etc?
[09:32] <mjg59> You never want p4-clockmod
[09:32] <mjg59> acpi-cpufreq ought to already be autoloaded when appropriate, I think
[09:33] <jbailey> Hmm.  Last time I checked, I think my toshiba works with p4-clockmod, but not acpi-cpufreq.
[09:34] <jbailey> mdy (our ISV guy) just upgraded to feisty, but we had to add acpi-cpufreq to /etc/modules.
[09:35] <mjg59> No, you *really* never want p4-clockmod
[09:35] <mjg59> It doesn't do voltage scaling
[09:35] <mjg59> Ah
[09:36] <mjg59> sed s/acpi/acpi-cpufreq/ -i /etc/init.d/powernowd
[09:36] <mjg59> The module name has changed
[09:36] <mjg59> Ought to fix that
[09:46] <jbailey> Do all the chips support voltage scaling?
[09:46] <jbailey> I thoguht that's why p4-clockmod was still around, for the chips that didn't.
[10:10] <mjg59> Right, but there's no point in reducing the clock if you're not dropping the voltage
[10:12] <JanC> mjg59: except if you want to use more power because everything takes longer?  :)