Subject: Re: how to get kernel sources for i386 20020104-1.5ZA
To: Marshall Rose <mrose@dbc.mtview.ca.us>
From: Robert Elz <kre@munnari.OZ.AU>
List: port-i386
Date: 02/25/2002 19:57:01
    Date:        Sun, 24 Feb 2002 11:38:18 -0800
    From:        Marshall Rose <mrose@dbc.mtview.ca.us>
    Message-ID:  <20020224113818.1fd7644d.mrose@dbc.mtview.ca.us>

  | "fine, it's stable enough, now get the kernel source so you can debug
  | the audio problems, and that's how we got here.

What I generally do when installing a snapshot is simply fetch the latest
NetBSD-current sources (unless for some reason the snapshot is a real old one,
but then my solution is generally not to bother, but just wait for someone
to be kind enough to make a new one).

There's nothing more irritating than to be bitten by some bug that was fixed
a couple of days after the snapshot was built - unless it is perhaps wasting
a bunch of time tracking down the bug and fixing it yourself.

That is, I build a new kernel from -current sources, and just ignore whatever
was supplied with the snapshot (if that doesn't work today, it will do
within a couple of days).   The rest of the sources I just keep usually,
and compile individually if it looks like anything requires it (before
bug hunting).

This is pretty much what you did I think - you just got bitten by the
current non-intuitive build environment, which (even though you have all the
relevant binaries installed) requires you to have a full source tree
before you can compile anything in the source tree, and to have gone and
built the tools (so you now have two copies).  Or that you know the magic
to disable it (which is mostly knowing that there actually is magic to
disable it - knowing that, finding it isn't impossible).   Eventually,
enough people will complain about this that I think it very likely that the
build system will switch back so that if you just say "make" in some
random source directory, it will use the normal installed tools from /usr/bin
instead of the alternate toolchain.   This might depend upon the system
actually having gcc 2.95.3 as its installed toolchain (or perhaps having
the same one as the tools would install) - and so might not happen until
a large subset of users has upgraded (and so isn't likely until after 1.6
is released probably).

kre