when building the kernel sets and placing gzip'd kernels in binary/kernels.
For example, if KERNEL_SUFFIXES were set to "ecoff srec", then the kernel
set would include:
netbsd
netbsd.ecoff (only if it exists in the kernel compile directory)
netbsd.srec (only if it exists in the kernel compile directory)
This is useful for packaging kernel sets for platforms which have
extra special requirements for loading the kernel.
more consistent. To quote the comment in etc/Makefile
that describes how it's done:
# This target builds the kernels specified by each port. A port may
# specify the following kernels:
#
# KERNEL_SETS The list of kernels that will be
# packaged into sets, named
# kern-${kernel}.tgz. These kernels
# are also placed in the binary/kernels
# area of the release package as
# netbsd-${kernel}.gz.
#
# EXTRA_KERNELS Additional kernels to place in the
# binary/kernels area of the release
# package as netbsd-${kernel}.gz, but
# which are not placed into sets. This
# allows a port to provide e.g. a netbootable
# installation kernel containing a ramdisk.
#
# BUILD_KERNELS Additional kernels to build which are
# not placed into sets nor into the
# binary/kernels area of the release
# package. These are typically kernels
# that are built for inclusion only in
# installation disk/CD-ROM/tape images.
#
the latter being called by the "distribution" target. This allows the
various /etc/... files to be installed manually in a convenient way, if
desired.
NOTE: It is INTENTIONAL that this target is not named "install".
or distribution.
Also, clean up the check and include <sys/endian.h> instead -- some platforms'
<machine/endian_machdep.h> pull in the definitions of _BIG_ENDIAN and
_LITTLE_ENDIAN, invalidating the test; this makes the check values uniformly
"4321" and "1234" respectively.
Shouldn't be needed, but install has no other good way to deal with
this.
Pointed out by Rob Windsor in PR 14394 -- I committed his patch plus
one for something he didn't hit yet.
the etc Makefile override that by putting USETOOLS into $.MAKEOVERRIDES
This way the default for kernel compiles is still to use the installed
toolchain instead of depending on $TOOLDIR. $TOOLDIR can be used by
simply adding USETOOLS=yes to the command line as usual.
Adjust each ports template to set the default no setting and also pull in
bsd.own.mk if they weren't already to ensure they'll build correctly
with the new toolchain setup.
csh: Permission denied
csh: Trying to start from "/var/log"
message.
This was caused by the
su -m uucp -c "uustat -a"
line being executed in a directory not readable by uucp. The login
shell implied by -m is of course root's shell, /bin/csh, which doesn't
like not being able to read the dir it is in, and thus the errors. By
temporarily cd'ing to /tmp the problem is fixed.
What is really needed, of course, is a way to tell su what shell you
want to use explicitly, especially for use in scripts where the
vagaries of which shell the login executing the script uses should not
be depended on. No such method exists. One should be added.
Indeed, it might also be nice to have a way of telling su to directly
execute a command with -c rather than using a shell to interpret the
command.
I cannot find any standards documents that specify su at the moment,
though. SuSv2 is silent on su(8).
lukem