This commit is intended to makes the license status of Emulab and
ProtoGENI source files more clear.  It replaces license symbols like
"EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
blocks that contain actual license statements.

This change was driven by the fact that today, most people acquire and
track Emulab and ProtoGENI sources via git.

Before the Emulab source code was kept in git, the Flux Research Group
at the University of Utah would roll distributions by making tar
files.  As part of that process, the Flux Group would replace the
license symbols in the source files with actual license statements.

When the Flux Group moved to git, people outside of the group started
to see the source files with the "unexpanded" symbols.  This meant
that people acquired source files without actual license statements in
them.  All the relevant files had Utah *copyright* statements in them,
but without the expanded *license* statements, the licensing status of
the source files was unclear.

This commit is intended to clear up that confusion.

Most Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the Affero GNU General Public License, version 3
(AGPLv3).

Most Utah-copyrighted files related to ProtoGENI are distributed under
the terms of the GENI Public License, which is a BSD-like open-source
license.

Some Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the GNU Lesser General Public License, version 2.1
(LGPL).

clientside requres it to be there. As noted in previous revision, the
full emulab build always includes the clientside subdir, but a
clientside build will not necessarily include the rest of Emulab.

thankless job but someone has to do it. I'm expecting to finish by the
time Bush 43 leaves office.

stuff into the library since we do that in many places.

between when something is installed and when post-install runs. Short
of a global lock (which we probably need anyway someday), my solution
is this. In your makefiles, add these variables before the line that
has the include of $(TESTBED_SRCDIR)/GNUmakerules:

	SETUID_BIN_SCRIPTS   =
	SETUID_SBIN_SCRIPTS  =

I have added three new rules to GNUmakerules that look like this:

	$(addprefix $(SBINDIR)/, $(SETUID_SBIN_SCRIPTS)): $(SBINDIR)/%: %
		echo "Installing (setuid) $<"
		-mkdir -p $(INSTALL_SBINDIR)
		$(SUDO) $(INSTALL) -o root -m 4755 $< $@

Yep, your eyes ain't lying to you; use sudo to run the target so that
install does the right thing (which is that the old file is not
replaced until the new one has the proper attributes on it).

Note that post-install is still needed for the initial install, but
should no longer be needed for day to day installs since all that other
stuff post-install does is mkdir/chmod on directories.

weren't really affecting anything).

  * xdr_sizeof.c: This was removed from the FreeBSD rpc lib around
      RELENG_5_1; so, to make robots stuff compile again on new ops/boss,
      I'm including this file from RELENG_6_1.

Add prototypes to make perl 5.8 happy

able to be directly reused in the continuous motion modifications to the
tracker.

integer.

camera, as well as its width, height, and fps. Tack these params onto
the robotrack URL:

	&camwidth=640&camheight=480&fps=2&camera=1

where camera is 0, 1, or 2 ... Dave can figure out which one he needs.
The allowed camera sizes are:

  640x480, 640x360, 480x360, 384x288, 352x288, 352x240, 320x240, 240x180

as defined by the axis HTTP API.

forthcoming ...

color configs; also handle more total fiducials per camera (limit had been
6 -- too low with checker fiducials added).  Also add offset information
for vmc-client configs.

option to mtp_dispatch.

avoidance to work correctly.

starting pilot seemed to cause problems.

To use the 'B' posture regulator, define USE_POSTREG_B in masterController.c

between the current frame and the last.  Need to also check that the
minimum distance is the same between the last and current, otherwise
ordering of the tracks in the list matters (doh).

transitioning cameras a higher speeds.

command-wheels to the list of message types.

 * brainstem-reset.cc: comments.

is reset, then the GP (it seems that the GP acts as the I2C router... so
moto has to be reset first -- this may not be true, not sure yet).  Reset
can be toggled in pilot by sending a USR2 to the pilot process.  If reset
is sent while robot is executing any sort of move, the only way to recover
is to kill pilot.  Reset can be toggled whenever the robot is not moving
without consequence (obviously, brainstem state (including wheel odometry)
is lost).  There is also a separate reset command (brainstem-reset) that
works independently.  This command is now called in the pilot-wrapper.sh
script before pilot is (re)started.

  * GNUmakefile.in: new target `brainstem-reset'.

  * garcia-pilot.cc: not much.

  * garciaUtil.cc: the brainstem_reset function.

  * garciaUtil.hh: prototypes...

  * pilot-wrapper.sh: call brainstem-reset (NOTE: this always fails the
    first time, and I'm not sure why.  It always succeeds subsequently...
    so it makes no difference at the moment).

  * brainstem-reset.cc: new command to reset the brainstem modules.