Re: [yocto] yocto jethro failed on gettext-native

[Zoran Stojsavljevic]

Hello Paul,

Could you, please, read couple of times more my quoted comment (by you)?
Stress to word: *couple*! ;-)

> Now, I must admit, I have learned something new. Never gave any
> consideration to these releases: example: Pyro 17.0.3.
>
>* But now I understand: it has direct link with Ubuntu 17... Even, YOCTO*
> *Pyro, as given example, can be substituted with Ubuntu 17.04?! Wow... *

Thank you,
Zoran
___

On Wed, May 2, 2018 at 10:36 PM, Paul Barker  wrote:

> On Wed, 25 Apr 2018, at 21:55, Zoran Stojsavljevic wrote:
> > > Jethro doesn't support Yocto 16.* because it is very old (released
> 2015...)...
> >
> > Now, I must admit, I have learned something new. Never gave any
> > consideration to these releases: example: Pyro 17.0.3.
> >
> > But now I understand: it has direct link with Ubuntu 17... Even, YOCTO
> > Pyro, as given example, can be substituted with Ubuntu 17.04?! Wow...
> >
> > Every day in every way, I'm progressing more and more! ;-)
> >
>
> You seem to be a bit confused here by the fact that the poky version
> number lined up with the year in 2017. See https://wiki.yoctoproject.org/
> wiki/Releases for some context.
>
> --
> Paul Barker
> Beta Five Ltd
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't compile out of tree kernel module when CONFIG_SYSTEM_TRUSTED_KEYRING is set in the kernel configuration

[Bruce Ashfield]

On Wed, May 2, 2018 at 5:05 PM, Martin Townsend 
wrote:

> Hi,
>
> I get the following error when compiling a kernel module using the
> latest version of Rocko (The kernel is not linux-yocto but NXP's
> freescale linux-imx, maybe this could be a factor) :
>
> ERROR: kernel-module-driver-0.1-r0 do_make_scripts: Function failed:
> do_make_scripts (log file is located at
> /ws/yocto-rocko/build/tmp/work/mach_1717-linux-gnueabi/
> kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703)
> ERROR: Logfile of failure stored in:
> /ws/yocto-rocko/build/tmp/work/mach_1717-cwr-linux-
> gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703
> Log data follows:
> | DEBUG: Executing shell function do_make_scripts
> | make: Entering directory
> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source'
> | make[1]: Entering directory
> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-
> 1717/kernel-build-artifacts'
> |   HOSTCC  scripts/extract-cert
> | /ws/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-
> source/scripts/extract-cert.c:21:25:
> fatal error: openssl/bio.h: No such file or directory
> | compilation terminated.
> | scripts/Makefile.host:107: recipe for target 'scripts/extract-cert'
> failed
> | make[2]: *** [scripts/extract-cert] Error 1
> | /ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/
> kernel-source/Makefile:560:
> recipe for target 'scripts' failed
> |
>
> I checked the makefile and extract-cert is only compiled if
> CONFIG_SYSTEM_TRUSTED_KEYRING is set which we have.
>
>  I could install libssl-dev but it doesn't feel right installing this
> and it's not in the system requirements plus the file openssl/bio.h is
> in the recipe-sysroot-native directory of the kernel module WORK_DIR.
>

I've run into this plenty of times with newer kernels (4.14+), which is why
all the linux-yocto recipes have:


DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
DEPENDS += "openssl-native util-linux-native"

As does my re-worked kernel-devsrc.

So yah, you can just add the dependency to fix the problem.

Bruce


>
>
> Any help would be greatly appreciated,
> Marin.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Steve Pavao]

Hi Andrei,

We were able to verify that we could directly use the raspberrypi3-64.conf for 
the cm3 as 64-bit, as you had suggested.  Thanks for that suggestion.

It just seemed a bit confusing that there is only one cm3 machine conf, and it 
tunnels through to a rpi2.  All the online doc about the cm3 mentions the rpi3. 
 A colleague wonders if there are any differences that 
someone was planning to eventually use that cm3 conf to enumerate, otherwise - 
having a cm3 conf seems like unnecessary duplication.

Thanks again for your help!

- Steve Pavao
Korg R


> On May 1, 2018, at 9:39 AM, Andrei Gherzan  wrote:
> 
> 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] Recipe availability through eSDK (cppzmq)

