On Fri, 19 Oct 2001, Luke Mewburn wrote:

> On Thu, Oct 18, 2001 at 12:28:31PM -0500, Frederick Bruckman wrote:
> > Would anyone object if I change the "send-pr" Makefile to put the (build
> > time) result of `uname -r` into the "send-pr" script itself?

> 1. With the current method, we get DEFAULT_RELEASE from
>    gnu/usr.bin/send-pr/Makefile, which is "<NetBSD current source date>"
>    for -current, and a more specific version for a release.

Evidently, that's difficult for releng to keep up with! 3 PR's have
been filed for the same thing (DEFAULT_RELEASE in send-pr 1.5.2 says
"NetBSD 1.5.1"), and I sent an email to releng -- no response. The fix
suggested in PR 14217 is a laudable effort to make this maintenance
free in the future.

> 2. With `uname -r` at run-time, we get the kernel version of the running
>    kernel, which might be newer than userland.

> 3. With `uname -r` at build time, we get the kernel version from that
>    time of build. At best this reflects the status of the send-pr
>    build.

For the normal case, where you "cvs update" the sources, then upgrade
the kernel, then upgrade userland, it doesn't matter...

>    Also suggesting `ident foo` output for a program (and possibly
>    that of any referenced shared libraries - a tool which uses
>    file(1), ldd(1), and ident(1) would be useful here) could be of
>    assistance.

I thought of the former, but I couldn't think of a message that fits
the pattern (one-line and concise).

> Out of these, I'd argue for `2.' as the solution.  (Running system
> `uname -r`, update the send-pr prompts to remind people about
> kernel<->userland version skew)

OK. I realize now, the bad thing about `3', is that it would do
entirely the wrong thing for cross-builds.

I also thought of getting __NetBSD_Version__ out of <sys/param.h> and
massaging it, but that's complicated, and it still fails if the kernel
and userland are out of sync.

> (As a medium term project, we should ensure that we provide full
> CVS version strings in kernel source files. I compile with full
> debugging symbols (both kernel and userland), and for my kernels
> I only get CVS ids for ipfilter, some wscons stuff, and one audio
> driver. Something's not right there (IMHO)...)

I guess that means adding

#include <sys/cdefs.h>
__KERNEL_RCSID(0, "$NetBSD$");

to lots and lots of files in syssrc?

Frederick