Re: Building local kernels from Debian sources
On Fri, Oct 28, 2005 at 10:43:55AM +0900, Horms wrote:
> On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote:
> > 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.
The build is a lot of make magic, something I am not very familiar
with. And it is hard for me to fine a starting point for investigation.
> > * 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 ...
That is too easy ;)
> One caveat, is that if you play with stuff before running
> dpkg-buildpackage, which I guess you would else you won't be
> here,
That guess seems to be correct. In particular, I'd like only three
flavors of the kernel to be built, all of them for i386, but with my
own .config file.
> 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.
I see.
> If, like me, this troubles you, run
>
> rm -f debian/control
> ./debian/rules debian/control
Thanks.
> N.B: This requires python
*urgs*
> > * Are there any hooks to interfere with the build process?
>
> No
Too bad.
> > * 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.
That sounds pretty neat. Looks like all I need is to learn what a
patch does and how it is classified by the one who applied it.
> > * 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.
Great. I think I understand how things work. Thanks!
> 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?
dpatch-edit-patch is a tool from the dpatch package which will make a
snapshot of the current sources (which might be inappropriate for a
package as large as the kernel), drop you into a shell where you can
make your modifications. After that shell has exited, your local
working copy will be diffed against the snapshot made beforehand,
resulting in a patch file which represents your changes.
> > * 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?
I would probably like to disable their generation.
> They should only be created
> for flavours that exist. If you want to get rid of them entirely,
> look in debian/templates/
Thanks, will do.
> > * 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.
Yes, but I am planning to move away from my own mechanism built around
make-kpkg and towards your build system since it seems to be much
better maintained than my local stuff.
> > * Are there hooks for building external modules?
>
> No
Too bad.
> > * 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
Thanks.
> Clearly there is room for improvement here.
Yes, but that could easily be scripted once the mechanisms have been
understood. And your message has moved me a great deal towards
understanding, I really appreciate that.
> > * 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?
Surely in a future version the kernel handbook can do so. Back in
October, it didn't, and I must admit not having looked at the current
versions.
> > * 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.
I surely hope so ;)
> 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 am not currently worried about a specific patch, but worries will
come up sooner or later, and in the start phase, I would ask a _lot_
of questions. Besides, the docs belong in the patch file, not in the
list archive.
I only took the amd64-int3-fix as an arbitrary example though. I
proably chose it because it was particularly badly documented.
> I've answered the questions I know the answers to below,
> hopefully someone can fill in the gaps.
Thank you very much.
> > * 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.
Would that be true for all patches with names starting with an arch
name?
> > * 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.
I would _love_ to have that fixed for all patches applied by Debian
sources. It will also help users to communicated with kernel upstream
directly because kernel upstream is likely to barf when one approaches
them with problems with a distribution kernel. If I know which patches
are applied, I can say with a good conscience whether patches applied
might affect the module in question.
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
Reply to: