[yocto] [meta-raspberrypi][PATCH 1/1] Remove orphan bbappend

2017-03-15 Thread Fabien Lahoudere 
gstreamer1.0-omx_1.2.0.bb and gstreamer1.0-omx_git.bb have been removed
from poky on master branch, so related bbappend should be removed.

Signed-off-by: Fabien Lahoudere 
---
 .../gstreamer/gstreamer1.0-omx_1.2.0.bbappend  | 14 --
 recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bbappend | 13 -
 2 files changed, 27 deletions(-)
 delete mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend
 delete mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bbappend

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend
deleted file mode 100644
index 49ba376..000
--- a/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend
+++ /dev/null
@@ -1,14 +0,0 @@
-#
-# Need to make this conditional to gstreamer1
-#
-SRC_URI_append_rpi = " \
- file://0001-config-files-path.patch \
- 
file://0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch \
- file://0002-fix-decoder-flushing.patch \
- file://0003-no-timeout-on-get-state.patch \
- file://0004-Properly-handle-drain-requests-while-flushing.patch \
- 
file://0005-Don-t-abort-gst_omx_video_dec_set_format-if-there-s-.patch \
- 
file://0006-omxvideodec-unref-allocator-after-getting-it-from-al.patch \
-"
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/gstreamer1.0-omx-1.2.0:"
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bbappend
deleted file mode 100644
index 9bcc446..000
--- a/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bbappend
+++ /dev/null
@@ -1,13 +0,0 @@
-#
-# Need to make this conditional to gstreamer1
-#
-SRC_URI_append_rpi = " \
- file://0001-config-files-path.patch \
- 
file://0002-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch \
- file://0003-fix-decoder-flushing.patch \
- file://0003-no-timeout-on-get-state.patch \
- file://0004-Properly-handle-drain-requests-while-flushing.patch \
- 
file://0005-Don-t-abort-gst_omx_video_dec_set_format-if-there-s-.patch \
-"
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/gstreamer1.0-omx:"
-- 
2.11.0

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

Re: [yocto] [meta-raspberrypi][PATCH] userland_git.bb: remove libgl RPROVIDES

2017-03-15 Thread Paul Barker 
On Wed, 15 Mar 2017 09:45:53 -0400
Trevor Woerner  wrote:

> This recipe does not generate any libGL libraries, so remove libgl from the
> list of libraries it provides. Among the libraries generated are libEGL and
> libGLESv2. This entry makes it impossible to have, say, mesa provide libGL
> since opkg thinks there is a conflict.
> 
> Signed-off-by: Trevor Woerner 
> ---
>  recipes-graphics/userland/userland_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-graphics/userland/userland_git.bb 
> b/recipes-graphics/userland/userland_git.bb
> index 5344dc3..f0f25b2 100644
> --- a/recipes-graphics/userland/userland_git.bb
> +++ b/recipes-graphics/userland/userland_git.bb
> @@ -10,7 +10,7 @@ PR = "r5"
>  PROVIDES = "virtual/libgles2 \
>  virtual/egl"
>  
> -RPROVIDES_${PN} += "libgles2 libgl"
> +RPROVIDES_${PN} += "libgles2"
>  
>  COMPATIBLE_MACHINE = "raspberrypi"
>  

I think Khem already has a similar patch staged for this:
https://github.com/kraj/meta-raspberrypi/commit/e070005aa8251c81323b393d49fd87f92e74cae1

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

Re: [linux-yocto] [linux-yocto v4.1 0/4] net: mwifiex: Enable the DRCS & MSI support

2017-03-15 Thread Bruce Ashfield 

I need the intel maintainers of this branch to comment on the changes.

I have no issues with merging them, but need their ack before I'll do
so.

I've copied them on this reply!

Cheers,

Bruce

On 2017-03-15 10:24 AM, Kevin Hao wrote:

From: Kevin Hao 

Hi,

This targets on standard/intel/4.1.27/leaf-hill branch. In order to support
concurrent AP(5G) and client(2.4G) mode, we need to enable the DRCS(Dynamic
Rapid Channel Switching) feature in the Wifi module. Pick up two patches
from mainline to enable this feature. The other two patches are for the
MSI interrupt support.

Avinash Patil (3):
  mwifiex: enable MSI interrupt support in pcie
  mwifiex: support to set multichannel policy to FW
  mwifiex: advertise multichannel support to cfg80211

Shengzhen Li (1):
  mwifiex: fix interrupt processing corner case in MSI mode

 drivers/net/wireless/mwifiex/cfg80211.c| 14 +-
 drivers/net/wireless/mwifiex/fw.h  |  8 +++
 drivers/net/wireless/mwifiex/main.h|  1 +
 drivers/net/wireless/mwifiex/pcie.c| 81 ++
 drivers/net/wireless/mwifiex/pcie.h|  1 +
 drivers/net/wireless/mwifiex/sta_cmd.c | 36 +
 drivers/net/wireless/mwifiex/sta_cmdresp.c |  1 +
 7 files changed, 130 insertions(+), 12 deletions(-)



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

Re: [yocto] [meta-raspberrypi][PATCH] userland_git.bb: remove libgl RPROVIDES

2017-03-15 Thread Trevor Woerner 
On Wed, Mar 15, 2017 at 10:30 AM, Paul Barker  wrote:
> I think Khem already has a similar patch staged for this:
> https://github.com/kraj/meta-raspberrypi/commit/e070005aa8251c81323b393d49fd87f92e74cae1


Oops! thanks :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Why generated locales does not have .UTF-8 suffix?

2017-03-15 Thread Fabio Emiliani 

Hi Khem,

I confirm that generated locales are UTF-8 encoded. Even if they don't 
have .utf8 suffix at the end of the file name. This morning I  had an 
answer from StackOverflow:



http://stackoverflow.com/questions/42784435/how-to-check-if-a-locale-is-utf-8/42797421#42797421
I've also opened a bug on bugzilla to try to solve an annyoing encoding 
problem:



https://bugzilla.yoctoproject.org/show_bug.cgi?id=11153#c1

I hope this can help everyone has similar problems

--

Fabio

Il 14/03/2017 18:08, Fabio Emiliani ha scritto:


Hi Khem,

I've tried with the GLIBC_GENERATE_LOCALES variable too but locales 
are still generated without .utf8 suffix.


A little bit of info, locales are working, I can see localized 
strings. E.g. if I set en_US locale and execute "ls --help" I can see 
the output of ls in english. If i set zh_CN (chinese) locale and 
execute "ls --help" I can see the output of ls in chinese.


The problem is realted to the encoding of a locale. Until now I  have 
not found any way to generate an UTF-8 locale.


Since the encoding is not specified in the file name, how can I check 
the encoding of a locale called "en_US"?


Best regards,

Fabio Emiliani

Il 14/03/2017 18:00, Khem Raj ha scritto:

On 3/14/17 9:50 AM, Fabio Emiliani wrote:

Hi Khem,

unfortunatly doesn't work.

The IMAGE_LINGUAS variable can be valorized only with the suffixes of
the locale-base-* packages. As of now my list of locale-base-* packages
for en_US is:


locale-base-en-us.iso-8859-1
locale-base-en-us

no .utf8 suffix. That's strange, I'm not sure that the en_US locale I've
generated supports UTF-8 encoding.

does this help ?

GLIBC_GENERATE_LOCALES = "de_DE en_US de_DE.UTF-8 en_US.UTF-8"
IMAGE_LINGUAS = "de-de en-us"



I've just opened a bug on bugzilla:


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

Any other ideas?

Thanks in advance for your time

Best regards,

Fabio Emiliani

Il 14/03/2017 17:39, Khem Raj ha scritto:

On 3/14/17 8:36 AM, Fabio Emiliani wrote:

Dear all,

I've generated several locales specifying, in the local.conf file, the
variable:


|IMAGE_LINGUAS = "de-de fr-fr en-gb en-gb.iso-8859-1 en-us
en-us.iso-8859-1 zh-cn"|

inspecting the target file system, both in: /usr/share/locale and
/usr/lib/locale, generated locales does not have the .UTF-8 suffix.


Perhaps adding en-gb.utf8 to IMAGE_LINGUAS might help you.


See:


|/usr/share/locale/ drwxr-xr-x 6 root root 416 Nov 17 2016 . drwxr-xr-x
30 root root 2056 Nov 17 2016 .. drwxr-xr-x 4 root root 296 Nov 17
2016 de drwxr-xr-x 3 root root 232 Nov 17 2016 en_GB drwxr-xr-x 4 root
root 296 Nov 17 2016 fr drwxr-xr-x 4 root root 296 Nov 17 2016 zh_CN|

|and|

||


|/usr/lib/locale/ drwxr-xr-x 9 root root 640 Mar 13 2017 . drwxr-xr-x
32 root root 4 Mar 13 2017 .. drwxr-xr-x 3 root root 1016 Mar 13
2017 de_DE drwxr-xr-x 3 root root 1016 Mar 13 2017 en_GB drwxr-xr-x 3
root root 1016 Mar 13 2017 en_GB.ISO-8859-1 drwxr-xr-x 3 root root
1016 Mar 13 2017 en_US drwxr-xr-x 3 root root 1016 Mar 13 2017
en_US.ISO-8859-1 drwxr-xr-x 3 root root 1016 Mar 13 2017 fr_FR
drwxr-xr-x 3 root root 1016 Mar 13 2017 zh_CN|

What is the character encoding of the following locales: de_DE, en_GB,
en_US, fr_FR, zh_CN?

Thanks in advance for your time

Best regards,

Fabio Emiliani

--

*Fabio Emiliani*

*/Software Engineer/*

/Ph. +39 075 8298 530  /

/fabio.emili...@artgroup-spa.com/

DISCLAIMER
This email and any attachment may contain confidential information. If
you are not the intended recipient you are not authorised to copy or
disclose all or any part of it without the prior written consent of ART SpA.

  


/ART SpA – Step Forward With US - //www.artgroup-spa.com/logo_ART_firma-1//

/Ph. +39 075 8298 501 – Fax +39 075 8298 525 /

P*Please consider our environment  before printing this e-mail***

  





--

*Fabio Emiliani*

*/Software Engineer/*

/Ph. +39 075 8298 530  /

/fabio.emili...@artgroup-spa.com/

DISCLAIMER
This email and any attachment may contain confidential information. If
you are not the intended recipient you are not authorised to copy or
disclose all or any part of it without the prior written consent of ART SpA.

  


/ART SpA – Step Forward With US - //www.artgroup-spa.com/logo_ART_firma-1//

/Ph. +39 075 8298 501 – Fax +39 075 8298 525 /

P*Please consider our environment  before printing this e-mail***

  



--

*Fabio Emiliani*

*/Software Engineer/*

/Ph. +39 075 8298 530 /

/fabio.emili...@artgroup-spa.com/ 

DISCLAIMER
This email and any attachment may contain confidential information. If 
you are not the intended recipient you are not authorised to copy or 
disclose all or any part of it without the prior written consent of 
ART SpA.


/ART SpA – Step Forward With US - 
//www.artgroup-spa.com/logo_ART_firma-1//


/Ph. +39 075 8298 501 – Fax +39 075 8298 525 /

P*Please consider our environment  before

[yocto] [meta-raspberrypi][PATCH] userland_git.bb: remove libgl RPROVIDES

2017-03-15 Thread Trevor Woerner 
This recipe does not generate any libGL libraries, so remove libgl from the
list of libraries it provides. Among the libraries generated are libEGL and
libGLESv2. This entry makes it impossible to have, say, mesa provide libGL
since opkg thinks there is a conflict.

Signed-off-by: Trevor Woerner 
---
 recipes-graphics/userland/userland_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/userland/userland_git.bb 
b/recipes-graphics/userland/userland_git.bb
index 5344dc3..f0f25b2 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -10,7 +10,7 @@ PR = "r5"
 PROVIDES = "virtual/libgles2 \
 virtual/egl"
 
-RPROVIDES_${PN} += "libgles2 libgl"
+RPROVIDES_${PN} += "libgles2"
 
 COMPATIBLE_MACHINE = "raspberrypi"
 
-- 
2.12.0.rc1.48.g076c053

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

Re: [yocto] List of packages in image and their Licenses

2017-03-15 Thread Josef Holzmayr 

Hi,

On 15.03.2017 09:42, Keskinarkaus, Teemu wrote:


I know that there is bitbake command/option to get list of all packages
available, but how would I get a list of packages that goes to any
specific image? And is there a way to get what Licenses those packages
are using?


look at tmp/deploy/licenses/$YOURSPECIFICBUILD_$TIMESTAMP/license.manifest

(with $YOURSEPCIFICBUILD basically being imagename-machine)

Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

[yocto] List of packages in image and their Licenses

2017-03-15 Thread Keskinarkaus, Teemu 
Hi,

I know that there is bitbake command/option to get list of all packages 
available, but how would I get a list of packages that goes to any specific 
image? And is there a way to get what Licenses those packages are using?

-TeemuK



Actuant Corporation Email Notice

This message is intended only for the use of the Addressee and may contain 
information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the 
recipient(s) named above. If the reader of this email is not an intended 
recipient, you have received this email in error and any review, dissemination, 
distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately 
by return mail and permanently delete the copy you received.

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

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

2017-03-15 Thread Robert P. J. Day 
On Wed, 15 Mar 2017, Belisko Marek wrote:

> On Tue, Mar 14, 2017 at 9:53 PM, Robert P. J. Day  
> wrote:
> > On Tue, 14 Mar 2017, Belisko Marek wrote:
> >
> >> Hi Robert,
> >>
> >> On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day  
> >> wrote:
> >> > On Mon, 13 Mar 2017, Robert P. J. Day wrote:
> >> >
> >> >>
> >> >>   i'll start a new thread to focus on just this issue. again, building
> >> >> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
> >> >>
> >> >>   INHERIT += "kernel-fitimage" <-- do i need this line?
> >> >>   KERNEL_IMAGETYPES_append = " fitImage"
> >> >>
> >> >> anyway, run:
> >> >>
> >> >>   $ bitbake virtual/kernel
> >> >>
> >> >> and eventually get:
> >> >>
> >> >>   make[2]: *** No rule to make target 'fitImage'.  Stop.
> >> >
> >> > ... snip ...
> >> >
> >> >   i would still love to figure out how to generate a simple FIT image
> >> > when building core-image-minimal for mpc8315e-rdb.
> >> >
> >> >   first, based on what i read, my first attempt was to add the
> >> > following line to local.conf:
> >> >
> >> >   KERNEL_IMAGETYPES_append = " fitImage"
> >> You need probably also add:
> >>
> >> KERNEL_CLASSES += "kernel-fitimage"
> >>
> >> to local.conf
> >
> >   that *appears* to have solved the problem ... so why is it i didn't
> > realize that? where is that written up that i somehow missed it?

> It is not documented in yocto manual (I cannot find anything about
> fitimage at all), so maybe it could be extended.

  i'll check later to see where it would seem to belong, unless
someone has a suggestion.

> >   and would it not make sense that selecting FIT image in one
> > variable should automatically set the other required variables?

> I think something like that can be doable and it will save a lot of
> time for people who want's to have it enabled.

  actually, i take back that suggestion, as i think it would overly
complicate kernel.bbclass (at least the way i read it).

  i can see that, for backward compatibility, kernel.bbclass contains
the following:

  # Here we pull in all various kernel image types which we support.
  #
  # In case you're wondering why kernel.bbclass inherits the other image
  # types instead of the other way around, the reason for that is to
  # maintain compatibility with various currently existing meta-layers.
  # By pulling in the various kernel image types here, we retain the
  # original behavior of kernel.bbclass, so no meta-layers should get
  # broken.
  #
  # KERNEL_CLASSES by default pulls in kernel-uimage.bbclass, since this
  # used to be the default behavior when only uImage was supported. This
  # variable can be appended by users who implement support for new kernel
  # image types.

  KERNEL_CLASSES ?= " kernel-uimage "
  inherit ${KERNEL_CLASSES}

so it's quite simple to extend the set of .bbclass files that provide
new kernel image types with, say:

  KERNEL_CLASSES += "kernel-fitimage"

beyond that, however, since a new kernel class file might define a
*pile* of new kernel image types, poor kernel.bbclass would need to
recognize all of them and know which kernel class file to inherit for
each new kernel type, which seems unwieldy.

  so as long as how to define new kernel image types is explained
clerly (is it?), then a discussion of FIT images should simply need to
refer the reader to that section.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

2017-03-15 Thread Belisko Marek 
On Tue, Mar 14, 2017 at 9:53 PM, Robert P. J. Day  wrote:
> On Tue, 14 Mar 2017, Belisko Marek wrote:
>
>> Hi Robert,
>>
>> On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day  
>> wrote:
>> > On Mon, 13 Mar 2017, Robert P. J. Day wrote:
>> >
>> >>
>> >>   i'll start a new thread to focus on just this issue. again, building
>> >> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
>> >>
>> >>   INHERIT += "kernel-fitimage" <-- do i need this line?
>> >>   KERNEL_IMAGETYPES_append = " fitImage"
>> >>
>> >> anyway, run:
>> >>
>> >>   $ bitbake virtual/kernel
>> >>
>> >> and eventually get:
>> >>
>> >>   make[2]: *** No rule to make target 'fitImage'.  Stop.
>> >
>> > ... snip ...
>> >
>> >   i would still love to figure out how to generate a simple FIT image
>> > when building core-image-minimal for mpc8315e-rdb.
>> >
>> >   first, based on what i read, my first attempt was to add the
>> > following line to local.conf:
>> >
>> >   KERNEL_IMAGETYPES_append = " fitImage"
>> You need probably also add:
>>
>> KERNEL_CLASSES += "kernel-fitimage"
>>
>> to local.conf
>
>   that *appears* to have solved the problem ... so why is it i didn't
> realize that? where is that written up that i somehow missed it?
It is not documented in yocto manual (I cannot find anything about
fitimage at all), so maybe it could be extended.
>
>   and would it not make sense that selecting FIT image in one variable
> should automatically set the other required variables?
I think something like that can be doable and it will save a lot of
time for people who want's to have it enabled.
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Development and production images

2017-03-15 Thread Mircea Gliga 
In my layer I've defined a separate image for development and a separate 
one for production, eg myimage-dbg.bb and myimage.bb
The difference between them is that the devel one has extra packages 
installed.
So, if you want to build a development image you build the `myimage-dbg` 
image, else the other one.
Now, for production images, I want to disable the serial console login, 
this is controlled by the SERIAL_CONSOLES variable and is specified in 
the machine.conf file, so this cannot be added to the image recipes.
In order to keep things as simple as I can, and make the choice only 
once (devel vs production), I want to avoid creating separate 
machine.conf files for development and production, eg mymachine.conf and 
mymachine-dbg.conf.



Do you have any suggestion on what's the best and approach ?

Thanks

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

[yocto] arm-poky-linux-gnueabi-gcc: Command not found

2017-03-15 Thread ravikiran j 
I am trying to build the linux kernel for odorid-xu3 board but i am getting
following errors for
*bitbake linux-stable*


DEBUG: Executing shell function do_compile
NOTE: make -j 4 HOSTCC=gcc  HOSTCPP=gcc  -E zImage
CC=arm-poky-linux-gnueabi-gcc   -fuse-ld=bfd
LD=arm-poky-linux-gnueabi-ld.bfd
ERROR: oe_runmake failed
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/scripts/gcc-version.sh:
line 25: arm-poky-linux-gnueabi-gcc: command not found
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/scripts/gcc-version.sh:
line 26: arm-poky-linux-gnueabi-gcc: command not found
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
  GEN ./Makefile
scripts/kconfig/conf  --silentoldconfig Kconfig
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/scripts/gcc-version.sh:
line 25: arm-poky-linux-gnueabi-gcc: command not found
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/scripts/gcc-version.sh:
line 26: arm-poky-linux-gnueabi-gcc: command not found
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
  CHK include/config/kernel.release
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
  GEN ./Makefile


 Using
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source
as source for kernel
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
make[2]: arm-poky-linux-gnueabi-gcc: Command not found
  HOSTCC  scripts/pnmtologo
  HOSTCC  scripts/kallsyms
  CC  scripts/mod/empty.o
/bin/sh: 1: arm-poky-linux-gnueabi-gcc: not found
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/scripts/Makefile.build:293:
recipe for target 'scripts/mod/empty.o' failed
make[4]: *** [scripts/mod/empty.o] Error 127
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/scripts/Makefile.build:544:
recipe for target 'scripts/mod' failed
make[3]: *** [scripts/mod] Error 2
make[3]: *** Waiting for unfinished jobs
  HOSTCC  scripts/dtc/dtc.o
  HOSTCC  scripts/dtc/flattree.o
  HOSTCC  scripts/dtc/fstree.o
  HOSTCC  scripts/dtc/data.o
  HOSTCC  scripts/dtc/livetree.o
  HOSTCC  scripts/dtc/treesource.o
  HOSTCC  scripts/dtc/srcpos.o
  HOSTCC  scripts/dtc/checks.o
  HOSTCC  scripts/dtc/util.o
  SHIPPED scripts/dtc/dtc-lexer.lex.c
  SHIPPED scripts/dtc/dtc-parser.tab.h
  SHIPPED scripts/dtc/dtc-parser.tab.c
  HOSTCC  scripts/dtc/dtc-lexer.lex.o
  HOSTCC  scripts/dtc/dtc-parser.tab.o
  HOSTLD  scripts/dtc/dtc
/home/mistral/yocto1/poky/build-xfce/tmp/work-shared/odroid-xu3/kernel-source/Makefile:560:
recipe for target 'scripts' failed
make[2]: *** [scripts] Error 2
Makefile:150: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at
/home/mistral/yocto1/poky/build-xfce/tmp/work/odroid_xu3-poky-linux-gnueabi/linux-stable/4.9.13+gitAUTOINC+f3329efb7f-r0/temp/log.do_compile.15577)

what is the problem and how to solve this problem ?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto