Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-03 Thread Paul Eggleton 
Hi Trevor,

On Friday, 4 May 2018 3:26:18 PM NZST Trevor Woerner wrote:
> On Wed, May 2, 2018 at 5:19 PM, Paul Eggleton  > wrote:
> > 1) If you want the cppzmq development files to be available *within* the
> > eSDK
> > (so you can write code to use them using the eSDK), even if they are not
> > brought in by way of the image containing a package from the cppzmq
> > recipe,
> > you can install them into the eSDK by running this within the eSDK
> > environment:
> >
> > devtool sdk-install -s cppzmq
> >
> 
> Is sdk-install new? It doesn't show up when I run "devtool help"

It's only available within the eSDK - you won't see it if you run devtool next 
to the build system.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-03 Thread Trevor Woerner 
On Wed, May 2, 2018 at 5:19 PM, Paul Eggleton  wrote:

> 1) If you want the cppzmq development files to be available *within* the
> eSDK
> (so you can write code to use them using the eSDK), even if they are not
> brought in by way of the image containing a package from the cppzmq
> recipe,
> you can install them into the eSDK by running this within the eSDK
> environment:
>
> devtool sdk-install -s cppzmq
>

Is sdk-install new? It doesn't show up when I run "devtool help"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-02 Thread Paul Eggleton 
On Wednesday, 2 May 2018 8:33:12 PM NZST Andrea Galbusera wrote:
> On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt  wrote:
> > Hacking the recipe according to:
> > martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
> > diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> > b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> > index a64745c94..aba1d6edb 100644
> > --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> > +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> > @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
> >
> >  do_install () {
> >  install -d ${D}/usr/include
> > +install -d ${D}/etc
> >  install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
> > +install -m 0755 ${S}/zmq.hpp ${D}/etc
> >  }
> >
> > -PACKAGES = "${PN}-dev"
> > +PACKAGES = "${PN}-dev ${PN}"
> 
> If you go down the patch-the-recipe way, you can probably leave
> PACKAGES at its default: both ${PN} and ${PN}-dev are there by
> default.
> 
> > RDEPENDS_${PN}-dev = "zeromq-dev"
> >
> > triggers both ${PN}-dev and ${PN} variants to be packaged and included by
> > the image. Leaving out the installation into /etc causes ${PN} package not
> > to be generated and the image generation does not pick up the ${PN}-dev
> > variant.
> 
> Better would be adding:
> 
> ALLOW_EMPTY_${PN} = "1"
> 
> This way it's cleaner and should work as well. However, you'll need to
> force your image to depend upon an empty package to be added
> (meaningless for the target), for the sake of the corresponding -dev
> package to be part of the tailored eSDK... Maybe there's a better way
> to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
> with something like TOOLCHAIN_TARGET_TASK_append (never used it in
> practice though). Hopefully someone can further comment on this to add
> some wisdom.
> 
> > In essence, it looks like image generation disregards recipes residing
> > exclusively in the ${PN}-dev variant - question is whether this is
> > intended
> > or not?
> 
> Yes it is. -dev packages are not intended to be installed into target
> image by design.

Rather than "by design" I would say "by default" - you can certainly install 
them explicitly (or for the whole image via IMAGE_FEATURES += "dev-pkgs" and 
that is intended - but out of the box it's not expected that you would be 
doing compilation on the target and thus the expectation is that the 
development files aren't needed.

A couple of other things worth mentioning from earlier in the discussion:


1) If you want the cppzmq development files to be available *within* the eSDK 
(so you can write code to use them using the eSDK), even if they are not 
brought in by way of the image containing a package from the cppzmq recipe, 
you can install them into the eSDK by running this within the eSDK 
environment:

devtool sdk-install -s cppzmq

Alternatively you can add them to the built eSDK by setting this before you 
build it:

SDK_TARGETS += "cppzmq:do_populate_sysroot"

FWIW there is a bug open to make this more friendly:

 https://bugzilla.yoctoproject.org/show_bug.cgi?id=10600


2) To add packages to the image when doing devtool build-image within the eSDK 
you would use the -p option (rather than trying to set IMAGE_INSTALL on the 
command line), so you could do the following for this situation:

devtool build-image -p cppzmq-dev

(This should work regardless of whether or not you do #1 above)


Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-02 Thread Andrea Galbusera 
On Wed, May 2, 2018 at 2:33 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi Andrea,
>
> You are right, the recipe works-as-is, when adding 'cppzmq-dev' to the image 
> rather than just 'cppzmq' - I was not aware of this. From an eSDK perspective 
> it seems to work when the package is installed according to
>
> devtool sdk-install -s cppzmq
>
> and then adding 'IMAGE_INSTALL += "cppzmq-dev"' to local.conf.
>
> On the variables passed in from the shell, can you refer to the location of 
> this whitelist - for future reference?

https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST

>
> Thanks for your support - highly appreciated.
> Martin
>
>
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Wednesday, May 2, 2018 10:33
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
>
> On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
>> Hi,
>>
>>
>> Hacking the recipe according to:
>>
>>
>> martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
>> diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> index a64745c94..aba1d6edb 100644
>> --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
>>
>>  do_install () {
>>  install -d ${D}/usr/include
>> +install -d ${D}/etc
>>  install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
>> +install -m 0755 ${S}/zmq.hpp ${D}/etc
>>  }
>>
>> -PACKAGES = "${PN}-dev"
>> +PACKAGES = "${PN}-dev ${PN}"
>
> If you go down the patch-the-recipe way, you can probably leave
> PACKAGES at its default: both ${PN} and ${PN}-dev are there by
> default.
>
>> RDEPENDS_${PN}-dev = "zeromq-dev"
>>
>> triggers both ${PN}-dev and ${PN} variants to be packaged and included by
>> the image. Leaving out the installation into /etc causes ${PN} package not
>> to be generated and the image generation does not pick up the ${PN}-dev
>> variant.
>
> Better would be adding:
>
> ALLOW_EMPTY_${PN} = "1"
>
> This way it's cleaner and should work as well. However, you'll need to
> force your image to depend upon an empty package to be added
> (meaningless for the target), for the sake of the corresponding -dev
> package to be part of the tailored eSDK... Maybe there's a better way
> to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
> with something like TOOLCHAIN_TARGET_TASK_append (never used it in
> practice though). Hopefully someone can further comment on this to add
> some wisdom.
>
>> In essence, it looks like image generation disregards recipes residing
>> exclusively in the ${PN}-dev variant - question is whether this is intended
>> or not?
>
> Yes it is. -dev packages are not intended to be installed into target
> image by design.
>
>>
>>
>> Br,
>>
>> Martin
>>
>>
>> ____________
>> From: Martin Siegumfeldt
>> Sent: Tuesday, May 1, 2018 8:49:17 PM
>> To: Andrea Galbusera
>>
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>>
>>
>> Hi Andrea,
>>
>>
>>
>> 
>> From: Andrea Galbusera <giz...@gmail.com>
>> Sent: Tuesday, May 1, 2018 16:06
>> To: Martin Siegumfeldt
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>>
>> Hi Martin,
>>
>> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
>> wrote:
>>> Hi,
>>>
>>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>>> search function does not return anything, despite the recipe being available
>>> through local recipe:
>>>
>>> martin@dell:~/gomspace_sdk$ ls
>>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>>
>>> I assume this is expected since it does not come prebuilt as part of the
>>> eSDK - is this correct understood?
>>>
>>> Fortunately, 'devtool modify/build/package'

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-02 Thread Martin Siegumfeldt 
Hi Andrea,

You are right, the recipe works-as-is, when adding 'cppzmq-dev' to the image 
rather than just 'cppzmq' - I was not aware of this. From an eSDK perspective 
it seems to work when the package is installed according to

devtool sdk-install -s cppzmq

and then adding 'IMAGE_INSTALL += "cppzmq-dev"' to local.conf.

On the variables passed in from the shell, can you refer to the location of 
this whitelist - for future reference?

Thanks for your support - highly appreciated.
Martin


From: Andrea Galbusera <giz...@gmail.com>
Sent: Wednesday, May 2, 2018 10:33
To: Martin Siegumfeldt
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
  

On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
>
> Hacking the recipe according to:
>
>
> martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
> diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> index a64745c94..aba1d6edb 100644
> --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
>
>  do_install () {
>  install -d ${D}/usr/include
> +    install -d ${D}/etc
>  install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
> +    install -m 0755 ${S}/zmq.hpp ${D}/etc
>  }
>
> -PACKAGES = "${PN}-dev"
> +PACKAGES = "${PN}-dev ${PN}"

If you go down the patch-the-recipe way, you can probably leave
PACKAGES at its default: both ${PN} and ${PN}-dev are there by
default.

> RDEPENDS_${PN}-dev = "zeromq-dev"
>
> triggers both ${PN}-dev and ${PN} variants to be packaged and included by
> the image. Leaving out the installation into /etc causes ${PN} package not
> to be generated and the image generation does not pick up the ${PN}-dev
> variant.

Better would be adding:

ALLOW_EMPTY_${PN} = "1"

This way it's cleaner and should work as well. However, you'll need to
force your image to depend upon an empty package to be added
(meaningless for the target), for the sake of the corresponding -dev
package to be part of the tailored eSDK... Maybe there's a better way
to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
with something like TOOLCHAIN_TARGET_TASK_append (never used it in
practice though). Hopefully someone can further comment on this to add
some wisdom.

> In essence, it looks like image generation disregards recipes residing
> exclusively in the ${PN}-dev variant - question is whether this is intended
> or not?

Yes it is. -dev packages are not intended to be installed into target
image by design.

>
>
> Br,
>
> Martin
>
>
> ____________
> From: Martin Siegumfeldt
> Sent: Tuesday, May 1, 2018 8:49:17 PM
> To: Andrea Galbusera
>
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
>
> Hi Andrea,
>
>
>
> 
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Tuesday, May 1, 2018 16:06
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
> Hi Martin,
>
> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
> wrote:
>> Hi,
>>
>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>> search function does not return anything, despite the recipe being available
>> through local recipe:
>>
>> martin@dell:~/gomspace_sdk$ ls
>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>
>> I assume this is expected since it does not come prebuilt as part of the
>> eSDK - is this correct understood?
>>
>> Fortunately, 'devtool modify/build/package' generates the package -
>> unfortunately it is not included in the subsequent image generation:
>>
>> martin@dell:~/gomspace_sdk$ devtool package cppzmq
>> NOTE: Starting bitbake server...
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:03
>> Loaded 2773 e

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-02 Thread Andrea Galbusera 
On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
>
> Hacking the recipe according to:
>
>
> martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
> diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> index a64745c94..aba1d6edb 100644
> --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
>
>  do_install () {
>  install -d ${D}/usr/include
> +install -d ${D}/etc
>  install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
> +install -m 0755 ${S}/zmq.hpp ${D}/etc
>  }
>
> -PACKAGES = "${PN}-dev"
> +PACKAGES = "${PN}-dev ${PN}"

If you go down the patch-the-recipe way, you can probably leave
PACKAGES at its default: both ${PN} and ${PN}-dev are there by
default.

> RDEPENDS_${PN}-dev = "zeromq-dev"
>
> triggers both ${PN}-dev and ${PN} variants to be packaged and included by
> the image. Leaving out the installation into /etc causes ${PN} package not
> to be generated and the image generation does not pick up the ${PN}-dev
> variant.

Better would be adding:

ALLOW_EMPTY_${PN} = "1"

This way it's cleaner and should work as well. However, you'll need to
force your image to depend upon an empty package to be added
(meaningless for the target), for the sake of the corresponding -dev
package to be part of the tailored eSDK... Maybe there's a better way
to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
with something like TOOLCHAIN_TARGET_TASK_append (never used it in
practice though). Hopefully someone can further comment on this to add
some wisdom.

> In essence, it looks like image generation disregards recipes residing
> exclusively in the ${PN}-dev variant - question is whether this is intended
> or not?

Yes it is. -dev packages are not intended to be installed into target
image by design.

>
>
> Br,
>
> Martin
>
>
> ____________
> From: Martin Siegumfeldt
> Sent: Tuesday, May 1, 2018 8:49:17 PM
> To: Andrea Galbusera
>
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
>
> Hi Andrea,
>
>
>
> ________
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Tuesday, May 1, 2018 16:06
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
> Hi Martin,
>
> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
> wrote:
>> Hi,
>>
>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>> search function does not return anything, despite the recipe being available
>> through local recipe:
>>
>> martin@dell:~/gomspace_sdk$ ls
>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>
>> I assume this is expected since it does not come prebuilt as part of the
>> eSDK - is this correct understood?
>>
>> Fortunately, 'devtool modify/build/package' generates the package -
>> unfortunately it is not included in the subsequent image generation:
>>
>> martin@dell:~/gomspace_sdk$ devtool package cppzmq
>> NOTE: Starting bitbake server...
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:03
>> Loaded 2773 entries from dependency cache.
>> Parsing recipes: 100%
>> |##|
>> Time: 0:00:01
>> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets,
>> 305 skipped, 11 masked, 0 errors.
>> NOTE: Resolving any missing task queue dependencies
>> Initialising tasks: 100%
>> |###|
>> Time: 0:00:00
>> Checking sstate mirror object availability: 100%
>> |###

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-02 Thread Martin Siegumfeldt 
Hi,


Hacking the recipe according to:


martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb 
b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
index a64745c94..aba1d6edb 100644
--- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
+++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
@@ -13,9 +13,11 @@ S = "${WORKDIR}/git"

 do_install () {
 install -d ${D}/usr/include
+install -d ${D}/etc
 install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
+install -m 0755 ${S}/zmq.hpp ${D}/etc
 }

-PACKAGES = "${PN}-dev"
+PACKAGES = "${PN}-dev ${PN}"

RDEPENDS_${PN}-dev = "zeromq-dev"

triggers both ${PN}-dev and ${PN} variants to be packaged and included by the 
image. Leaving out the installation into /etc causes ${PN} package not to be 
generated and the image generation does not pick up the ${PN}-dev variant.


In essence, it looks like image generation disregards recipes residing 
exclusively in the ${PN}-dev variant - question is whether this is intended or 
not?


Br,

Martin



From: Martin Siegumfeldt
Sent: Tuesday, May 1, 2018 8:49:17 PM
To: Andrea Galbusera
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)


