Re: Building local kernels from Debian sources
On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote:
> 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.
the comments show a funny public you reached.
> 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.
then use latest stable.
the addition of this tree helped a lot in the maintenance of the debian
kernel. chris wright and greg kroah-hartman do a fantastic job.
> 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
> * In my opinion, answers to these questions are missing:
> * Which steps happen in which order (prose)?
README.build in svn??
> * Are there any hooks to interfere with the build process?
> * How to keep patches from being applied?
naah, you were already told:
take it as whole or forget about it.
> * How to add local patches?
just add them to the debian-patches dir and the latest series file.
or like m68k and hppa that still use big sepperate patches in
patches-arch. we hope that will evolve as more and more bits land upstream.
> * Is there anything like dpatch-edit-patch for the
> (home-grown?) patch system in the Debian kernel source package?
no.
dpatch was never used afair.
> * 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.
-> debian/templates/control.extra.in
> * Can I have patches from a kernel-patch-foo Package automatically
> applied for certain flavours?
> * Are there hooks for building external modules?
> * Are there debian/rules parameters or environment variables to
> select only a certain kernel to be built (like for debugging
> problems)?
> * Can build of helper packages (-headers, -doc, -patch, -source,
> -tree) be disabled?
> * 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
> * 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.
cool.
> * Patches like, for example, amd64-int3-fix need to be better commented
> * 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?
> * is it necessary only if certain drivers are in use?
> * what does happen when it is omitted?
> * is it security relevant?
> * CAN/CVE number, if applicable.
naah the last fits into changelog.
dont poke with the patches themself.
--
maks
Reply to: