On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote: > Hi guys, > > this is basically a re-hash of > http://blog.zugschlus.de/archives/231-Thoughts-about-the-Debian-kernel.html, > which I published on my blog on sunday. Since the article received > less response than I originally expected, I would like to solicit your > opinions and answers in a more direct way.
Sorry, I don't read your blog. This list is a pretty good place for debian-kernel discussions :) > I am one of the guys who builds Linux kernels locally, from vanilla > sources. What I don't like in this approach is that I do not get the > distribution patches and might miss one of the kernel security > patches, since I am way too busy to keep track of LKML any more. > otoh, I am kind of a version number junkie when it comes to the > kernel, so the Debian kernel sources even in sid frequently are not > current enough. So, what I want to have is a compromise between a > vanilla kernel and the Debian distribution kernels, built in a way > that the images integrate well with Debian. > > This message contains a few questions and wishes directed towards the > Debian kernel team which I failed to get addressed on #debian-kernel > and on the blog. > > * The build process is not very transparent > * Documentation in the README files seems quite incomplete The build process is something that is being worked on very heavily. So yes there is ample room for improvement. And one area that is particularly lacking is documenation. Contributions in that area would be greatly welcomed. > * In my opinion, answers to these questions are missing: > * Which steps happen in which order (prose)? I'm not entirely sure what you mean. apt-get source linux-2.6 cd linux-2.6 dpkg-buildpackage -rfakeroot -us -uc -B ... One caveat, is that if you play with stuff before running dpkg-buildpackage, which I guess you would else you won't be here, then debian/control probably needs to be regenerated. If you just run dpkg-buildpackage as above, it will fail, telling you that it re-generated debian/control. Confusingly, this is ok. Just re-run dpkg-buildpackage. If it fails again, then you are in trouble. If, like me, this troubles you, run rm -f debian/control ./debian/rules debian/control N.B: This requires python > * Are there any hooks to interfere with the build process? No > * How to keep patches from being applied? The best thing would be to create a series file as discussed immediately below (sorry, I'm answering this email backwards for no apparent reason). And remove the patches e.g: say you don't like amd64-int3-fix.patch cat << __EOF__ >> debian/series/2.6.13-12hls.1 - amd64-int3-fix.patch __EOF__ This will make sure that amd64-int3-fix.patch is unapplied when you build version 2.6.13-12hls.1 or greater of the package. It will still be there in earlier versions as dictated by other series files. > * How to add local patches? There are several ways. Add a patch package, which you asked about below. If you just want to dd a few patches, put them in debian/patches-debian. Create a file in debian/patches-debian/series, that's name is the debian version you are going to build, and add the patches to that file, one per line, prefixed by "+ ". For example: cp /tmp/a.patch debian/patches-debian cp /tmp/b.patch debian/patches-debian cat << __EOF__ >> debian/series/2.6.13-12hls.1 + a.patch + b.patch __EOF__ When version 2.6.13-12hls.1 or greater of the package gets built these patches will be applied. They will also be included in the linux-patch package. Just note that the patch filenames must end in .patch > * Is there anything like dpatch-edit-patch for the > (home-grown?) patch system in the Debian kernel source package? I'm not sure what that is, but probably not. Could you elaborate? > * How do I control generation of the > kernel-image-2.x-<flavour>_2.x.y-z_<arch>.deb helper packages? > They do not seem to be controlled by debian/arch/<arch>/defines > as the real kernel debs do. What about them do you want to control? They should only be created for flavours that exist. If you want to get rid of them entirely, look in debian/templates/ > * Can I have patches from a kernel-patch-foo Package automatically > applied for certain flavours? If you are talking about linux-2.6, then no, not realy. But if you invoke make-kpkg directly, then it has a facility to pre-patch the kernel. > * Are there hooks for building external modules? No > * Are there debian/rules parameters or environment variables to > select only a certain kernel to be built (like for debugging > problems)? No. If you are talking about linux-2.6, then edit debian/arch/$ARCH/defines. Near the top is a list of flavours that will be built. Remove the ones you don't want, and then run rm -f debian/control ./debian/rules debian/control Clearly there is room for improvement here. > * Can build of helper packages (-headers, -doc, -patch, -source, > -tree) be disabled? If you do a binary only build of the kernel package, then most of those should not be built. If you use make-kpkg directly you can get finner control. > * For local kernel builds, should one use the Debian kernel build > system, or continue to use make-kpkg as it was usual previously? > * there is nothing like a kernel HOWTO Isn't that the role of the Kernel Handbook? > * The Kernel Handbook needs to be fleshed out in these regards. I > might want to contribute once I have accumulated the knowledge needed > to write the passages. > * Patches like, for example, amd64-int3-fix need to be better commented One thing that I think we are getting better about is recording information about what patches do. But this isn't perfect and information is oftem missing. If you're worried about a specific patch, as you seem to be, then this list is a great place to ask. I've answered the questions I know the answers to below, hopefully someone can fill in the gaps. > * I think it is necessary that a patch file contains information > * what does the patch do? > * why is it applied? > * is it necessary only on certain archs? Yes, thats why it says amd64. Its applied to all arches, but it only affects amd64. > * is it necessary only if certain drivers are in use? Its a part of kprobes, so it probably affects many areas of the kernel. > * what does happen when it is omitted? > * is it security relevant? > * CAN/CVE number, if applicable. Security bugs are usually taged as such in the changelog. Unfortunately this patch does not have a changlog entry, which it should. However, I would guess that if it was security related then it would have a been documented more thoroughly. In any case, I agree this patch is underdocumented, and I'd like to get that fixed. > * Which role does module-assistant play here? > * If one builds kernels with make-kpkg, should one make use of make-kpkg > also build the modules, or should one use module-assistant instead? That I am also unsure about. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
