Re: [yocto] Problem with Python when running oe-init-build-env

[Zoran Stojsavljevic]

Hello Raymond,

The problem is that you (talking about your host distro):
[1] Do NOT have python3 package installed;
[2] Do have python3 package < 3.4.0 version, so you need to upgrade!

So, I have no idea which host distro you are using, but:
[1] If Debian/Ubuntu, then: apt-get install python3
 If Fedora, then dnf install python3
[2] If Debian/Ubuntu, then: apt-get update python3
 If Fedora, then dnf update python3

Hope this helps,
Zoran
___

On Tue, May 1, 2018 at 10:43 PM, Raymond Yeung  wrote:
> I'd just git cloned Rocko and meta-ti.  When I try to source
> oe-init-build-env, I got errors:
>
>
> -bash: python3: command not found
>
> BitBake requires Python 3.4.0 or later as 'python3'.  "python -V" gives
> "Python 2.7.9".  "python3" is not in $PATH.  I'd followed some detailed
> online description to install Python 3.6 on CentOS 7.  However, after
> installation, it looks like I need to invoke it with python3.6.
>
>
> How does this work now?  I suppose the oe-init-build-env script uses/expects
> python3, not python3.6.
>
>
> Any insight?
>
>
> Raymond
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Problem with Python when running oe-init-build-env

[Raymond Yeung]

I'd just git cloned Rocko and meta-ti.  When I try to source oe-init-build-env, 
I got errors:


-bash: python3: command not found

BitBake requires Python 3.4.0 or later as 'python3'.  "python -V" gives "Python 
2.7.9".  "python3" is not in $PATH.  I'd followed some detailed online 
description to install Python 3.6 on CentOS 7.  However, after installation, it 
looks like I need to invoke it with python3.6.


How does this work now?  I suppose the oe-init-build-env script uses/expects 
python3, not python3.6.


Any insight?


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

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Andre McCurdy]

On Tue, May 1, 2018 at 4:59 PM, Paul Eggleton
 wrote:
> On Wednesday, 2 May 2018 11:54:00 AM NZST Andre McCurdy wrote:
>> On Tue, May 1, 2018 at 3:10 PM, Paul Eggleton
>>  wrote:
>> > On Wednesday, 2 May 2018 12:07:42 AM NZST Burton, Ross wrote:
>> >> The make dependencies come from the ptest packages, so if you disable
>> >> ptest in your DISTRO_FEATURES then those should disappear.
>> >>
>> >> Essentially doing a full build without any GPLv3 software *and* not
>> >> using old releases which are still GPLv2 is tricky.  I can only
>> >> suggest you don't use the meta-gpl2 layer (as you don't want the
>> >> recipes to be used) and use bbappends to disable pieces where
>> >> required.
>> >
>> > We probably need some sort of whitepaper on how to do that, it doesn't
>> > look like our manuals cover it in sufficient detail. Any volunteers ? ;)
>>
>> Does "Blacklist GPLv3, don't use meta-gplv2, fix any issues you may
>> run into" need a whitepaper? Or is there more to it than that?
>
> Apart from "disable ptest" as Ross pointed out, I would assume that's all
> there is to it - but right now aside from asking here there's really no way
> for someone to know that that's the best available way of handling it, so I
> think it's worth documenting somewhere.

Yes, OK. I hadn't realised ptest is enabled by default in poky (!?!).

  
http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?id=9381b2d2bddf9f67cf57b0718cf99e45805125fa
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] gRPC: grpc_cpp_plugin is not included in host sysroot for standard sdk

[Jacob Kaddoura]

Hello,

I am trying to generate an sdk for a Qt project that includes gRPC. I have 
successfully included protobuf compiler (protoc) in the sysroot for the host 
which is used by qmake to compile protobuf stubs.

After sourcing the SDK environment protoc is appearing in my PATH and this 
allows me to generated client stubs with my proto file. However, when I am 
trying to generate server stubs the protoc command requires the grpc_cpp_plugin 
path as an argument. 
The grpc_cpp_plugin is currently not appearing the host sysroot. Currently, the 
plugin seems to be included the in target sysroot but not the host sysroot.

The Qt application recipe currently includes these lines (see grpc-native and 
grpc):
DEPENDS = "qtbase qtsensors qtmultimedia sw-mcu grpc-native"
RDEPENDS_${PN} = "qtbase qtsensors qtmultimedia sw-mcu qtvirtualkeyboard 
qttranslations qtquickcontrols2 qtgraphicaleffects grpc"

I added the following lines to the image which includes this application:
inherit populate_sdk_qt5
TOOLCHAIN_HOST_TASK_append += "nativesdk-protobuf-compiler"
TOOLCHAIN_TARGET_TASK_append += "grpc"

The command I use to generate the SDK is: bitbake -c do_populate_sdk 

 I tried to add "grpc" to the TOOLCHAIN_HOST_TASK_append line, bitbake threw 
the following error:
* opkg_prepare_url_for_install: Couldn't find anything to satisfy 'grpc'.

Am I misunderstanding how to properly include the plugin or does the current 
recipe not support the grpc_cpp_plugin?

Build Configuration:
BB_VERSION   = "1.36.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "intel-corei7-64"
DISTRO   = "poky"
DISTRO_VERSION   = "2.4.2"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta 
meta-poky
meta-yocto-bsp   = "rocko:fdeecc901196bbccd7c5b1ea4268a2cf56764a62"
meta-oe  
meta-networking  
meta-python  = "rocko:dacfa2b1920e285531bec55cd2f08743390aaf57"
meta-intel   = "rocko:7e284b95b45c7ec5c5b5c8cb08122d3b470c0d63"
meta-qt5 = "HEAD:32bb7d18a08d1c48873d7ab6332d4cc3815a4dff"
meta-sbis-bsp
meta-sbis-software   
meta-sbis-app= "rocko:aa9fa139cfc30da53b84c81facd22b958c1f9852"

Note: I had to pull the gRPC recipe from master as it is not included in the 
meta-openembedded rocko branch.

Any help is appreciated!

Regards,
Jacob Kaddoura

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

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Paul Eggleton]

On Wednesday, 2 May 2018 11:54:00 AM NZST Andre McCurdy wrote:
> On Tue, May 1, 2018 at 3:10 PM, Paul Eggleton
>  wrote:
> > On Wednesday, 2 May 2018 12:07:42 AM NZST Burton, Ross wrote:
> >> The make dependencies come from the ptest packages, so if you disable
> >> ptest in your DISTRO_FEATURES then those should disappear.
> >>
> >> Essentially doing a full build without any GPLv3 software *and* not
> >> using old releases which are still GPLv2 is tricky.  I can only
> >> suggest you don't use the meta-gpl2 layer (as you don't want the
> >> recipes to be used) and use bbappends to disable pieces where
> >> required.
> >
> > We probably need some sort of whitepaper on how to do that, it doesn't
> > look like our manuals cover it in sufficient detail. Any volunteers ? ;)
> 
> Does "Blacklist GPLv3, don't use meta-gplv2, fix any issues you may
> run into" need a whitepaper? Or is there more to it than that?

Apart from "disable ptest" as Ross pointed out, I would assume that's all 
there is to it - but right now aside from asking here there's really no way 
for someone to know that that's the best available way of handling it, so I 
think it's worth documenting somewhere.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Andre McCurdy]

On Tue, May 1, 2018 at 3:10 PM, Paul Eggleton
 wrote:
> On Wednesday, 2 May 2018 12:07:42 AM NZST Burton, Ross wrote:
>> The make dependencies come from the ptest packages, so if you disable
>> ptest in your DISTRO_FEATURES then those should disappear.
>>
>> Essentially doing a full build without any GPLv3 software *and* not
>> using old releases which are still GPLv2 is tricky.  I can only
>> suggest you don't use the meta-gpl2 layer (as you don't want the
>> recipes to be used) and use bbappends to disable pieces where
>> required.
>
> We probably need some sort of whitepaper on how to do that, it doesn't look
> like our manuals cover it in sufficient detail. Any volunteers ? ;)

Does "Blacklist GPLv3, don't use meta-gplv2, fix any issues you may
run into" need a whitepaper? Or is there more to it than that?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Paul Eggleton]

On Wednesday, 2 May 2018 12:07:42 AM NZST Burton, Ross wrote:
> The make dependencies come from the ptest packages, so if you disable
> ptest in your DISTRO_FEATURES then those should disappear.
> 
> Essentially doing a full build without any GPLv3 software *and* not
> using old releases which are still GPLv2 is tricky.  I can only
> suggest you don't use the meta-gpl2 layer (as you don't want the
> recipes to be used) and use bbappends to disable pieces where
> required.

We probably need some sort of whitepaper on how to do that, it doesn't look 
like our manuals cover it in sufficient detail. Any volunteers ? ;)

One other thing worth mentioning is that there has been some discussion a 
while ago about a better plan to handle this, in the form of providing a set 
of recipes for BSD-licensed replacements for GPLv3 components built for the 
target instead of old GPLv2 ones. I don't know if anyone is actively working 
on that though.

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)

[Martin Siegumfeldt]

Hi Andrea,



From: Andrea Galbusera 
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  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']

I wonder why this occurs when the recipe is indeed present:

martin@dell:~/work/z7000-distro-zcu102/build$ bitbake-layers  show-recipes 
cppzmq
NOTE: Starting bitbake server...
WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
version of t

Re: [yocto] Need Help for meta-qt5

[Vincent Daanen]

Hi,
Sorry for the late reply, I have to work on other topics..

I found that building qtbase-native would meet my needs but I cannot figure out 
how to build it 'alone' ... if it is possible

I added the file myMeta/recipes-qt/qt5/ qtbase-native_%.bbappend but bitbake 
still build qtbase...
Any idea ?

Thanks 
Vince

-Message d'origine-
De : Zoran Stojsavljevic  
Envoyé : jeudi 19 avril 2018 08:00
À : Vincent Daanen 
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] Need Help for meta-qt5

http://developer.toradex.com/knowledge-base/how-to-set-up-qt-creator-to-cross-compile-for-embedded-linux#contents
http://developer.toradex.com/knowledge-base/board-support-package/openembedded-(core)#Adding_the_Qt5_Layer

Hope this helps,
Zoran
___

On Wed, Apr 18, 2018 at 6:24 PM, Vincent Daanen  
wrote:
> Hi,
>
>
>
> I have to add Qt5 QtCore libs to my image. I know I must use meta-qt5 
> but as I’m not familiar with qt configuration, I simply do not know how to 
> start !
>
> So can someone help me to configure meta-qt5 to simply build and add 
> QtCore to my image ?
>
> Thank you
>
>
>
> Vincent
>
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [layerindex-web][PATCH 000/242] Integrate and improve Recipe Reporting System (cover letter only)

[Paul Eggleton]

Hi Alex,

On Tuesday, 1 May 2018 9:58:03 PM NZST Alexander Kanavin wrote:
> On 05/01/2018 05:23 AM, Paul Eggleton wrote:
> > The Recipe Reporting System (RRS - live instance at
> > http://recipes.yoctoproject.org) was originally developed as a fork of
> > the layer index (live instance at http://layers.openembedded.org) - this
> > set of changes rebases it on top of master and makes the functionality
> > possible to activate for other layers. I've introduced the concept of a
> > "Maintenance Plan" to tie together the recipe maintenance information
> > for one or more layers and used it to replace all the parts that assumed
> > Poky or OE-Core were the repositories/layers being tracked. I've also
> > made it possible again for the application to gather data going back to
> > 1.6 across the python 2/3 divide, and made various cleanups and
> > optimisations in the code.
> 
> Thanks! Is this already taken into use on the recipes.yoctoproject.org?

No, what you see there is still the old version. I haven't discussed it yet 
with Michael but I would propose that once this gets merged and 
layers.openembedded.org is updated, then recipes.yoctoproject.org would simply 
become a redirect to the OE-Core maintenance plan on layers.openembedded.org.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

[yocto] Help with Bitbake: (bitbake-layers show-recipes)

[Luis Martins]

Good afternoon,

The path that lead me to bitbake's recipe building is going to be presented 
next, if the setup isn't important the warnings and errors are highlited in 
green and you can skip it to there.

Similar to this 
thread,
 i'm having some hard time building the openembedded filesystem.
So far I have managed to follow this 
tutorial until the 
"Booting the board" section. After running the board some errors appear during 
the execution:

[Inline image OWAPstImg945310]
[Inline image OWAPstImg953070]

This lead me to follow the "Addendum B: Building the OpenEmbedded filesysytem 
from source"
(I thought this part was optional since in this section "Initialising a 
workspace" it says "The script will guide you through the process of 
initialising your workspace, automatically downloading all relevant source 
files and required binaries.")

I executed this commands with no problems:


/* Create workspace */

/* WARNING: Do *not* create this as a subdirectory of the main Linaro Arm 
Platforms workspace created by `workspace_yy.mm' above */

$ mkdir openembedded

$ cd openembedded

$ export OE_HOME=`pwd`

$ git clone git://git.linaro.org/openembedded/jenkins-setup.git

$ cd $OE_HOME/jenkins-setup

$ git checkout release-YY.MM

$ cd $OE_HOME

$ sudo jenkins-setup/pre-build-root-install-dependencies.sh

$ jenkins-setup/init-and-build.sh

$ cd $OE_HOME/openembedded-core

$ ./oe-init-build-env

/* Add bitbake to your $PATH */

$ export PATH=$OE_HOME/openembedded-core/bitbake/bin:$PATH

But, after running this commands:


$ cd $OE_HOME/build

$ bitbake-layers show-recipes

I get the following Warnings and Errors (from the log file located in the 
directory /Desktop/openembedded/build/tmp-glibc/log/cooker)):


WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb:
 Exception during build_dependencies for do_install

WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb:
 Error during finalise of 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb

WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb:
 Exception during build_dependencies for do_install

WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb:
 Error during finalise of 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb

ERROR: ExpansionError during parsing 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb

Traceback (most recent call last):

bb.data_smart.ExpansionError: Failure expanding variable do_install, expression 
wasoe_runmake 
install_root=/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image
 install

for r in bootparam_prot.x nlm_prot.x rstat.x   yppasswd.x 
klm_prot.x rex.x sm_inter.x mount.x   rusers.x spray.x nfs_prot.x 
rquota.x key_prot.x; do

h=`echo $r|sed -e's,\.x$,.h,'`

install -m 0644 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/git/sunrpc/rpcsvc/$h
 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image//usr/include/rpcsvc/

done

install -Dm 0644 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/etc/ld.so.conf
 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image//etc/ld.so.conf

install -d 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image/usr/lib/locale

make -f 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/generate-supported.mk
 
IN="/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/git/localedata/SUPPORTED"
 
OUT="/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/SUPPORTED"

# get rid of some broken files...

for i in ; do

sed -i "/$i/d" 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/SUPPORTED

done

rm -f 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image/etc/rpc

rm -rf 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image/usr/share/zoneinfo

rm -rf 
/home/lfpm1993/Desktop/openembedded

[yocto] Yocto Project Technical Meeting links

[Stephano Cetola]

The Yocto Project Technical Meeting is about to start.

How To Join:
https://www.yoctoproject.org/monthly-technical-call/

Shared Google Doc:
https://docs.google.com/document/d/1Lr8KgkmmCZ84RF_ThIwnT3WWxMv_tUsHkpRV5PXTd0s/edit?usp=sharing

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

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

[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 recommended that you use a 

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Anuj Mittal]

On 05/01/2018 06:58 PM, Irving ST wrote:
> Hello,
> 
> First time posting, apologies if I miss anything in the community guidelines.
> 
> I had some problems trying to make an image that contains no GPLv3
> (due to corporate requirement) nor old GPLv2 software in meta-gplv2
> (due to lack of support).
> 
> I tried getting a fresh checkout of poky and adding
> INCOMPATIBLE_LICENSE in conf/local.conf , but I got the following
> error:
> 
> ERROR: Nothing RPROVIDES 'make' (but
> /home/irving/srcgit/poky/meta/recipes-core/zlib/zlib_1.2.11.bb,
> /home/irving/srcgit/poky/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
> RDEPENDS on or otherwise requires it)
> make was skipped: it has an incompatible license: GPLv3 & LGPLv2
> 
> I tried adding meta-gplv2 layer to bblayer.conf and the error
> disappears. I was expecting the license restriction to apply to the
> final image only, but my guess is I am also restricted from building
> the cross compilation tools (which seems weird to me).

You can grep the license.manifest in ./tmp/deploy/licenses to see what
is being included in the final image.

I think the poky core-image-minimal image can be built without
meta-gplv2 and non gplv3 components.

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

Re: [yocto] [meta-raspberrypi] Compute Module 3 machine .conf questions

[Andrei Gherzan]

Hi Steve,

On Tue, May 1, 2018 at 12:40 AM, Steve Pavao  wrote:

> Hello,
>
> My company has bought a Raspberry Pi Compute Module 3 for evaluation, and
> I have a 2 questions about the supplied machine .conf files for it.
>
> 1. Should the supplied raspberrypi-cm3.conf file internally refer to the
> Raspberry Pi 3 instead of the Raspberry Pi 2, since the RPi3 is the
> hardware basis of the Compute Module 3?
>

RaspberryPi 3 is currently almost the same as RaspberryPi 2 in terms of
configuration. What is the problem you are facing?


> 2. Should there also be an additional .conf file supplied in the
> meta-raspberry pi layer for a 64-bit version of poky Linux for the Compute
> Module 3, just as there is a raspberrypi3-64 machine .conf for the RPi3?
>

You can use directly raspberrypi3-64 as far as I am aware. The cm confs are
used as aliases right now. They point to one of the Raspberrypi 2 or 3
machine configurations.

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

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Burton, Ross]

The make dependencies come from the ptest packages, so if you disable
ptest in your DISTRO_FEATURES then those should disappear.

Essentially doing a full build without any GPLv3 software *and* not
using old releases which are still GPLv2 is tricky.  I can only
suggest you don't use the meta-gpl2 layer (as you don't want the
recipes to be used) and use bbappends to disable pieces where
required.

Ross

On 1 May 2018 at 11:58, Irving ST  wrote:
> Hello,
>
> First time posting, apologies if I miss anything in the community guidelines.
>
> I had some problems trying to make an image that contains no GPLv3
> (due to corporate requirement) nor old GPLv2 software in meta-gplv2
> (due to lack of support).
>
> I tried getting a fresh checkout of poky and adding
> INCOMPATIBLE_LICENSE in conf/local.conf , but I got the following
> error:
>
> ERROR: Nothing RPROVIDES 'make' (but
> /home/irving/srcgit/poky/meta/recipes-core/zlib/zlib_1.2.11.bb,
> /home/irving/srcgit/poky/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
> RDEPENDS on or otherwise requires it)
> make was skipped: it has an incompatible license: GPLv3 & LGPLv2
>
> I tried adding meta-gplv2 layer to bblayer.conf and the error
> disappears. I was expecting the license restriction to apply to the
> final image only, but my guess is I am also restricted from building
> the cross compilation tools (which seems weird to me).
>
> Is this layer required when building without GPLv3?
> Is there any alternative I can try, or is my choice limited to either
> using GPLv3 code vs outdated GPLv2 code?
> If I have to use the meta-gplv2 layer, is there a way to restrict
> anything inside this layer from being built into the image?
>
> I tried to look for information on building a busybox-based image (vs
> a GNU coreutils-based image) in the mega manual but didn’t find
> anything specific.
>
> Regards,
> Irving
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Irving ST]

Hello,

First time posting, apologies if I miss anything in the community guidelines.

I had some problems trying to make an image that contains no GPLv3
(due to corporate requirement) nor old GPLv2 software in meta-gplv2
(due to lack of support).

I tried getting a fresh checkout of poky and adding
INCOMPATIBLE_LICENSE in conf/local.conf , but I got the following
error:

ERROR: Nothing RPROVIDES 'make' (but
/home/irving/srcgit/poky/meta/recipes-core/zlib/zlib_1.2.11.bb,
/home/irving/srcgit/poky/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
RDEPENDS on or otherwise requires it)
make was skipped: it has an incompatible license: GPLv3 & LGPLv2

I tried adding meta-gplv2 layer to bblayer.conf and the error
disappears. I was expecting the license restriction to apply to the
final image only, but my guess is I am also restricted from building
the cross compilation tools (which seems weird to me).

Is this layer required when building without GPLv3?
Is there any alternative I can try, or is my choice limited to either
using GPLv3 code vs outdated GPLv2 code?
If I have to use the meta-gplv2 layer, is there a way to restrict
anything inside this layer from being built into the image?

I tried to look for information on building a busybox-based image (vs
a GNU coreutils-based image) in the mega manual but didn’t find
anything specific.

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

Re: [yocto] [layerindex-web][PATCH 000/242] Integrate and improve Recipe Reporting System (cover letter only)

[Alexander Kanavin]

On 05/01/2018 05:23 AM, Paul Eggleton wrote:

The Recipe Reporting System (RRS - live instance at
http://recipes.yoctoproject.org) was originally developed as a fork of
the layer index (live instance at http://layers.openembedded.org) - this
set of changes rebases it on top of master and makes the functionality
possible to activate for other layers. I've introduced the concept of a
"Maintenance Plan" to tie together the recipe maintenance information
for one or more layers and used it to replace all the parts that assumed
Poky or OE-Core were the repositories/layers being tracked. I've also
made it possible again for the application to gather data going back to
1.6 across the python 2/3 divide, and made various cleanups and
optimisations in the code.


Thanks! Is this already taken into use on the recipes.yoctoproject.org?

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