Re: Classification scheme for 2.6 kernel patches
* Marc Haber: > On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: >> Cherrypicking makes little sense, because there are only cherries. :-) > > For my systems, I care about security holes being fixed, but I do not > care about some obscure video hardware, or additional features. So > "Cherry" is relative. Fix upstream's security process, or use vendor kernels. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Classification scheme for 2.6 kernel patches
On Tue, Jan 11, 2005 at 10:25:37AM +0100, Florian Weimer wrote: > * Marc Haber: > > On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: > >> Cherrypicking makes little sense, because there are only cherries. :-) > > > > For my systems, I care about security holes being fixed, but I do not > > care about some obscure video hardware, or additional features. So > > "Cherry" is relative. > > Fix upstream's security process, Broken beyond repair, IMO. > or use vendor kernels. Which is what I am trying to do. Debian is a vendor. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Classification scheme for 2.6 kernel patches
* Marc Haber: > On Tue, Jan 11, 2005 at 10:25:37AM +0100, Florian Weimer wrote: >> * Marc Haber: >> > On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: >> >> Cherrypicking makes little sense, because there are only cherries. :-) >> > >> > For my systems, I care about security holes being fixed, but I do not >> > care about some obscure video hardware, or additional features. So >> > "Cherry" is relative. >> >> Fix upstream's security process, > > Broken beyond repair, IMO. There's a discussion on linux-kernel right now... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: > Hi, > > A few months ago, I asked on this list for more informative > description of patches enabling non-kernel hackers to choose > individual patchsets for their local kernels. Unfortunately, that > question was denied pretty fast. Looks like you guys don't have time > to write more extensive docs. [snip] > I would like to solicit your comments about this concept. I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Thiemo
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: > I think the effort to do so is better invested elsewhere. As a > general rule, the kernel team strives to keep the debian-specific > patches to a minimum. For people without in-depth kernel knowledge > it's probably best to take the full set of patches and add their > own (feature- ?) patches on top. Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: > I think the effort to do so is better invested elsewhere. As a > general rule, the kernel team strives to keep the debian-specific > patches to a minimum. For people without in-depth kernel knowledge > it's probably best to take the full set of patches and add their > own (feature- ?) patches on top. Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: > Agreed. The package is not a repository for cherrypicking patches > but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: > Actually, the kernel of my dreams is more near to the vanilla > kernel.org kernel, so I'd like to be able to throw out patches that > you need to apply because of your _much_ broader user base. > > otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the > distribution kernel because it is still stuck in NEW. It is adviseable > to take a snapshot from the Debian kernel svn? > > And, without trolling, I'd like to build my local kernels from sources > that haven't had drivers removed because of non-free licenses. I think only one of my machines is running a Debian-built kernel. Debian is much more forgiving of using a stock kernel than some other distributions. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:36:47PM +, Matthew Wilcox wrote: > On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: > > Actually, the kernel of my dreams is more near to the vanilla > > kernel.org kernel, so I'd like to be able to throw out patches that > > you need to apply because of your _much_ broader user base. > > > > otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the > > distribution kernel because it is still stuck in NEW. It is adviseable > > to take a snapshot from the Debian kernel svn? > > > > And, without trolling, I'd like to build my local kernels from sources > > that haven't had drivers removed because of non-free licenses. > > I think only one of my machines is running a Debian-built kernel. Debian > is much more forgiving of using a stock kernel than some other distributions. It definetely is, and it is exceptionally good in allowing usage of infrastructure for local builds and installation as well. kernel-package is one of the big advantages that has driven me to Debian years ago. Using infrastructure that makes individual patch files is a big step forward as well as this enables people to individually choose their patch sets. The progress is impressive. What we need now are better docs, and a few minor tweaks in the tools. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: > On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: > > I think the effort to do so is better invested elsewhere. As a > > general rule, the kernel team strives to keep the debian-specific > > patches to a minimum. For people without in-depth kernel knowledge > > it's probably best to take the full set of patches and add their > > own (feature- ?) patches on top. > > Actually, the kernel of my dreams is more near to the vanilla > kernel.org kernel, so I'd like to be able to throw out patches that > you need to apply because of your _much_ broader user base. Well, then you need detailed knowledge about those patches in any case. (If you know you don't use that code, why bother? The patch won't make a difference for you.) > otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the > distribution kernel because it is still stuck in NEW. http://www.acm.rpi.edu/~dilinger/ > It is adviseable to take a snapshot from the Debian kernel svn? You can use the appopriate SVN tag as well if you like. > And, without trolling, I'd like to build my local kernels from sources > that haven't had drivers removed because of non-free licenses. Disable the purge script in the kernel-source source package. Thiemo
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: > On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: > > Agreed. The package is not a repository for cherrypicking patches > > but intended to used as a whole thing. > > I am pretty disappointed about that attitude towards your users. What > exactly is the problem with a little more docs to _allow_ cherrypicking? It generates work. The time is better used for pushing those patches upstream. Cherrypicking makes little sense, because there are only cherries. :-) Thiemo
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: > Cherrypicking makes little sense, because there are only cherries. :-) For my systems, I care about security holes being fixed, but I do not care about some obscure video hardware, or additional features. So "Cherry" is relative. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: > On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: >> Agreed. The package is not a repository for cherrypicking patches >> but intended to used as a whole thing. > > I am pretty disappointed about that attitude towards your users. What > exactly is the problem with a little more docs to _allow_ cherrypicking? > > Greetings > Marc A large problem with this is that patches in our -source packages assume a certain order. A patch may depend upon another patch; removing one breaks the other. We have this problem when cherry-picking changes from bitkeeper; I'd imagine it gets even worse when you attempt to pick changes from -source packages.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 03:56:48PM -0500, Andres Salomon wrote: > On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: > > On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: > >> Agreed. The package is not a repository for cherrypicking patches > >> but intended to used as a whole thing. > > > > I am pretty disappointed about that attitude towards your users. What > > exactly is the problem with a little more docs to _allow_ cherrypicking? > > > > Greetings > > Marc > > A large problem with this is that patches in our -source packages assume a > certain order. A patch may depend upon another patch; removing one breaks > the other. We have this problem when cherry-picking changes from > bitkeeper; I'd imagine it gets even worse when you attempt to pick changes > from -source packages. Choosing a working patchset would be the responsibility of the picking user, no work on your side involved. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, 09 Jan 2005 19:01:38 +0100, Marc Haber wrote: > Hi, > > A few months ago, I asked on this list for more informative > description of patches enabling non-kernel hackers to choose > individual patchsets for their local kernels. Unfortunately, that > question was denied pretty fast. Looks like you guys don't have time > to write more extensive docs. > > cleanup: Cosmetic change Shouldn't be in Debian kernels. > bugfix: Fixes a bug that might result in errant behavior This applies to pretty much every patch. Even feature additions are usually fixing bugs of the type "machine XYZ doesn't boot!" or "I can't use my network card with your kernel" > crashfix: Fixes a bug that might result in a kernel crash > oopsfix: Fixes a bug that might result in a kernel oops > build: Fixes a build time issue Not worth classifying the differences, imo. Something that might crash one machine might oops on another; it depends on hardware, what the kernel config is, etc. Build problems are the most clear-cut on this list, but I can't imagine why you wouldn't want to include them. There's also warning build fixes, which might be necessary (if the code in question causes an oops/crash), or might simply be to shut the compiler up. > feature: Adds a new feature Aside from non-x86 stuff, we try to avoid these. Some archs need them for basic hardware; in which case, they could easily be considered a bugfix. The general rule is, if it's not needed to boot/install, it should be in a separate kernel-patch package. > maybe-security: Fixes an issue that might pose a security problem Pretty much any bugfix is possibly a security hole that no one's figured out how to exploit yet. This is just another name for "bugfix". > security: Fixes a sure security problem We already try to use this one. > license: Patch accompanying driver removal due to license issues I believe we have exactly 1 patch (tg3-readd) that would be classified as this. That patch needs to go away, as well, as it's a hassle to maintain. > documentation: Documentation patch only I would think this would be easy enough to determine simply by looking at the patch? We don't really have too many of these to begin with. > patchfix: fixes a bug introduced by some other patch When you end up with a large number of patches, this becomes quite an annoyance. > > Architecture-specific tags do not seem to be necessary as architecture > specific patches have the architecture in their file name. > > To locate possible problems with the classification, I have tried to > roughly classify the patches from current 2.6.10 svn: > > x86-i486_emu.dpatch feature > tty-locking-fixes9.dpatch bugfix > sparc64-hme-lockup.dpatch bugfix > sparc32-initrd-memcpy.dpatch bugfix > smbfs-overflow-fixes.dpatch maybe-security > smbfs-overflow-fixes-2.dpatch maybe-security > sec_brk-locked.dpatch security > remove-references-to-removed-drivers.dpatch license > powerpc-serial.dpatch bugfix > powerpc-pegasos-via82cxxx.dpatch bugfix > powerpc-pegasos-2.dpatch feature > powerpc-g4-l2-flush-errata.dpatch bugfix > modular-vesafb.dpatch feature > modular-vesafb-2.dpatch feature > modular-ide.dpatchbugfix > modular-ide-pnp.dpatchfeature > modular-ide-2.dpatch feature > marvell-pegasos.dpatchfeature > ia64-irq-affinity-upfix.dpatchbuild > ia64-generic-no-smp.dpatchbuild > ia64-generic-no-smp-1-to-2.dpatch build > ia64-bte_error-missing-include.dpatch build > fs-asfs.dpatchfeature > fix-mxser-compile.dpatch build > drm-locking-fixes.dpatch crashfix > drivers-scsi_changer.dpatch feature > drivers-net-tg3-readd.dpatch license > drivers-net-8139too-locking.dpatchcrashfix > drivers-input-psaux-hacks.dpatch feature > drivers-ide-dma-blacklist-toshiba.dpatch bugfix > drivers-ide-__devinit.dpatch cleanup > doc-post_halloween.dpatch documentation > alsa-module-load-fix.dpatch crashfix > 032-do_brk_security_fixes.dpatch security > 031-sg_scsi_ioctl_int_overflows.dpatchsecurity > 030-moxa_user_copy_checking.dpatchsecurity > 029-random_poolsize_overflow.dpatch security > 028-do_brk_security_fixes.dpatch security > 027-track_dummy_capability-2.dpatch cleanup This actually fixes 025. It could be considered security, or cleanup, or patchfix. Kind of hard to classify it with o
