* resolves issues with newer CMake
-- Performing Test HAVE_MM_MALLOC
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately:
HAVE_MM_MALLOC_EXITCODE (advanced)
HAVE_MM_MALLOC_EXITCODE__TRYRUN_OUTPUT (advanced)
For details see pcl/1.8.0-r0/build/TryRunResults.cmake
-- Performing Test HAVE_MM_MALLOC - Success
* should resolve the issues with memory usage during the build:
https://github.com/PointCloudLibrary/pcl/issues/2284#issuecomment-437584571
but it still triggers OOMK with -j8 on 32GB RAM builder, use at least
-j4 to improve the build time a bit
* use git fetcher for sources, github archives can be regenerated
from time to time with different checksums:
https://github.com/bmwcarit/meta-ros/issues/609
* 0001-make-the-pcl-library-compile-with-gcc6.patch is needed only
with thud and older, with warrior it builds OK without this
patch as well
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* newer version is needed to fix build with newer python-3.7:
_proj.c:7421:21: error: 'PyThreadState' {aka 'struct _ts'} has no member named 'exc_type'; did you mean 'curexc_type'?
*type = tstate->exc_type;
^~~~~~~~
curexc_type
* see https://github.com/pyproj4/pyproj/issues/138https://github.com/pyproj4/pyproj/issues/136
* and pypi.bbclass is needed to fetch the source from
files.pythonhosted.org, the old pypi.python.org/packages/source
doesn't have the new releases
* the newest version is 2.1.3, but that needs a bit more changes
like:
DEPENDS += "${PYTHON_PN}-cython-native"
and then it still fails with:
| Proj executable not found. Please set PROJ_DIR variable.
| ERROR: 'python3 setup.py build ' execution failed.
will probably need native pyproj as well, I'll leave that to someone
actually using pyproj (I was just fixing the build error detected in
bitbake world with Yocto 2.7 Warrior).
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fixes:
ERROR: festival-2.4-r0 do_package_qa: QA Issue: festival: /festival/usr/share/festival/dicts/wsj.wp39.poslexR is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/wsj.wp39.tri.ngrambin is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/COPYING.poslex is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmudict-0.4.diff is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmu_lts_rules.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmudict_extensions.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmulex.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmudict-0.4.out is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/Makefile is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmudict_compile.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/allowables.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmudict-0.4.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/cmu2ft is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/cmu/COPYING is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/cuvoald710-0.2.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/oald-0.4.out is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/oald2ft.tar.gz is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/Makefile is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/oald_extensions.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/oald_lts_rules.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/oaldlex.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/README.oald is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/dicts/oald/COPYING is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/rab_diphone/COPYING is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/rab_diphone/festvox/rab_diphone.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/rab_diphone/group/rablpc16k.group is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/kal_diphone/COPYING is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/kal_diphone/festvox/kal_diphone.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/kal_diphone/festvox/kaldurtreeZ.scm is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination
festival: /festival/usr/share/festival/voices/english/kal_diphone/group/kallpc16k.group is owned by uid 1026, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* using PN here won't work with multilib
* fixes QA warning:
WARNING: festival-2.4-r0 do_package_qa: QA Issue: festival: SRC_URI uses PN not BPN [src-uri-bad]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fixes:
ar-track-alvar/0.6.1-r0/ar_track_alvar-0.6.1/src/Marker.cpp: In member function 'virtual void alvar::MarkerData::VisualizeMarkerContent(IplImage*, alvar::Camera*, double*, double*) const':
ar-track-alvar/0.6.1-r0/ar_track_alvar-0.6.1/src/Marker.cpp:123:15: error: 'CV_RGB' was not declared in this scope
CvScalar rgb=CV_RGB(255,255,0);
^~~~~~
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fixes:
ERROR: python-wstool-0.1.13-r0 do_package: QA Issue: python-wstool: Files/directories were installed but not shipped in any package:
/usr/share
/usr/share/zsh
/usr/share/zsh/site-functions
/usr/share/zsh/site-functions/_wstool
/usr/share/zsh/site-functions/wstool-completion.bash
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
python-wstool: 5 installed and not shipped files. [installed-vs-shipped]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Deprecated signals library was dropped in 1.69.0 release:
https://www.boost.org/users/history/version_1_69_0.html
Signals (v1) is now removed. Its removal was announced in 1.68 and its
deprecation was announced in 1.54. Boost 1.68 is the last release that
provides this library. Users are encouraged to use Signals2 instead. The
Boost community thanks Douglas Gregor for his work on Signals which
served its users well and which also inspired Signals2.
image-view doesn't use signals at all.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fixes:
image-view/1.12.23-r0/image_pipeline-1.12.23/image_view/src/nodes/stereo_view.cpp:53:10: fatal error: gtk/gtk.h: No such file or directory
#include <gtk/gtk.h>
^~~~~~~~~~~
compilation terminated.
* also add x11 to required DISTRO_FEATURES as gtk+ is available only with x11 or directfb,
otherwise ti causes another error in world builds:
ERROR: Nothing PROVIDES 'gtk+' (but meta-ros/recipes-ros/image-pipeline/image-view_1.12.23.bb DEPENDS on or otherwise requires it)
gtk+ was skipped: one of '['directfb', 'x11']' needs to be in DISTRO_FEATURES
* GTK2DISTROFEATURES variable and ANY_OF_DISTRO_FEATURES check is
available since 2.0 Jethro (that should be old enough that all
meta-ros/legacy users already have support for this).
commit 60157da8a6df0c7ec5bb572bea5124af273bab08
Author: Joe Slater <jslater@windriver.com>
Date: Thu May 7 12:55:26 2015 -0700
distro_features_check: add any of test
commit ef967c70182eeccb59c7511d838a7ecb0b2315c1
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Mon Sep 28 11:53:35 2015 +0100
classes/meta: Add DISTRO_FEATURES check for gtk+/gtk3+
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* resolves following error in world builds without everybody needing
to blacklist it manually for builds which don't include
meta-intel-realsense layer, we could use dynamic layers for this, but
as long as this is the only recipe depending on optional layer, we
can just use this DISTRO_FEATURE (like thud branch of meta-ros is
using now).
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'librealsense' (but /OE/build/oe-core/meta-ros/recipes-extended/realsense-camera/realsense-camera_1.8.0.bb DEPENDS on or otherwise requires it)
ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'realsense-camera', 'librealsense']
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Deprecated signals library was dropped in 1.69.0 release:
https://www.boost.org/users/history/version_1_69_0.html
Signals (v1) is now removed. Its removal was announced in 1.68 and its
deprecation was announced in 1.54. Boost 1.68 is the last release that
provides this library. Users are encouraged to use Signals2 instead. The
Boost community thanks Douglas Gregor for his work on Signals which
served its users well and which also inspired Signals2.
Ros code already uses signals2 library but it still has links to the
older library in its CMake files. This commit removes those references
as they are now useless and more importantly source of error at
configure time.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
bson is provided by python-pymongo in meta-python
Not all runtime dependencies are automatically added, which leads to
dependency problems in the package management. Added two packages to
RDEPENDS.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
- Add a description of this branch and its status.
- Fixup URLs for new location of meta-ros.git .
- Fixup URLs to use https: wherever possible.
- Switch the branches of the layer dependencies from [master] to [thud].
- Remove references to development guide wiki pages that no longer
exist or are no longer applicable to this branch.
SQUASH README
* it actually needs ${PYTHON_PN}-pyparsing-native as shown in
do_configure failure:
| DEBUG: Executing shell function do_configure
| -- Found PythonInterp: ament-cmake-core/git-r0/recipe-sysroot-native/usr/bin/python3-native/python3 (found suitable version "3.5.2", minimum required is "3")
| -- Using PYTHON_EXECUTABLE: ament-cmake-core/git-r0/recipe-sysroot-native/usr/bin/python3-native/python3
| Error parsing 'ament-cmake-core/git-r0/git/ament_cmake_core/package.xml':
| Traceback (most recent call last):
| File "ament-cmake-core/git-r0/git/ament_cmake_core/cmake/core/package_xml_2_cmake.py", line 145, in <module>
| main()
| File "ament-cmake-core/git-r0/git/ament_cmake_core/cmake/core/package_xml_2_cmake.py", line 56, in main
| raise e
| File "ament-cmake-core/git-r0/git/ament_cmake_core/cmake/core/package_xml_2_cmake.py", line 53, in main
| package = parse_package_string(args.package_xml.read())
| File "ament-cmake-core/git-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/ament_package/__init__.py", line 173, in parse_package_string
| pkg.build_depends = _get_dependencies(root, 'build_depend')
| File "ament-cmake-core/git-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/ament_package/__init__.py", line 364, in _get_dependencies
| from .dependency import Dependency
| File "ament-cmake-core/git-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/ament_package/dependency.py", line 15, in <module>
| from ament_package.condition import evaluate_condition
| File "ament-cmake-core/git-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/ament_package/condition.py", line 17, in <module>
| import pyparsing
| ImportError: No module named 'pyparsing'
| CMake Error at cmake/core/ament_package_xml.cmake:94 (message):
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* Fix wrong suffix x86_64-linux-gnu in native python module shared library
* Python native module shared library is cross-compiled for correct
architecture but filename had an incorrect suffix 'x86_64-linux-gnu'.
As per python_cmake_module, if PYTHON_SOABI environment variable is not
defined, it'll query it from native's python sysconfig module.
https://github.com/ros2/rosidl/blob/master/python_cmake_module/cmake/Modules/FindPythonExtra.cmake
So adopt a solution similar to the one adopted below, where PYTHON_SOABI
is set explicitly for our specific build.
https://github.com/erlerobot/meta-ros2/blob/master/classes/ament.bbclass
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Fixes rosidl:
ImportError: No module named 'json'
ImportError: No module named 'em'
Fixes ros2:
ImportError: No module named 'xmlrpc'
ImportError: No module named 'pydoc'
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fixes rmw-fastrtps-cpp failure:
http://errors.yoctoproject.org/Errors/Details/174717/
DEBUG: Executing shell function do_compile
NOTE: VERBOSE=1 cmake --build TOPDIR/tmp-glibc/work/aarch64-oe-linux/rmw-fastrtps-cpp/git-r0/build --target all -- -j 9
ninja: error: 'TOPDIR/tmp-glibc/work/aarch64-oe-linux/fastrtps/git-r0/recipe-sysroot/usr/lib/libtinyxml2.so', needed by 'librmw_fastrtps_cpp.so', missing and no known rule to make it
WARNING: TOPDIR/tmp-glibc/work/aarch64-oe-linux/rmw-fastrtps-cpp/git-r0/temp/run.do_compile.13110:1 exit 1 from 'eval ${DESTDIR:+DESTDIR=${DESTDIR} }VERBOSE=1 cmake --build 'TOPDIR/tmp-glibc/work/aarch64-oe-linux/rmw-fastrtps-cpp/git-r0/build' "$@" -- -j 9'
ERROR: Function failed: do_compile (log file is located at TOPDIR/tmp-glibc/work/aarch64-oe-linux/rmw-fastrtps-cpp/git-r0/temp/log.do_compile.13110)
* it was caused by fastrtps's /usr/lib/fastrtps/cmake/fastrtpsTargets.cmake
containing the full path to libtinyxml2.so inside fastrtps's WORKDIR
which might be already removed by rm_work by the time when
rmw-fastrtps-cpp is being built
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* using AUTOREV causes undeterministic builds when it might start failing
even when nothing was changed in the metadata
* it also forces bitbake to run git ls-remote on the github repo every
single time when the recipe is parsed and fails to build when doing builds
without network access (from pre-populated premirror)
* hydro-devel branch wasn't updated for last 3 years and there are only 73
commits in it, so AUTOREV wasn't really useful anyway
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* fixes:
| checking for bison... no
| configure: error: You need to install bison
| NOTE: The following config.log files may provide further information.
| NOTE: /data/cibot/deleteme/build/tmp-glibc/work/i586-oe-linux/sphinxbase/0.8-r0/build/config.log
* needed since oe-core change:
http://git.openembedded.org/openembedded-core/commit/?id=b7edc20cc2dd82989bd9561f860cb25478a40f69
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* meta-ros is compatible with Yocto 2.4 Rocko without any special
handling needed to integrate it, mark it as compatible
* LAYERSERIES_COMPAT variables are used only since 2.4 Rocko, so with
even older Yocto releases this isn't an issue, but with 2.4 it was
failing with:
bitbake -e zlib | tee env.zlib
ERROR: Unable to start bitbake server
which isn't really useful, bitbake-cookerdaemon.log shows better
explanation:
Traceback (most recent call last):
File "build-rocko/bitbake/lib/bb/cookerdata.py", line 285, in parseBaseConfiguration
self.data = self.parseConfigurationFiles(self.prefiles, self.postfiles)
File "build-rocko/bitbake/lib/bb/cookerdata.py", line 399, in parseConfigurationFiles
% (c, " ".join(layerseries), " ".join(compat)))
File "build-rocko/bitbake/lib/bb/__init__.py", line 104, in fatal
raise BBHandledException()
bb.BBHandledException
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "build-rocko/bitbake/lib/bb/daemonize.py", line 77, in createDaemon
function()
File "build-rocko/bitbake/lib/bb/server/process.py", line 433, in _startServer
self.cooker = bb.cooker.BBCooker(self.configuration, self.featureset)
File "build-rocko/bitbake/lib/bb/cooker.py", line 197, in __init__
self.initConfigurationData()
File "build-rocko/bitbake/lib/bb/cooker.py", line 356, in initConfigurationData
self.databuilder.parseBaseConfiguration()
File "build-rocko/bitbake/lib/bb/cookerdata.py", line 318, in parseBaseConfiguration
raise bb.BBHandledException
bb.BBHandledException
ERROR: Layer ros-layer is not compatible with the core layer which only supports these series: rocko (layer is compatible with sumo)
* and it's a bit complicated to override LAYERSERIES_COMPAT_ros-layer
from local build without meta-ros modification, changing it in some
other (own) layer, which is parsed after meta-ros works, but you might
not have suitable layer for this.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Martin Jansa