[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 necessary.

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  \
  KDEB_PKGVERSION=2.6.39~git+drt110529.2a9e5862  \
  deb-pkg 2>&1  | tee ../build-logs/build-log-2.6.39.1-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!  ;-)


Dave W.


Reply to: