* Mark <[EMAIL PROTECTED]> [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- -- http://grml.org/ # Linux for texttool-users and sysadmins http://wiki.grml.org/ # share your knowledge http://grml.supersized.org/ # the grml development weblog #grml @ irc.freenode.org # meet us on irc
signature.asc
Description: Digital signature
_______________________________________________ Grml mailing list - [email protected] http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