Hi Andrea,



From: Andrea Galbusera <giz...@gmail.com>
Sent: Tuesday, May 1, 2018 16:06
To: Martin Siegumfeldt
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)

Hi Martin,

On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The 
> search function does not return anything, despite the recipe being available 
> through local recipe:
>
> martin@dell:~/gomspace_sdk$ ls 
> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
> cppzmq_git.bb  files  zeromq_4.1.6.bb
>
> I assume this is expected since it does not come prebuilt as part of the eSDK 
> - is this correct understood?
>
> Fortunately, 'devtool modify/build/package' generates the package - 
> unfortunately it is not included in the subsequent image generation:
>
> martin@dell:~/gomspace_sdk$ devtool package cppzmq
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:03
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:01
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> Initialising tasks: 100% 
> |###|
>  Time: 0:00:00
> Checking sstate mirror object availability: 100% 
> |###|
>  Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun 
> and all succeeded.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>
> martin@dell:~/gomspace_sdk$ devtool build-image
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:02
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 27

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-02 Thread Andrea Galbusera 
Martin,

On Tue, May 1, 2018 at 8:49 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi Andrea,
>
>
>
> 
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Tuesday, May 1, 2018 16:06
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
> Hi Martin,
>
> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
> wrote:
>> Hi,
>>
>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>> search function does not return anything, despite the recipe being available
>> through local recipe:
>>
>> martin@dell:~/gomspace_sdk$ ls
>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>
>> I assume this is expected since it does not come prebuilt as part of the
>> eSDK - is this correct understood?
>>
>> Fortunately, 'devtool modify/build/package' generates the package -
>> unfortunately it is not included in the subsequent image generation:
>>
>> martin@dell:~/gomspace_sdk$ devtool package cppzmq
>> NOTE: Starting bitbake server...
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:03
>> Loaded 2773 entries from dependency cache.
>> Parsing recipes: 100%
>> |##|
>> Time: 0:00:01
>> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets,
>> 305 skipped, 11 masked, 0 errors.
>> NOTE: Resolving any missing task queue dependencies
>> Initialising tasks: 100%
>> |###|
>> Time: 0:00:00
>> Checking sstate mirror object availability: 100%
>> |###|
>> Time: 0:00:00
>> NOTE: Executing SetScene Tasks
>> NOTE: Executing RunQueue Tasks
>> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be
>> rerun and all succeeded.
>>
>> Summary: There was 1 WARNING message shown.
>> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>>
>> martin@dell:~/gomspace_sdk$ devtool build-image
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:00
>> Loaded 2773 entries from dependency cache.
>> Parsing recipes: 100%
>> |##|
>> Time: 0:00:02
>> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets,
>> 305 skipped, 11 masked, 0 errors.
>>
>> Summary: There was 1 WARNING message shown.
>> WARNING: Skipping recipe cppzmq as it doesn't produce a package with the
>> same name
>
> This is the suspicious bit... If you look at the recipe, you'll notice
> it's re-defining the PACKAGES variable. Then, it's not generating a
> package called 'cppzmq', but only one named 'cppzmq-dev'. That said,
> I'm not sure why you'd want to add a package which only provides
> development headers to your target image...
>
> I understand your doubt here. The header file installed is a wrapper around
> zeromq and thus DEPENDS/RDEPENDS on this library. zeromq is included in the
> image, for which the SDK is generated, hence I would expect this to be a
> valid use case?
>
> Anyhow, I realized that the recipe does not even work in a BB environment -
> the following is encountered for an image includin

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-01 Thread Martin Siegumfeldt 
Hi Andrea,



From: Andrea Galbusera <giz...@gmail.com>
Sent: Tuesday, May 1, 2018 16:06
To: Martin Siegumfeldt
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)

Hi Martin,

On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The 
> search function does not return anything, despite the recipe being available 
> through local recipe:
>
> martin@dell:~/gomspace_sdk$ ls 
> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
> cppzmq_git.bb  files  zeromq_4.1.6.bb
>
> I assume this is expected since it does not come prebuilt as part of the eSDK 
> - is this correct understood?
>
> Fortunately, 'devtool modify/build/package' generates the package - 
> unfortunately it is not included in the subsequent image generation:
>
> martin@dell:~/gomspace_sdk$ devtool package cppzmq
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:03
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:01
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> Initialising tasks: 100% 
> |###|
>  Time: 0:00:00
> Checking sstate mirror object availability: 100% 
> |###|
>  Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun 
> and all succeeded.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>
> martin@dell:~/gomspace_sdk$ devtool build-image
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:02
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
>
> Summary: There was 1 WARNING message shown.
> WARNING: Skipping recipe cppzmq as it doesn't produce a package with the same 
> name

This is the suspicious bit... If you look at the recipe, you'll notice
it's re-defining the PACKAGES variable. Then, it's not generating a
package called 'cppzmq', but only one named 'cppzmq-dev'. That said,
I'm not sure why you'd want to add a package which only provides
development headers to your target image...

I understand your doubt here. The header file installed is a wrapper around 
zeromq and thus DEPENDS/RDEPENDS on this library. zeromq is included in the 
image, for which the SDK is generated, hence I would expect this to be a valid 
use case?

Anyhow, I realized that the recipe does not even work in a BB environment - the 
following is encountered for an image including the package:

ERROR: Nothing RPROVIDES 'cppzmq' (but 
/home/martin/work/z7000-distro-zcu102/poky/meta/recipes-core/images/core-image-minimal.bb
 RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'cppzmq' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['cppzmq']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'cppzmq']

Re: [yocto] Recipe availability through eSDK (cppzmq)

2018-05-01 Thread Andrea Galbusera 
Hi Martin,

On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The 
> search function does not return anything, despite the recipe being available 
> through local recipe:
>
> martin@dell:~/gomspace_sdk$ ls 
> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
> cppzmq_git.bb  files  zeromq_4.1.6.bb
>
> I assume this is expected since it does not come prebuilt as part of the eSDK 
> - is this correct understood?
>
> Fortunately, 'devtool modify/build/package' generates the package - 
> unfortunately it is not included in the subsequent image generation:
>
> martin@dell:~/gomspace_sdk$ devtool package cppzmq
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:03
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:01
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> Initialising tasks: 100% 
> |###|
>  Time: 0:00:00
> Checking sstate mirror object availability: 100% 
> |###|
>  Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun 
> and all succeeded.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>
> martin@dell:~/gomspace_sdk$ devtool build-image
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:02
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
>
> Summary: There was 1 WARNING message shown.
> WARNING: Skipping recipe cppzmq as it doesn't produce a package with the same 
> name

This is the suspicious bit... If you look at the recipe, you'll notice
it's re-defining the PACKAGES variable. Then, it's not generating a
package called 'cppzmq', but only one named 'cppzmq-dev'. That said,
I'm not sure why you'd want to add a package which only provides
development headers to your target image...

>
> Inspecting the manifest file confirms that the package is not installed - any 
> idea why not? I also tried installing though sdk-install:
>
> martin@dell:~/gomspace_sdk$ devtool sdk-install -s cppzmq
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:02
> Parsing of 1968 .bb files complete (1961 cached, 7 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Installing cppzmq...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is