Re: 2.6.36, make oldconfig broken

[Ken Moffat <zarniwhoop@ntlworld.com>]

On Fri, Oct 22, 2010 at 08:54:51PM -0400, Gene Heskett wrote:
> 
> It hasn't been edited since I ran it, so I'll attach it.  Maybe you can see 
> something I missed.
> 
Hi Gene,

 I don't see anything that is immediately wrong (but, it's late and
I'll be going to bed as soon as webkit has finished compiling on my
desktop, so my concentration might be lacking), but it does seem
overly complex.  I've long since given up trying to script kernel
builds, it mostly isn't necessary if you aren't creating a distro.

 I appreciate your comment about fingers - mine are mostly ok, but
prone to operating in the wrong order so that I often generate typos
such as 'teh'.  What works for me is -

1. build in ~/ : I often have current and "previous, but still
usable" systems on the same machine, and I share /home between them.
Arguably, building as a user may prevent some disastrous actions,
but backups are always useful - I remember your past comments about
using amanda so I'm sure you've already got that covered.

2. for each kernel version of interest (typically, current and next
- over time the old one drops out and a new one rolls in) :
 create a first version (untar, or untar and patch).
 I then rename it to 2.6.xx-stable or 2.6.xx-rc.

 For the patches I use
bzcat /path/to/patch-2.6.whatever.bz2 | patch -p1
(yes, send me tickets for "useless uses of cat" if you wish ;)

3. When I want to test a new -rc, or a release has come out, cd into
the tree and
 head Makefile
to confirm which (-rc) patch was last applied.
revert that: bzcat /path/to/that-patch.bz2 | patch -p1 -R
apply the new one

and then just make oldconfig and continue (or, for the first rc of a
new version, zcat /proc/config.gz >.config && make oldconfig.

 To keep track of errant fingers, you can read the commandline
before hitting <enter>, you can also run 'make modules_install' as a
user - it won't work, but it will confirm which version it is trying
to install.

 Sorry if this comes across as trying to teach you things you
already know, but the process should be simple enough to not need
scripting!  Of course, my video hardware doesn't need out-of-tree
firmware nor other drivers.  Perhaps in that situation I might try
to script it all.  From painful experience, the usual problem with
scripts is a failure to detect errors or unexpected results.  Keep
things simple if you can.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce