In the tf recipe, this commit adjusts the license-file line and
drops the upstream-accepted patch due to update.
With the update of eigen-conversions and tf-conversions,
the compilation of both packages fails with:
```
| [...]: fatal error: Eigen/Core: No such file or directory
| #include <Eigen/Core>
| ^~~~~~~~~~~~
| compilation terminated.
```
It fails as the upstream development uses the Eigen3 CMake
find script instead of the ROS cmake_modules find script,
and the Eigen3 CMake find script does not work in the current
openembedded-core and meta-openembedded setup (cf. #501).
Hence, this commit applies a patch to revert the CMakeLists.txt
to use ROS cmake_modules to find Eigen. This patch must be applied
until issue #501 is resolved in the upstream development.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
In builds with recent commits of openembedded-core,
`bitbake velodyne-driver` fails in do_package_qa with:
```
ERROR: velodyne-driver-1.2.0-r0 do_package_qa: QA Issue: /opt/ros/indigo/lib/velodyne_driver/vdump contained in package velodyne-driver requires /bin/bash, but no providers found in RDEPENDS_velodyne-driver? [file-rdeps]
```
In the past, the QA issue was only a warning and considered of low
priority. Now that it raises an error, it must be addressed.
Hence, this commit resolves the issue.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
This commit also drops the patch that has been included in the
updated version, and adjusts to new directory structure in the
archive of the updated version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit drops the patch for gscam that has
been included in the current upstream version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit drops the patch for smach-ros that
has been included in the current upstream version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit drops the patch for ecl-containers
that has been included in the current upstream version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
The recipes collada-parser, collada-urdf and kdl-parser have been
moved to new repositories and are further developed there. This
commit updates the recipes to the current versions in the new
repositories. Furthermore, it adds the new recipe kdl-parser-py,
but this recipe is still deactivated in packagegroup-ros-world, as
python-orocos-kdl is not yet properly building.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
This commit also updates the license file checksum, and patches
CMakeLists.txt to build properly when testing with catkin is
switched off.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit drops the two previous patches that
are now included in the upstream development. For depth-image-proc,
the commit provides a patch to properly find Eigen. For image-proc,
the commit adjusts the dependencies and tunes its formatting.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
While improving ros-mavlink, this commit also moves the
pre-existing patch to the more common directory for patches.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
The script environment_cache.py generates a cache file that
sets LD_LIBRARY_PATH so that the paths to target libs
go first. This confuses native python3 which dynamically links
to the target libpython3 and that leads to wrong linking
of dynamic python modules:
04:09:43 | [ 16%] Generating Python from MSG std_msgs/Float32
04:09:43 | catkin_generated/env_cached.sh /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot-native/usr/bin/python3-native/python3 /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/share/genpy/cmake/../../../lib/genpy/genmsg_py.py /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/std_msgs-0.5.10/msg/Float32.msg -Istd_msgs:/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/std_msgs-0.5.10/msg -p std_msgs -o /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/build/devel/lib/python3.5/site-packages/std_msgs/msg
04:09:43 | Traceback (most recent call last):
04:09:43 | File "/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/share/genpy/cmake/../../../lib/genpy/genmsg_py.py", line 44, in <module>
04:09:43 | import genpy.generator
04:09:43 | File "/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/lib/python3.5/site-packages/genpy/__init__.py", line 34, in <module>
04:09:43 | from . message import Message, SerializationError, DeserializationError, MessageException, struct_I
04:09:43 | File "/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/lib/python3.5/site-packages/genpy/message.py", line 40, in <module>
04:09:43 | import math
04:09:43 | ImportError: /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot-native/usr/lib/python3.5/lib-dynload/math.cpython-35m-x86_64-linux-gnu.so: undefined symbol: _Py_dg_stdnan
Don't put LD_LIBRARY_PATH to the cache, but use the value provided
by bitbake.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
If python2 is available in build environment then according to
PEP-394 python should reference python2. But in case of building
a python3 flavor of meta-ros PYTHONPATH is set explicitly to
python3 libraries. When python2 is called with PYTHONPATH
pointing to python3 libs the following error triggers:
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
This patch makes the dynamic reconfigurations call python3
explicitly in case a python3 flavor of meta-ros is being
built.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
With these improved build dependencies, the image-view recipe
configures successfully. However, compiling fails due to not
finding the gtk headers.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
The commit adjusts the line number of the license check due to
the update. Due to the manual inspection, this commit also tunes
the description to a short description.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
The package can't be built with python2 bindings since
libboost_python.so (which the bindings depend on) has been
disabled in Boost in OE upstream. Only python3 configuration
is supported nowadays.
Disable support for python2 in camera_calibration_parsers.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
python2 bindings for Boost got disabled in OE upstream, so
disable python2 support in cv-bridge that depends on them.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
By default meta-ros uses python2. In case you want to get
python3-compatible builds add the following line to your local.conf:
ROS_USE_PYTHON3 = "yes"
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
The added patch makes resource-retriever compatible with python3.
Also drop python-urlgrabber which resource-retriever used to
depend on.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
It's enough to have python-empy-native in the build dependencies
of catkin and catkin-runtime. If we ever support on target
development then python-empy should be better added to
catkin's run-time dependencies.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
ROS integration for uArm robots fails to work properly without
geometry-msgs installed which sensor-msgs depends on.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
As the page https://github.com/ros-planning/shape_tools suggests
the package shape-tools is deprecated in favor of geometric-shapes and
the latter doesn't really depend on the former and builds successfully
without shape-tools in its builddeps.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Particularly this commit brings in
* moveit_core;
* moveit_ros_perception;
* moveit_ros_planning;
* moveit_msgs
and their build dependencies like
* object_recognition_msgs;
* srdfdom.
Also they are included into packagegroup-ros-world.bb.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Due to the update, this commit also drops the urdf patch, which is
now included in the released version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to this update, this commit also drops the rosconsole patch,
which is now included in the released version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit also drops the urdf patch, which is
now included in the released version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit drops the patch that is not
needed anymore. A slightly different patch has been merged.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit also drops both patches that are
now included in the released version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the uodate, this commit also adjusts the LIC_FILES_CHKSUM
line to the recent change in package.xml.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
libeigen is an interface dependency needed by orocos-kdl and
orocos-kdl does export this dependency, but it does so with
a hardcoded absolute path pointing to the sysroot where
orocos-kdl was built. In case the sysroot doesn't exist
the compiler can't find libeigen's headers.
Unfortunately orocos-kdl's CMakeList.txt doesn't use
per-target include dirs, but global ones. I don't know
an easy way how to make them relocatable.
The easiest way to fix it is to add the explicit dependency
on libeigen to kdl-parser's CMakeList.txt. Anyway it's already
been declarated as a dependency in kdl-parser's recipe.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
If a package (A) depends on another package (B) and the package
B depends on Boost then it might happen that B produces BConfig.cmake
file where absolute paths to Boost's headers are put (because CMake's
standard FindBoost.cmake module reports absolute paths). In case of
Yocto it means that BConfig.cmake will contain something like
/path/to/build/tmp-glibc/work/i586/package_B/0.0.1/recipe-sysroot/usr/include.
The path may not exist at the moment when the package A is being built.
And that leads to the failure of the check this patch switches off.
The problem has been reported to catkin's issue tracker:
https://github.com/ros/catkin/issues/851
This patch "relocates" required headers from dependencies' sysroots
to the current sysroot by removing sysroot prefix from include dirs
in *Config.cmake files at the moment the files get created and
by prepending the include dirs again with the current sysroot prefix.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Octomap has been updated to provide relocatable libraries. Now
it's not needed to tweak the absolute paths to Octomap's
binaries.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Since the Octomap package provides CMake configs suitable for
cross-compilation there's no need for an external module
in cmake-modules.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Also backport a patch improving generation of config.cmake
files. This makes octomap libraries relocatable which is
required for successful cross-compilation builds.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Without the dependency on cmake-modules, `bitbake pcl-conversions` can
possibly fail with:
```
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
| Could not find a package configuration file provided by "cmake_modules"
| with any of the following names:
|
| cmake_modulesConfig.cmake
| cmake_modules-config.cmake
|
| Add the installation prefix of "cmake_modules" to CMAKE_PREFIX_PATH or set
| "cmake_modules_DIR" to a directory containing one of the above files. If
| "cmake_modules" provides a separate development package or SDK, be sure it
| has been installed.
| Call Stack (most recent call first):
| CMakeLists.txt:4 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```
The failure only occurs if cmake-modules has not been installed
before pcl-conversions is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`,
which builds many packages in parallel, did not
uncover this because cmake-modules was usually installed before
pcl-conversions was configured.
However, the issue is clearly reproducable with
`bitbake pcl-conversions cmake-modules -c cleanall && bitbake pcl-conversions`
The missing dependency was probably introduced by the automatic
recipe updates without checking for new dependencies.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Without the dependency on cmake-modules, `bitbake eigen-conversions`
can possibly fail with:
```
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/eigen-conversions/1.11.8-r0/recipe-sysroot-native/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
| Could not find a package configuration file provided by "cmake_modules"
| with any of the following names:
|
| cmake_modulesConfig.cmake
| cmake_modules-config.cmake
|
| Add the installation prefix of "cmake_modules" to CMAKE_PREFIX_PATH or set
| "cmake_modules_DIR" to a directory containing one of the above files. If
| "cmake_modules" provides a separate development package or SDK, be sure it
| has been installed.
| Call Stack (most recent call first):
| CMakeLists.txt:5 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```
The failure only occurs if cmake-modules has not been installed
before eigen-conversions is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`, which
builds many packages in parallel, did not uncover this because
make-modules was usually installed before eigen-conversions was
configured.
However, the issue is clearly reproducible with
`bitbake eigen-conversions cmake-modules -c cleanall && bitbake eigen-conversions`
The missing dependency was probably introduced by the automatic
recipe updates without checking for new dependencies.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Without the dependency on libeigen, `bitbake eigen-stl-containers`
can possibly fail with:
```
| CMake Error at CMakeLists.txt:8 (find_package):
| By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
| asked CMake to find a package configuration file provided by "Eigen3", but
| CMake did not find one.
|
| Could not find a package configuration file provided by "Eigen3" with any
| of the following names:
|
| Eigen3Config.cmake
| eigen3-config.cmake
|
| Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
| "Eigen3_DIR" to a directory containing one of the above files. If "Eigen3"
| provides a separate development package or SDK, be sure it has been
| installed.
|
|
| -- Configuring incomplete, errors occurred!
```
The failure only occurs if libeigen has not been installed
before eigen-stl-containers is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`,
which builds many packages in parallel, did not uncover this
because libeigen was usually installed before
eigen-stl-containers was configured.
However, the issue is clearly reproducible with
`bitbake eigen-stl-containers libeigen -c cleanall && bitbake eigen-stl-containers`
The missing dependency was probably overlooked in the creation of
the eigen-stl-containers recipe, i.e., in
commit a255e67c9e.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
The patch added in the reverted commit was meant to fix the issue
https://github.com/bmwcarit/meta-ros/issues/291
In fact it enables CMake to look for libraries in a host system which
leads to errors when a path is tested for a library presence with the
help of CMake's find_library() command: e.g. a non-existing host
directory is tested for library presence and find_library() returns
successfully because the library exists in bitbake's sysroot; then the
directory is used by the linker, but the library doesn't exist in the
directory -> failure. In worse cases the host directory may actually exist
and contain the library, but of wrong architecture, format or
incompatible ABI making finding the root cause a difficult task.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Lukas Bulwahn