Dear Lars,

in the meta-ros layer, we try to keep the whole layer running with the 
current upstream git repositories (oe-core and meta-openembedded/meta-oe). 
The exact URLs of these two layers can be found in the README.

With the upstream oe-core and meta-oe layer, I have not noticed this issue 
at any time in the past (that I could still remember).

The python-imaging recipe is provided in the oe-core layer, and hence 
should in fact be very well maintained; hence, I am surprised that this 
issue occurs. Also, I am unaware of any configuration in the meta-ros layer 
that influence the python-imaging recipe.

In the meta-ros layer, the rosbag recipe depend on python-imaging; if you 
do not require rosbag on the target, you can possibly drop that from the 
packagegroup-ros-comm and avoid the issue you ran into.

In the last 24 hours, I tried hard to reproduce the issue, but it did not 
occur.

I tried on oe-core jethro:

[lukas@hulk build]$ bitbake packagegroup-ros-comm

Parsing recipes: 100%

Parsing of 1949 .bb files complete (0 cached, 1949 parsed). 2489 targets, 
78 skipped, 0 masked, 0 errors.

*NOTE*: Resolving any missing task queue dependencies

*NOTE*: multiple providers are available for jpeg (jpeg, libjpeg-turbo)

*NOTE*: consider defining a PREFERRED_PROVIDER entry to match jpeg


Build Configuration:

BB_VERSION        = "1.28.0"

BUILD_SYS         = "x86_64-linux"

NATIVELSBSTRING   = "Fedora-22"

TARGET_SYS        = "i586-oe-linux"

MACHINE           = "qemux86"

DISTRO            = "nodistro"

DISTRO_VERSION    = "nodistro.0"

TUNE_FEATURES     = "m32 i586"

TARGET_FPU        = ""

meta              = "HEAD:05e551d821594b0f4c06328386b6a82e0801ac2a"

meta-oe           

meta-python       

meta-multimedia   = "HEAD:7bc138a365e20653ddfb9229561e3e9e50b89ee8"

meta-ros          = "master:63ebe5bfe6312b6e67fbbd379ff83f2b42b85a5c"


*NOTE*: Preparing RunQueue

*NOTE*: Executing SetScene Tasks

*NOTE*: Executing RunQueue Tasks

*WARNING*: QA Issue: log4cxx: 
/log4cxx/usr/share/log4cxx/html/logmanager_8h.html is owned by uid 1008, 
which is the same as the user running bitbake. This may be due to host 
contamination [host-user-contaminated]

*NOTE*: Tasks Summary: Attempted 2177 tasks of which 1 didn't need to be 
rerun and all succeeded.


Summary: There was 1 WARNING message shown.

and I tried on poky jethro:

[lukas@hulk build]$ bitbake packagegroup-ros-comm

Loading cache: 100%

Loaded 2320 entries from dependency cache.

Parsing recipes: 100%

Parsing of 1802 .bb files complete (1797 cached, 5 parsed). 2324 targets, 
88 skipped, 0 masked, 0 errors.

*NOTE*: Resolving any missing task queue dependencies

*NOTE*: multiple providers are available for jpeg (jpeg, libjpeg-turbo)

*NOTE*: consider defining a PREFERRED_PROVIDER entry to match jpeg


Build Configuration:

BB_VERSION        = "1.28.0"

BUILD_SYS         = "x86_64-linux"

NATIVELSBSTRING   = "Fedora-22"

TARGET_SYS        = "i686-poky-linux"

MACHINE           = "genericx86"

DISTRO            = "poky"

DISTRO_VERSION    = "2.0.1"

TUNE_FEATURES     = "m32 core2"

TARGET_FPU        = ""

meta              

meta-yocto        

meta-yocto-bsp    = "jethro:5b12268f6e17574999f91628a60e21711cf62ee4"

meta-oe           = "jethro:7bc138a365e20653ddfb9229561e3e9e50b89ee8"

meta-ros          = "master:63ebe5bfe6312b6e67fbbd379ff83f2b42b85a5c"


*NOTE*: Preparing RunQueue

*NOTE*: Executing SetScene Tasks

*NOTE*: Executing RunQueue Tasks

*NOTE*: Tasks Summary: Attempted 1650 tasks of which 696 didn't need to be 
rerun and all succeeded.

Maybe it was just an intermediate issue in the oe-core jethro branch, and 
you just have to update your git repositories to current version?

Could you please provide the exact commit identifiers of the layers that 
you are using?

Lukas

Reply via email to