Re: 3.0 kernel fails to compile
On 08/02/2011 04:50 AM, Stan Hoeppner wrote:
On 8/1/2011 9:44 PM, Dave Witbrodt wrote:
I was a long-time user of make-kpkg, but since I learned how to use the
in-kernel deb-pkg target I have been taking the Debian Kernel Team's
advice and recommending building custom kernels that way.
As was I. One downside (depending on how you look at it) IIRC the
make..deb-pkg method doesn't pay attention to CONCURRENCY_LEVEL. First
run took about twice as long as make-kpkg. Specifying -j2 fixes it, but
the whole point of environment variables is so you don't have to. A
dtep backwards here IMO.
I also had some personal adjustments to make. I made the switch around
the same time that I moved from the old GRUB to the new one, and I did
not like the order that my installed kernels were being displayed in the
GRUB menu at boot; I also found that initrd images were being built for
my custom kernels, but I configure my kernels so that no initrd is
Solving the GRUB menu and initrd issues required some intervention with
custom hacks, but frankly I don't consider the loss of the
CONCURRENCY_LEVEL variable to be a serious problem. This is because of
the versioning I use with my custom kernels to distinguish them from
those provided by the Debian Kernel Team.
For example, to build with 5 concurrent processes (# of CPU cores + 1);
modify the kernel's Makefile setting for EXTRAVERSION to reflect that
this is a local kernel (and not a Debian kernel); record the date and
git commit ID of the last patch I cherry-picked from drm-radeon-testing;
and save all output in a log file in case I want a close look at how the
build went, I run 'make' something like this:
make -j 5 EXTRAVERSION=.1-3dwlocal \
deb-pkg 2>&1 | tee ../build-logs/build-log-18.104.22.168-3dwlocal.txt
I add the "dwlocal" suffix in EXTRAVERSION so that I can hack
'/etc/kernel/postinst.d/initramfs-tools' to look for it and _not_ build
an initrd for a kernel with that string in its name. Other (normal)
people build custom kernels with initrd's, so they do not need to jump
through these hoops.
If you are really devoted to CONCURRENCY_LEVEL so much, why don't you
leave it in your environment and write a script (or a bash alias) to
automatically use it for your custom kernel builds?
make -j $CONCURRENCY_LEVEL deb-pkg
You could even call the script or alias 'make-kpkg' if you want! ;-)