[00:52] <elkan76> Hi!
[00:58] <elkan76> I 've a doubt, on september 12th an update, drops down my wifi, and i report the bug (#269533), today another update was fixiing the bug (#259816) fix my wifi , but a half hour later it drops down like the first time, i repport this and go tu the second bug tu link them because the work to fix it has effects on my system. I'm using the proposed kernel.
[03:10] <philsf> where can I get the kernel 2.6.27, that is mentioned in possibly all kernel related bug reports, for hardy?
[03:10] <nullack> Hi kernel team :) Does the intrepid alpha kernel have any debugging code that would slow it down
[03:10] <nullack> Im trying to chase down some performance problems
[03:12] <nullack> philsf Such a configuration would be unsupported and would need to be compiled by you
[03:12] <nullack> philsf Intrepid has that kernel revision but its Alpha software so it comes with the usual caveats
[03:13] <philsf> so, the ubiquous message from ogasawara across the bug reports actually calls for intrepid testing, and not just the kernel?
[03:13] <nullack> yep, no .27 in hardy
[03:13] <philsf> what about the bugs in hardy, won't they be fixed?
[03:13] <nullack> They might be as backports
[03:14] <philsf> I see, thanks for the info, then
[03:15] <philsf> nullack: as a side question, some bugs I subscribe to are considered "fixed" because they no longer appear in intrepid. Shouldn't hardy deserve the fix as well, being LTS?
[03:16] <nullack> philsf If the fix works in Intrepid then it might be considered for backporting onto Hardy
[03:16] <philsf> nullack: what can I do, as a user, to make it happen?
[03:17] <nullack> https://help.ubuntu.com/community/UbuntuBackports
[03:18] <philsf> well, duh, I should've known better by now :) thanks again
[03:19] <wgrant> nullack: No. That's not for backporting fixes.
[03:20] <wgrant> Important fixes may be SRUed, but Ubuntu Backports are not for fixing bugs.;
[03:21] <nullack> wgrant : Wouldnt a new version of a package be backport? The difference between SRU and Backports isnt clear to me
[03:22] <wgrant> SRU is for fixing bugs.
[03:22] <wgrant> Backports are for new version.
[03:22] <wgrant> Kernels will not be backported.
[03:22] <wgrant> Backports will not be granted to fix bugs.
[03:23] <nullack> wgrant : So an SRU could involve a version upgrade by fixing a bug? Whereas a backport is to get new features offered in new versions?
[03:23] <wgrant> An SRU will involve only the minimal patch needed to fix the bug.
[03:23] <wgrant> Unless you are Mozilla.
[03:23] <nullack> wgrant : right, thanks mate for helping me understand :) Makes sense from a regression point of view
[03:24] <wgrant> Yes. We do not do crazy things like some other distros.
[03:24] <philsf> and yet are no so conservative as debian
[03:24] <philsf> *not
[03:25] <wgrant> With regard to SRUs we are rather close.
[03:25] <wgrant> Except that they do them all at once.
[03:26] <philsf> is the -updates repo only for SRUs, or are there other kind of updates there? It's a rather dynamic repo there
[03:26] <wgrant> -updates is only for SRU.
[03:26] <wgrant> +s
[03:27] <wgrant> Well, security updates are also copied into there now for various reasons, but they're generally even more conservative.
[05:28] <lukehasnoname> bug #59695
[05:53] <nullack> Im trying to chase down some performance problems in Intrepid. Can any kernel folk advise me if the Intrepid Alpha has debug code in it slowing it down?
[05:54] <nullack> i.e. The Alpha kernel
[06:04] <TheMuso> nullack: I wouldn't think so. I think the debug code for the kernels is in a separate package.
[06:04] <TheMuso> However, I am not a kernel dev, so don't know for sure.
[06:10] <nullack> TheMuso : Thanks, btw, Im on your PPA for PA, working well
[06:11] <TheMuso> nullack: Sounds good, however I think 0.9.10 will be used for intrepid. Too many regressions from other users that need addressing at he alsa level.
[06:11] <TheMuso> As well as stream switching, and usb card/speakers issues.
[06:12] <nullack> TheMuso : yep thats why having test coverage as wide as possible is important :)
[06:12] <TheMuso> nullack: Totally.
[06:12] <TheMuso> Maybe for jaunty.
[15:02] <persia> Good day.  I've some questions about kernel packaging, and hoped someone could direct me.
[15:03] <persia> Firstly, I've noticed that the linux-meta package seems to be arch-dependent, rather than arch: all.  I wondered if this was due to convenience of packaging with the git tree, or was chosen to meet the constraints of "depending on the latest kernel".
[15:04] <persia> Also, I've noticed that the various ports all seem to have linux-$(architecture) as the name of the package.  Would it be sensible for an arch-dependent metapackage to also provide "linux" that depends on e.g. "linux-powerpc"?
[15:04] <persia> Lastly, I'm wondering how the -meta packages are tracked.  Is there a script that pulls them out of git, or are they handled as source packages directly?
=== chuck__ is now known as zul
=== chuck__ is now known as zul
=== BenC1 is now known as BenC