Fix a bug in the EncodeDecodeOpenprs.c template which would screw up a
test (a trailing ; in a test).

Make sure to pass all variables defining the proper python version as found by
robotpkg, otherwise ros CMakeFiles may happily find python-3.2 and use it
instead of python<3, although this does not work in the end (at least ros-rx
does this and breaks on F17).

This is done in the common ros Makefile as this affects all packages.

This template produces encoding and decoding functions in a module
(which can be loaded by an Openprs kernel), as well as basic OPs to
have OpenPRS to be a client of a genom3 module (using the
{ros,pocolibs}/client/c library.

tcl-genomix package provides a TCL package that interacts with the genomix HTTP
server and can control GenoM3 components.

It can prompt interactively for arguments of services. Services can be invoked
synchronously or asynchronously and callbacks can be triggered whenever
services complete.

tcl-genomix is best used in combination with the interactive eltclsh shell.

The genomix HTTP server is a generic interface between clients and genom
components (using the generic genom C client template). Control is done be the
mean of specific HTTP GET requests (not yet documented...).

The genom3-ros template (see meta-pkgs/ros-base) provides a GenoM3
template for generating ros-based components.

The genom3-pocolibs template (see middleware/pocolibs) provides a GenoM3
template for generating pocolibs-based components.

The Generator of Modules GenoM is a tool to design real-time software
architectures. It encapsulates software functions inside independent
components. GenoM is more specifically dedicated to complex on-board systems,
such as autonomous mobile robots or satellites, that require:

. The integration of heterogeneous functions with different real-time
  constraints and algorithm complexities (control of sensors and actuators,
  data processings, task planification, etc.).

. An homogeneous integration of these functions in a control architecture which
  requires coherent and predictable behaviors (starting, ending, error
  handling), and standard interfaces (configuration, control flow, data
  flow).

. The management of parallelization, physical distribution and portability of
  the functions.

. Simple procedures to add, modify or (re)use the functions by non-specialists

GenoM generates the source code of components by using:

. A generic template, common for all components. This guarantees that all
  components share the same consistent behaviour. The template itself is not
  part of GenoM, so that different template kind can be developped easily.

. A formal description of the components interface. This description is based
  on a simple language using OMG IDL for data types definitions and a custom
  syntax for the description of a more detailed component model.

The project is released under an open-source, BSD-like license.

Correspond to 4447255a1 in upstream.
Bump PKGREVISION

Fix actionlib/script/genaction.py that was using harcoded "python" interpreter.

- Add missing dependency on log4cxx + boost headers for rosout
- Fix build with boost>=1.50

The rx stack contains GUI-related tools for using ROS, including:

 . rxbag: ROS bag recording, playback and visualization

 . rxgraph: ROS graph visualization

 . rxplot: ROS topic data visualization

 . rxconsole: ROS/rosout logging output

Install .msg files generated from .action under the correct path.

actionlib generated messages are in "build" directory. Without the patch, the
cmake rules for message generation would install those generated .msg under a
wrong path.

Simply add an optional parameter to add_message_file() and add_service_file()
that allows to specify both the source and destination dir of input files,
instead of considering they are the same. This is only used by actionlib and
has no side effect on other packages.

The actionlib package provides a standardized interface for interfacing with
preemptible tasks. Examples of this include moving the base to a target
location, performing a laser scan and returning the resulting point cloud,
detecting the handle of a door, etc.

In any large ROS based system, there are cases when someone would like to send
a request to a node to perform some task, and also receive a reply to the
request. This can currently be achieved via ROS services.

In some cases, however, if the service takes a long time to execute, the user
might want the ability to cancel the request during execution or get periodic
feedback about how the request is progressing. The actionlib package provides
tools to create servers that execute long-running goals that can be
preempted. It also provides a client interface in order to send requests to the
server.

common_msgs contains messages that are widely used by other ROS packages. These
includes messages for actions (actionlib_msgs), diagnostics (diagnostic_msgs),
geometric primitives (geometry_msgs), robot navigation (nav_msgs), and common
sensors (sensor_msgs), such as laser range finders, cameras, point clouds.

The ros_comm stack contains the ROS middleware/communications packages. This
packages are collectively known as the ROS "Graph" layer. They provide
implementations and tools for topics, nodes, services, and parameters. This
includes the supported ROS client libraries: roscpp, rospy, and roslisp.

Some ros python packages require py-setuptools instead of using vanilla
distutils. This has the side effect of installing so called EGG_INFO
directories that behave differently depending on the platform (sometimes the
directory is zipped, sometimes not). The PLIST may then be broken.

Instead of fighting with this, just use distutils instead of setuptools since
setuptools does not bring anything useful in robotpkg (does it?). This is done
via a SUBST stage in setup.py for packages that declare using it.

Affected packages are, so far:
 - ros-gencpp
 - ros-genlisp
 - ros-genpy

Factor out the following:
 - PKGNAME with ros- prefix. This is overrided for a few base pkgs only
 - MAINTAINER
 - LICENSE

These can still be overriden on a per pkg basis.

std_msgs contains common message types representing primitive data types and
other basic message constructs, such as multiarrays. For common, generic
robot-specific message types, please see common_msgs.

std_msgs contains wrappers for ROS primitive types, which are documented in the
msg specification. It also contains the Empty type, which is useful for sending
an empty signal.

This package also contains the "MultiArray" types, which can be useful for
storing sensor data.

Meta package modeling the build-time dependencies for language bindings of
messages in ROS.

Meta package modeling the build-time dependencies for language bindings of
messages in ROS.

Lisp code generator for ros .msg and .srv files

python code generator for ROS .srv and .msg files

C++ code generator for ROS .msg and .srv files

Project genmsg exists in order to decouple code generation from ROS .msg & .srv
format files from the parsing of these files and from impementation details of
the build system (project directory layout, existence or nonexistence of
utilities like rospack, values of environment variables such as
ROS_PACKAGE_PATH): i.e. none of these are required to be set in any particular
way.

This module provides a simple interface to record some trajectory and
then replay it.

The CmakeFile of catkin is able to find either the standalone script, or the
python package. It looks like catkin is happy with both.