* Mark 27e3kk302@sneakemail.com [20070526 10:15]:
I really appreciate your feedback but you seem to prefer writing mails instead of trying what I wrote. [Mika]
[...]
During beta I would have done as requested to improve 1.0 final. Grml gave me no task, no suspect kernel config flags to isolate, etc. Radio silence made me hungry for info-crumbs...
How often do I have to write this again? I had no idea where the problem derived from.
Beta cycles are meant to catch bugs before release. Kernel regression is just another bug category. A kernel regression which, for instance, broke your laptop, would prevent a grml release. And that is how it should be.
Just because one single device does not work anymore (notice: "broke your laptop" is different from "my external harddisk can't be accessed") without any relevant changes in the kernel configuration it won't become a release-stopper for everyone out there.
Re bisect: Other people do that coordinated by -stable. My job is sysadmin, not kernel dev. The whole point of Linux for us, rather than BSD or Open Solaris or Nexenta or whatever, is hardware support. If we have to become kernel devs too, supporting/debugging our own hardware, then we would consider other kernels to develop, with possibly more rational code. Note about USB in Linux, "the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem" (Greg Kroah-Hartman). Anyway it's not my call. The last thing my boss will allow is debugging Linux hardware drivers.
Again, you seem to prefer writing mails instead of running those fscking 4 commands. You don't have to become a kernel dev for installing a kernel and test it once.
What I'm asking is, do you inspect a grml bug report, and then talk to -stable to see if they have anything related in their pipeline, and then decide whether grml should wait for a patch?
The stable-queue is available via git before being available as new official -stable release. I track that of course to be able to decide about kernel update/freeze.
Looking at -stable patch-2.6.20.12, I see USB fixes relating to mutexes, IRQs, etc. - the big stuff.
.12 does not include anything else than a bugfix for GEODE-AES: http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.12
What -stable version is 2.6.20-grml in grml 1.0 final?
It's all documented on http://grml.org/kernel/ - 2.6.20.11.
Next, how does Debian fit into all this? Grml tracks Debian unstable.
grml is based on Debian.
But grml releases are tied to Linus's kernel releases, not Debian kernel work, right? Correct me on anything.
grml's kernel has nothing to do with the one from Debian.
Does grml kernel customization include the possibility of using a -stable release that is not yet incorporated into Debian? Or is Debian a limiting factor?
Sorry, I don't understand your question. grml and Debian regarding the kernel are two different things.
Dumb question maybe, but if I compile my own 2.6.20-x using grml source and patched from -stable, will it work with grml 2.6.20-grml repos? I'm willing to compile a kernel but if I start having to build repos too, I've already become a custom distro, and I'd rather not.
Everything not containing '*2.6.20*' inside the package name/version can be used without any further changes. Only kernel modules build against the official 2.6.20-grml kernel can't be used any further.
regards, -mika-