Commit openembedded/openembedded-core@0391fca ("classes/utils: remove
compatibility functions") forces us to update to the proper oe.utils
functions.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
This commit is the result of:
- cherry-picking the two commits from the branch kinetic-experimental-v3-alpha1
commit aed2202182df ("ros-canopen: adding can-msgs, socketcan-interface and socketcan-bridge")
commit b62356a3a545 ("socketcan-interface: apply patch to compile with boost 1.65")
- downgrading the recipe version to the indigo release version 0.6.8,
- and squashing these changes into one commit.
The original ros-canopen recipes on kinetic-experimental were
provided by Matthias Schoepfer <matthias.schoepfer@identpro.de>.
[1] aed2202182
[2] b62356a3a5
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
This commit also drops patches included in version 1.12.14 and
adjusts to new enforced dependencies in the move_base package.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
This commit includes:
- use `DEPENDS =` instead of `DEPENDS +=`.
- put single-line configurations into a single line
- move DEPENDS to right location in recipe files
- remove superfluous ROS_SPN declarations
The clean up was motivated by the commits for
object-recognition-msgs and hector-mapping in #519.
Issues were identified with `grep "DEPENDS +=" . -R` and by looking
at the output of oe-stylize.py with this bash script:
```
for RECIPE in $(find . -name *.bb)
do
echo "Processing: $RECIPE"
~/work/repositories/openembedded.org/meta-openembedded/contrib/oe-stylize.py $RECIPE > $RECIPE-oestylize
diff $RECIPE $RECIPE-oestylize
done
```
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the recipe update, the commit also adjusts the line number
of the license file check and adds new dependencies.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
This commit also adjusts the dependencies, and drops the patch file
that is included in this version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Since Github's auto-generated tarballs aren't garanteed to be identical
over time it's better to tie the recipe to a git revision.
contributes to #552
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Since Github's auto-generated tarballs aren't garanteed to be identical
over time it's better to tie the recipe to a git revision.
contributes to #552
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Since Github's auto-generated tarballs aren't garanteed to be identical
over time it's better to tie the recipe to a git revision.
closes#552
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Lukas Bulwahn