[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

[yocto] Can't compile out of tree kernel module when CONFIG_SYSTEM_TRUSTED_KEYRING is set in the kernel configuration

[Martin Townsend]

Hi,

I get the following error when compiling a kernel module using the
latest version of Rocko (The kernel is not linux-yocto but NXP's
freescale linux-imx, maybe this could be a factor) :

ERROR: kernel-module-driver-0.1-r0 do_make_scripts: Function failed:
do_make_scripts (log file is located at
/ws/yocto-rocko/build/tmp/work/mach_1717-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703)
ERROR: Logfile of failure stored in:
/ws/yocto-rocko/build/tmp/work/mach_1717-cwr-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703
Log data follows:
| DEBUG: Executing shell function do_make_scripts
| make: Entering directory
'/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source'
| make[1]: Entering directory
'/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-build-artifacts'
|   HOSTCC  scripts/extract-cert
| 
/ws/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/scripts/extract-cert.c:21:25:
fatal error: openssl/bio.h: No such file or directory
| compilation terminated.
| scripts/Makefile.host:107: recipe for target 'scripts/extract-cert' failed
| make[2]: *** [scripts/extract-cert] Error 1
| 
/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/Makefile:560:
recipe for target 'scripts' failed
|

I checked the makefile and extract-cert is only compiled if
CONFIG_SYSTEM_TRUSTED_KEYRING is set which we have.

 I could install libssl-dev but it doesn't feel right installing this
and it's not in the system requirements plus the file openssl/bio.h is
in the recipe-sysroot-native directory of the kernel module WORK_DIR.


Any help would be greatly appreciated,
Marin.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Paul Barker]

On Wed, 2 May 2018, at 21:17, Zoran Stojsavljevic wrote:
> Hello Raymond,
> 
> YOCTO is, per say, moving target. If you have YOCTO Krogoth, you should
> have somehow frozen host Centos 7 release around this time. As you now
> moving to Rocko, you need to fast-forward the whole host Centos 7 (in other
> words to upgrade Centos 7) to this state (maybe to latest, it'll still
> work, I guess).

Sorry, I'd say this is wrong. Centos is a pretty stable base and I wouldn't 
expect backwards incompatible changes to be made within a stable release 
series. So if a Yocto release worked on a given Centos version (say Centos 7) 
at the time of release, it should still work now.

Advising people to "freeze" their host system and stop taking security/bugfix 
updates pushed by their distro is a bad idea.

-- 
Paul Barker
Beta Five Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto jethro failed on gettext-native

[Paul Barker]

On Wed, 25 Apr 2018, at 21:55, Zoran Stojsavljevic wrote:
> > Jethro doesn't support Yocto 16.* because it is very old (released 
> > 2015...)...
> 
> Now, I must admit, I have learned something new. Never gave any
> consideration to these releases: example: Pyro 17.0.3.
> 
> But now I understand: it has direct link with Ubuntu 17... Even, YOCTO
> Pyro, as given example, can be substituted with Ubuntu 17.04?! Wow...
> 
> Every day in every way, I'm progressing more and more! ;-)
> 

You seem to be a bit confused here by the fact that the poky version number 
lined up with the year in 2017. See https://wiki.yoctoproject.org/wiki/Releases 
for some context.

-- 
Paul Barker
Beta Five Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Zoran Stojsavljevic]

Hello Raymond,

YOCTO is, per say, moving target. If you have YOCTO Krogoth, you should
have somehow frozen host Centos 7 release around this time. As you now
moving to Rocko, you need to fast-forward the whole host Centos 7 (in other
words to upgrade Centos 7) to this state (maybe to latest, it'll still
work, I guess).

Not familiar with Centos distro, really... :-(

This is a good point to mention that you, Raymond, or anybody else, need to
give to YOCTO mailing list more info about what is going on with your
setup, since we are here guessing, in The Dark. You gave one parameter
less, then it is as solving two equations with three unknown variables (so
it is pure [un]educated guess out of Blue).

All Good, after all, you solved your problem! :-)

Zoran
___

On Wed, May 2, 2018 at 9:28 PM, Raymond Yeung  wrote:

> Thanks Zoran.
>
>
> My Linux build machine uses Centos 7.  I thought I'd done the installation
> to Python 3.6.5.  If this is not Python3 > 3.4.0, then I'm confused.  The
> link I follow for installation is here:  https://janikarhunen.fi/how-
> to-install-python-3-6-1-on-centos-7.html
>
> > python3.6 -V
>
> Python 3.6.5
>
> >python -V
>
> Python 2.7.5
>
>
> Anyway, I realize what went wrong.  I'd Krogoth (a 2016 Poky) running
> before.  Now as I'm migrating to Rocko (a 2017 Poky), I try to solve a
> Python versioning issue by installing Python only (as above).  However,
> there may be other packages I need to update.  After getting latest
> Reference Manual, download and install latest environment, I no longer have
> python3 issue.  However, the Python version of why Python3.6 won't satisfy
> Python > 3.4.0 still puzzles me (though no longer blocking me).
>
>
> Raymond
>
>
> --
> *From:* Zoran Stojsavljevic 
> *Sent:* Tuesday, May 1, 2018 11:19 PM
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Problem with Python when running oe-init-build-env
>
> 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 Info Page 
> lists.yoctoproject.org
> Discussion of all things about the Yocto Project. Read our Community
> Guidelines or learn more about how to participate in other community
> discussions. Subscribe before posting to bypass moderation.
>
>
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Burton, Ross]

On 2 May 2018 at 14:58, Alexander Kanavin  wrote:

