Re: Building local kernels from Debian sources
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
Reply to: