Re: [yocto] layerindex

[Paul Eggleton]

On Thursday 04 June 2015 15:54:18 Nathan Rossi wrote:
> On Thu, Jun 4, 2015 at 8:34 AM, Trevor Woerner  wrote:
> > Hi,
> > 
> > Does the layer index provide a REST api?
> 
> http://layers.openembedded.org/layerindex/api/
> 
> It is self documented to some degree :).
> 
> > -or-
> > 
> > Would (could) it be possible to somehow grab/access the data that drives
> > the layer index (preferably without scraping)?
> 
> The "bitbake-layers" tool might also be of interest as accesses this api:
> http://git.openembedded.org/bitbake/tree/bin/bitbake-layers#n261

Indeed - and if you need anything else of the API. please file enhancement 
requests in bugzilla - or if you're really keen you can send patches, the code 
is here:

  http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa15 toolchain compilation option (Neelkumar Patel)

[Taek Hyun Shin]

If we do not provide that option (arm-XXX-gcc  hello.c ) then it gives below 
error.
fatal error: gnu/stubs-soft.h: No such file or directory

=> your toolchain support only hard fpu
if you want to use softfp , you must change your toolchain

do you use linaro-toolchain gcc-4.9??? 

linaro-toolchain gcc-4.9 only hard fpu


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of yocto-requ...@yoctoproject.org
Sent: Monday, June 01, 2015 11:48 PM
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 57, Issue 1

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

   1. Re: cortexa15 toolchain compilation option (Neelkumar Patel)
   2. Strange configure error (???) (Neuer User)
   3. Re: build hello_world.c in yocto (Victor Rodriguez)
   4. Re: build hello_world.c in yocto (Burton, Ross)
   5. Multi recipes for different defconfig on the same kernel
  source (Joel (Xi Zhou) Zhou)


--

Message: 1
Date: Mon, 1 Jun 2015 07:02:33 +
From: Neelkumar Patel 
To: "yocto@yoctoproject.org" 
Subject: Re: [yocto] cortexa15 toolchain compilation option
Message-ID:



Content-Type: text/plain; charset="us-ascii"

Hi,

Sorry option is  -mfloat-abi=hard.

We have to provide below option during compilation.
arm-XXX-gcc  -mfloat-abi=hard hello.c

We do not want to give -mfloat-abi=hard option during compilation.

If we do not provide that option (arm-XXX-gcc  hello.c ) then it gives below 
error.
fatal error: gnu/stubs-soft.h: No such file or directory

Thanks
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Neelkumar Patel
Sent: 01 June 2015 12:04
To: yocto@yoctoproject.org
Subject: [yocto] cortexa15 toolchain compilation option

Hi,

We are building the toolchain for cortexa15 CPU in oe-core and we are able to 
build the toolchain but during the compilation of the application we have to 
provide manually option "--with-float=hard".

e.g.  We have one application called "hello.c". We have to provide below option 
for compilation. If we do not provide --with-float option then we are getting 
compilation error.

arm-XXX-gcc  --with-float=hard  hello.c

Is there any option to remove "-with-float" option during the application 
compilation. Is there any change we have to do in oe-core ??

Thanks in Advance.

*
 eInfochips Business Disclaimer: This e-mail message and all attachments 
transmitted with it are intended solely for the use of the addressee and may 
contain legally privileged and confidential information. If the reader of this 
message is not the intended recipient, or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, or other use of this message or its 
attachments is strictly prohibited. If you have received this message in error, 
please notify the sender immediately by replying to this message and please 
delete it from your computer. Any views expressed in this message are those of 
the individual sender unless otherwise stated. Company has taken enough 
precautions to prevent the spread of viruses. However the co
   mpany accepts no liability for any damage caused by any virus transmitted by 
this email. 
*
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Mon, 01 Jun 2015 11:23:19 +0200
From: Neuer User 
To: yocto@yoctoproject.org
Subject: [yocto] Strange configure error (???)
Message-ID: 
Content-Type: text/plain; charset=utf-8

Hi

I'm currently moving from Dora to Fido. I moved all my recipes to a new yocto 
installation and are modifying the recipes where necessary.

I have a very strange error when configuring a kernel recipe (linux-cubox-i). 
Actually, there is no error when using the defaut recipe included in fido. Only 
if I add the following bbappend file in order to change the kernel 
configuration, I get the error:

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-cubox-i:"

SRC_URI = "fi

[yocto] Removing rootfs from SDK

[John Ernberg]

Hi

We're trying to optimize the SDK generated by bitbake -c populate_sdk.
Currently we're trying to remove the kernel, modules and other 
executables which we have no use for, most of it could be removed using 
IMAGE_INSTALL = "" and IMAGE_FEATURES = "".

Due to us using 2 different kernel module sets, we're using 
IMAGE_INSTALL_append_[machine] additions to IMAGE_INSTALL which are not 
cleared by the IMAGE_INSTALL = "" setting.

I've tried to do IMAGE_INSTALL_remove using the same variable that we 
use to populate the IMAGE_INSTALL_append, but that doesn't work. I can 
however remove each individual package added by IMAGE_INSTALL_append.
Due to the number of packages added by IMAGE_INSTALL_append this is not 
really feasible.

Is there a way to clear IMAGE_INSTALL_append without doing an 
IMAGE_INSTALL_remove per package? Alternatively clearing it using a 
python loop without needing to know the name of each package.

We're also seeing busybox getting included into the SDK without anything 
showing a dependency on it from running bitbake -g -c populate_sdk.

What could be going on with that?

We're using poky daisy 11 and Yocto 1.6.1.

Thank you in advance.

Best regards // John Ernberg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Library not getting installed to intended path

[Burton, Ross]

On 4 June 2015 at 05:14, Yogesh Tyagi  wrote:

> I am using yocto 1.6 and I have written a component and written bitbake
> recipe file for this component. When rootfs is created my library is found
> in "/lib" directory but I want it to be installed to "/lib/gstreamer-0.10"
> directory (which is already created by open source gstreamer packages).
>
>
The path created by the GStreamer packages is /usr/lib/gstreamer-0.10,
unless you've been changing $prefix.

Your Makefile.am should have something like this:

# Plugins go in a subdirectory of libdir
plugindir=$(libdir)/gstreamer-0.10
plugin_LTLIBRARIES=libsomething.la
libsomething_la_SOURCES = something.c
# This is a module not a library, and don't version it
libsomething_la_LDFLAGS = -module -avoid-version

$(libdir) is turned into a real path by configure, and the autotools class
will pass the correct path to use.  Your recipe should then:

inherit autotools
FILES_${PN} = ${libdir}/gstreamer-0.10/*.so

At no point do you need to set libdir yourself, as the autotools class will
pass the right value from your distro configuration to the configure
script, which sets the right value in the Makefile.

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

[yocto] Kernel config fragments are no longer applied after update to Fido

[Neuer User]

Hello

I have the following kernel recipe, which is based on some help from
Bruce Ashfield last year:

-
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

SUMMARY = "Linaro Kernel 3.14 with additional machine specific patches"

SRCREV = "91d5e90284ee69d219872e3ae42ae0eac417f7e9"
LOCALVERSION = "-cubox-i+linux4kix+${SRCPV}"

DEPENDS += "lzop-native bc-native"

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-cubox-i:"

SRC_URI = "file://defconfig \
   file://videoin.cfg \
   file://dvb.cfg \
   file://networking.cfg \
   file://wlan.cfg \
   file://dm-crypt.cfg \
   file://no-caam.cfg \
   file://leds.cfg \
   file://mod-to-builtin.cfg \
   file://watchdog-nowayout.cfg \
   file://brcmfmac4330-sdio.bin \
   file://brcmfmac4330-sdio.txt \
"

SRC_URI +=
"git://github.com/linux4kix/linux-linaro-stable-mx6.git;branch=${SRCBRANCH}"
SRCBRANCH ?= "linux-linaro-lsk-v3.14-mx6"

COMPATIBLE_MACHINE = "(cubox-i)"

KERNEL_IMAGETYPE_cubox-i = "zImage"

SRCREV_machine = "${SRCREV}"
--


This worked nicely under yocto daisy. Now, after I migrated my recipes
to yocto fido, the recipe no longer seems to include the kernel
fragments, i.e. everything runs without errors, but the fragments are
not applied. (They are, however, copied to the build directory.)

Any idea, what the problem is or how to debug/solve it?

Thanks in advance

Michael

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

[yocto] [meta-raspberrypi] Issue with 8250/16550 UART1 access in raspberrypi (meta-raspberrypi)

[Andreas Enbacka]

Hello,

 

After a long break, I have returned to the Yocto project, and generally very
pleased. A lot of progress has been done since I last used the project (two
years ago), and now in my opinion everything works very smoothly.

 

I have used yocto to build a custom image for the RaspberryPi Compute
Module. Generally everything works ok, however I am experiencing problem
with accessing the UART1 port on the raspberryPi. I am using a library
called wiringPi to put the appropriate GPIO pins in the correct mode (alt5)
for RXD1/TXD1 (pins 32/33). Also I have used menuconfig to enable the
8250/16550 serial port support in the kernel (3.18.5+). After booting the
image I examined the dmesg output, and it shows following information
related to 8250/16550:

..

[   1.010958] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

[   1.013920] serial8250.0: ttyS0 at MMIO 0x20215040 (irq = 29, base_baud =
7812500) is a 8250

.

 

Then I put the pins 32/33 into alternative mode alt5, and try to connect to
the port /dev/ttyS0 using minicom (baud 115200). Trying to enter something
into the Mincom terminal does not give any indications on our connected
oscilloscope (connected to the relevant pins), however change of the alt
mode earlier was observed correctly. The serial port should not be using any
flow control, but when trying to disable the flow control using Minicom (it
was on by default) freezes the complete RaspberryPi system (requiring to
disconnect and reconnect power).

 

Does anyone have any thoughts what could be the cause of these issues (e.g.,
problems with driver etc)? Any information would be greatly appreciated. In
the project we are working on we would need to use both uart ports (0/1)
provided by the compute module (the uart0 is a pl011 and by disabling
console use of /dev/ttyAMA0 we were able to successfully connect to that
port).

 

Thanks for the great work with the Yocto platform.

 

Sincerely,

Andreas Enbacka

SW designer

Gasera Ltd

 

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

Re: [yocto] Kernel config fragments are no longer applied after update to Fido

[Bruce Ashfield]

On Thu, Jun 4, 2015 at 6:47 AM, Neuer User  wrote:
> Hello
>
> I have the following kernel recipe, which is based on some help from
> Bruce Ashfield last year:
>
> -
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> SUMMARY = "Linaro Kernel 3.14 with additional machine specific patches"
>
> SRCREV = "91d5e90284ee69d219872e3ae42ae0eac417f7e9"
> LOCALVERSION = "-cubox-i+linux4kix+${SRCPV}"
>
> DEPENDS += "lzop-native bc-native"
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/linux-cubox-i:"
>
> SRC_URI = "file://defconfig \
>file://videoin.cfg \
>file://dvb.cfg \
>file://networking.cfg \
>file://wlan.cfg \
>file://dm-crypt.cfg \
>file://no-caam.cfg \
>file://leds.cfg \
>file://mod-to-builtin.cfg \
>file://watchdog-nowayout.cfg \
>file://brcmfmac4330-sdio.bin \
>file://brcmfmac4330-sdio.txt \
> "
>
> SRC_URI +=
> "git://github.com/linux4kix/linux-linaro-stable-mx6.git;branch=${SRCBRANCH}"
> SRCBRANCH ?= "linux-linaro-lsk-v3.14-mx6"
>
> COMPATIBLE_MACHINE = "(cubox-i)"
>
> KERNEL_IMAGETYPE_cubox-i = "zImage"
>
> SRCREV_machine = "${SRCREV}"
> --
>
>
> This worked nicely under yocto daisy. Now, after I migrated my recipes
> to yocto fido, the recipe no longer seems to include the kernel
> fragments, i.e. everything runs without errors, but the fragments are
> not applied. (They are, however, copied to the build directory.)
>
> Any idea, what the problem is or how to debug/solve it?

The transition should have been seamless .. this is something that
works here and
something that was obviously tested as part of the release.

Is there somewhere that I can get a copy of the layer you are using
for your BSP ?
Otherwise, let me hack something up and try my own build.

Bruce

>
> Thanks in advance
>
> Michael
>
> --
> ___
> 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] Issue with 8250/16550 UART1 access in raspberrypi (meta-raspberrypi)

[Valentin Le bescond]

Hi !

I'm really no expert but am very interested in the subject.

Did you modify the device tree ? From what I understand in the DT that
you'll find pinmux definition right ?

Regards.


2015-06-04 14:01 GMT+02:00 Andreas Enbacka :

> Hello,
>
>
>
> After a long break, I have returned to the Yocto project, and generally
> very pleased. A lot of progress has been done since I last used the project
> (two years ago), and now in my opinion everything works very smoothly.
>
>
>
> I have used yocto to build a custom image for the RaspberryPi Compute
> Module. Generally everything works ok, however I am experiencing problem
> with accessing the UART1 port on the raspberryPi. I am using a library
> called wiringPi to put the appropriate GPIO pins in the correct mode (alt5)
> for RXD1/TXD1 (pins 32/33). Also I have used menuconfig to enable the
> 8250/16550 serial port support in the kernel (3.18.5+). After booting the
> image I examined the dmesg output, and it shows following information
> related to 8250/16550:
>
> ..
>
> [   1.010958] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>
> [   1.013920] serial8250.0: ttyS0 at MMIO 0x20215040 (irq = 29, base_baud
> = 7812500) is a 8250
>
> …
>
>
>
> Then I put the pins 32/33 into alternative mode alt5, and try to connect
> to the port /dev/ttyS0 using minicom (baud 115200). Trying to enter
> something into the Mincom terminal does not give any indications on our
> connected oscilloscope (connected to the relevant pins), however change of
> the alt mode earlier was observed correctly. The serial port should not be
> using any flow control, but when trying to disable the flow control using
> Minicom (it was on by default) freezes the complete RaspberryPi system
> (requiring to disconnect and reconnect power).
>
>
>
> Does anyone have any thoughts what could be the cause of these issues
> (e.g., problems with driver etc)? Any information would be greatly
> appreciated. In the project we are working on we would need to use both
> uart ports (0/1) provided by the compute module (the uart0 is a pl011 and
> by disabling console use of /dev/ttyAMA0 we were able to successfully
> connect to that port).
>
>
>
> Thanks for the great work with the Yocto platform.
>
>
>
> Sincerely,
>
> Andreas Enbacka
>
> SW designer
>
> Gasera Ltd
>
>
>
> --
> ___
> 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] [meta-raspberrypi] Issue with 8250/16550 UART1 access in raspberrypi (meta-raspberrypi)

[Andreas Enbacka]

Hello Valentin,

I used the wiringPi library to put the pins into the alternative mode. 

Regards,
Andreas

> 4 jun 2015 kl. 15:31 skrev Valentin Le bescond :
> 
> Hi !
> 
> I'm really no expert but am very interested in the subject.
> 
> Did you modify the device tree ? From what I understand in the DT that you'll 
> find pinmux definition right ?
> 
> Regards.
> 
> 
> 2015-06-04 14:01 GMT+02:00 Andreas Enbacka :
>> Hello,
>> 
>>  
>> 
>> After a long break, I have returned to the Yocto project, and generally very 
>> pleased. A lot of progress has been done since I last used the project (two 
>> years ago), and now in my opinion everything works very smoothly.
>> 
>>  
>> 
>> I have used yocto to build a custom image for the RaspberryPi Compute 
>> Module. Generally everything works ok, however I am experiencing problem 
>> with accessing the UART1 port on the raspberryPi. I am using a library 
>> called wiringPi to put the appropriate GPIO pins in the correct mode (alt5) 
>> for RXD1/TXD1 (pins 32/33). Also I have used menuconfig to enable the 
>> 8250/16550 serial port support in the kernel (3.18.5+). After booting the 
>> image I examined the dmesg output, and it shows following information 
>> related to 8250/16550:
>> 
>> ..
>> 
>> [   1.010958] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> 
>> [   1.013920] serial8250.0: ttyS0 at MMIO 0x20215040 (irq = 29, base_baud = 
>> 7812500) is a 8250
>> 
>> …
>> 
>>  
>> 
>> Then I put the pins 32/33 into alternative mode alt5, and try to connect to 
>> the port /dev/ttyS0 using minicom (baud 115200). Trying to enter something 
>> into the Mincom terminal does not give any indications on our connected 
>> oscilloscope (connected to the relevant pins), however change of the alt 
>> mode earlier was observed correctly. The serial port should not be using any 
>> flow control, but when trying to disable the flow control using Minicom (it 
>> was on by default) freezes the complete RaspberryPi system (requiring to 
>> disconnect and reconnect power).
>> 
>>  
>> 
>> Does anyone have any thoughts what could be the cause of these issues (e.g., 
>> problems with driver etc)? Any information would be greatly appreciated. In 
>> the project we are working on we would need to use both uart ports (0/1) 
>> provided by the compute module (the uart0 is a pl011 and by disabling 
>> console use of /dev/ttyAMA0 we were able to successfully connect to that 
>> port).
>> 
>>  
>> 
>> Thanks for the great work with the Yocto platform.
>> 
>>  
>> 
>> Sincerely,
>> 
>> Andreas Enbacka
>> 
>> SW designer
>> 
>> Gasera Ltd
>> 
>>  
>> 
>> 
>> --
>> ___
>> 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

[Aníbal Limón]

Hi Trevor,

You can review the machine models at [1], the db schema is generated by 
Django.


Regards,
alimon

[1] 
http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/tree/layerindex/models.py#n331


On 04/06/15 09:44, Trevor Woerner wrote:

Thanks Nathan and Paul!

Any chance the database schema drawing is available somewhere?

I'm guessing the machines.layerbranch points to layerItems.id?


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

Re: [yocto] layerindex

[Trevor Woerner]

Thanks Nathan and Paul!

Any chance the database schema drawing is available somewhere?

I'm guessing the machines.layerbranch points to layerItems.id?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to activate piTFT stagging driver?

[abhishek srivastava]

HiI need to interface raspberrypi with piTFT 2.8" resistive. I can find the 
driver in stagging directory in linux.I have enabled the driver from $make 
menuconfig option but could not get the display working. Is their some more 
settings needed to be done in other files in linux kernel ? please specify the 
detailed procedure how to do so? 
How to activate that driver from stagging directory? Abhishek 

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

[yocto] Yocto's udev not generating dev/dri/card0 file

[Chen, Simon]

Hello,

I am trying to integrate an external Radeon graphics card (E8860), and the FOSS 
xf86-video-ati driver, with the poky-dizzy-12.0.1 version of Yocto. I have the 
FOSS driver installed successfully with Glamor and udev enabled. However I am 
getting errors in my Xorg.0.log file, which says that the dev/dri/card0 device 
file does not exist. I've looked into the etc/udev/rules.d and the 
lib/udev/rules.d directories and could not find any rules for generating card0. 
I checked back in my udev Yocto recipe in meta/recipe-core Yocto build 
environment, and it seems as though there are already rules for card0 in 
udev.rules-I'm guessing they never made it through to the final Yocto image. 
I've tried entering my own udev rules in the Yocto file system via 
/etc/udev/rules.d/local.rules, but nothing has worked so far. Has anyone 
experienced similar problems?

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

Re: [yocto] [meta-selinux][PATCH] oe-selinux.conf: set preferred kernel version to 3.14

[Philip Tricca]

On 05/18/2015 07:15 PM, Khem Raj wrote:
> 
>> On May 16, 2015, at 12:04 PM, Philip Tricca  wrote:
>>
>> Upstream 3.19 isn't supported by meta-selinux yet. Set PREFERRED_VERSION
>> to 3.14 as a work-around to keep the reference images bootable.
>>
>> Signed-off-by: Philip Tricca 
>> ---
>> conf/distro/oe-selinux.conf | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/conf/distro/oe-selinux.conf b/conf/distro/oe-selinux.conf
>> index 6e55a32..ea3adbf 100644
>> --- a/conf/distro/oe-selinux.conf
>> +++ b/conf/distro/oe-selinux.conf
>> @@ -1,4 +1,6 @@
>> DISTRO = "oe-selinux"
>> DISTROOVERRIDES .= ":selinux"
>>
>> +PREFERRED_VERSION_linux-yocto = "3.14%”
> 
> IMO this looks a wrong place to pin kernel versions. Its BSPs choice hence 
> belongs to machine
> layers. unless you want to limit the scope of this layer to BSPs using 
> linux-yocto only, then you need
> to state that in README and still not set this but instead set a bbappend and 
> raise a parse error to inform
> the user about the layer expecting linux-yocto 3.14

I picked the distro conf because the SELinux kernel config is why we
need to pin the version (don't have a config for 3.19 yet). Secondly in
looking for an example of using this variable I saw the poky distro
layer pinning the kernel version in the distro.conf. I may have just
been emulating bad behavior here though.

Philip

> 
>> +
> 
>> DISTRO_FEATURES_append = " acl xattr pam selinux"
>> --
>> 2.1.4
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 

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