> On 05/02/2018 04:53 PM, Irving ST wrote:
>
>> Thank you for your help and explanations. Unfortunately just removing
>> ptest doesn't make it build.
>> This is the error when I tried bitbake core-image-minimal:
>>
>> ERROR: Nothing PROVIDES 'readline' (but
>> /home/irving/srcgit/poky/meta/recipes-devtools/python/python3_3.5.5.bb
>> ERROR: Nothing PROVIDES 'gdbm' (but
>> /home/irving/srcgit/poky/meta/recipes-devtools/python/python3_3.5.5.bb,
>> /home/irving/srcgit/poky/meta/recipes-devtools/perl/perl_5.24.1.bb
>> DEPENDS on or otherwise requires it)
>>
>
> 'readline' dependency can be easily disabled in python via PACKAGECONFIG.
> gdbm might be trickier, but I believe it's optional as well.
>

Note that this readline PACKAGECONFIG is in sumo/master, so you'll need to
cherrypick it if you're not using that.

gdbm is a little more fiddly but it can be done, I had a proof of concept
but didn't finish it.  Start by removing gdbm from DEPENDS in a bbappend
and see what breaks...

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

[yocto] Splash screen using systemd

[Damien LEFEVRE]

Hi,

I'm working on an NVidia Jetson board with a TX2 module and I would like to
have splash screen with a progress bar when booting and shutting down. The
board boots to an application embedded style. There's no desktop and no
user login.

The configuration I use makes use of systemd.

I gave a try to psplash but by now I have realized that it is not
compatible with systemd. The image is displayed but I don't get progress
information.

Next try with dietsplash. The splash screen isn't displayed and I just have
a black screen when booting. If I manually run /bin/dietsplash I lose
control over the keyboard and the penguin isn't displayed.

The dietsplash doc https://github.com/lucasdemarchi/dietsplash/tree/v0.3
mentions to add 'init=/bin/dietsplash' to the kernel command line.

What would be the way to I add it?

Last try plymouth. An error comes during the boot and the splash screen
doesn't show:
[   OK] Started Show Plymouth Boot Screen.
[FAILED] Failed to start Forward Passwrod Requests to Plymouth Directory
Watch.
See 'systemctl status systemd-ask-password-plymouth.path' for details

systemctl status gives me:
● systemd-ask-password-plymouth.path - Forward Password Requests to
Plymouth Directory Watch
   Loaded: loaded (/lib/systemd/system/systemd-ask-password-plymouth.path;
static; vendor preset: enabled)
   Active: inactive (dead)
 Docs: http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

May 02 14:34:10 jetson-tx2 systemd[1]:
[[0;1;31msystemd-ask-password-plymouth.path: Refusing to start, unit to
trigger not loaded.[[0m
May 02 14:34:10 jetson-tx2 systemd[1]: [[0;1;31mFailed to start Forward
Password Requests to Plymouth Directory Watch.[[0m

Any hint would be greatly appreciated :D

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

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

[Andrea Galbusera]

On Wed, May 2, 2018 at 2:33 PM, Martin Siegumfeldt  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 
> 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  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 
>> 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%
>>> 

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

[Alexander Kanavin]

On 05/02/2018 04:53 PM, Irving ST wrote:

Thank you for your help and explanations. Unfortunately just removing
ptest doesn't make it build.
This is the error when I tried bitbake core-image-minimal:

ERROR: Nothing PROVIDES 'readline' (but
/home/irving/srcgit/poky/meta/recipes-devtools/python/python3_3.5.5.bb
ERROR: Nothing PROVIDES 'gdbm' (but
/home/irving/srcgit/poky/meta/recipes-devtools/python/python3_3.5.5.bb,
/home/irving/srcgit/poky/meta/recipes-devtools/perl/perl_5.24.1.bb
DEPENDS on or otherwise requires it)


'readline' dependency can be easily disabled in python via 
PACKAGECONFIG. gdbm might be trickier, but I believe it's optional as well.


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

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

[Irving ST]

On Wed, May 2, 2018 at 7:01 PM, Burton, Ross  wrote:
> On 2 May 2018 at 01:41, Andre McCurdy  wrote:
>> 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
>
> Poky is primarily a vehicle for testing the Yocto Project software, so
> it follows that it enables ptest for QA purposes.
>
> Ross

Hi all,

Thank you for your help and explanations. Unfortunately just removing
ptest doesn't make it build.
This is the error when I tried bitbake core-image-minimal:

ERROR: Nothing PROVIDES 'readline' (but
/home/irving/srcgit/poky/meta/recipes-devtools/python/python3_3.5.5.bb
DEPENDS on or otherwise requires it)
readline was skipped: it has an incompatible license: GPLv3+
NOTE: Runtime target 'nativesdk-dnf' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-dnf',
'nativesdk-librepo', 'nativesdk-python3', 'python3', 'readline']
NOTE: Runtime target 'nativesdk-packagegroup-sdk-host' is unbuildable,
removing...
Missing or unbuildable dependency chain was:
['nativesdk-packagegroup-sdk-host', 'nativesdk-dnf',
'nativesdk-librepo', 'nativesdk-python3', 'python3', 'readline']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal',
'nativesdk-packagegroup-sdk-host', 'nativesdk-dnf',
'nativesdk-librepo', 'nativesdk-python3', 'python3', 'readline']


This is the error when I tried bitbake core-image-base:

ERROR: Nothing PROVIDES 'gdbm' (but
/home/irving/srcgit/poky/meta/recipes-devtools/python/python3_3.5.5.bb,
/home/irving/srcgit/poky/meta/recipes-devtools/perl/perl_5.24.1.bb
DEPENDS on or otherwise requires it)
gdbm was skipped: it has an incompatible license: GPLv3
NOTE: Runtime target 'gdb-cross-canadian-i586' is unbuildable, removing...
Missing or unbuildable dependency chain was:
['gdb-cross-canadian-i586', 'nativesdk-python3', 'python3', 'gdbm']
NOTE: Runtime target 'packagegroup-cross-canadian-qemux86' is
unbuildable, removing...
Missing or unbuildable dependency chain was:
['packagegroup-cross-canadian-qemux86', 'gdb-cross-canadian-i586',
'nativesdk-python3', 'python3', 'gdbm']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base',
'packagegroup-cross-canadian-qemux86', 'gdb-cross-canadian-i586',
'nativesdk-python3', 'python3', 'gdbm']

Since doing this seems trickier than I expected then I might have to
develop with meta-gplv2 for now and revisit this at a later date.

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

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

[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 
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  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 
> 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%
>> 

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

[Andrea Galbusera]

On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt  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 
> 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 

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

[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 
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 

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

[Andrea Galbusera]

Martin,

On Tue, May 1, 2018 at 8:49 PM, Martin Siegumfeldt  wrote:
> 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)

Again, look at the recipe source! This is expected behaviour. There is
no 'cppzmq' package at all. So, regardless how hard you try to add a
package with such a name in your image, bitbake is expected to fail
with the error above. The only valid package that cppzmq recipe is
providing is called 'cppzmq-dev'. Also note 

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