[yocto] When are file checksums gathered from files, for tasks? During recipe parsing?

[Paul Knopf]

I have a recipe that depends on a deployed output from an image.

--
SRC_URI +=
"file://${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.tar.gz;subdir=update"
do_fetch[depends] += "my-image:do_build"
--

Will the hash for "do_fetch" be computed after "my-image:do_build" is
executed?

If not, how would you propose I do something like this?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Forcing a single task to re-run each build, by default.

[Martin Hundebøll]

Hi Paul,

On 2017-11-22 07:12, Paul Knopf wrote:

I have a task that I would like to be forced to run for every build.

NOTE: I am aware of the deploy.bbclass, but I want to not use sstate. 
Assume I am not using deploy.bbclass.


So, let's say I have this.


DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
do_deploy[dirs] = "${DEPLOYDIR} ${B}"
do_deploy[vardeps] += "DATETIME"

do_deploy() {
     install -d ${DEPLOYDIR}
     # custom stuff...
}

addtask do_deploy after do_install


Now, when I run this recipe, I get "non-deterministic" errors, which I 
get. Maybe I can get a DATETIME-ish variable that has the same random 
value throughout the entire bitbake process?


Yes, DATETIME includes the seconds, which changes during the build and 
leads to tasks hashes changing from the initial recipe parsing to the 
actual execution of the task.



Or, what about this?


#do_deploy[vardeps] += "DATETIME"
do_deploy[stamp-extra-info] = "${DATETIME}"



In our process we force redeployment of images with "nostamp":

do_deploy[nostamp] += "1"

I think that would work for you too.

--
MARTIN HUNDEBØLL, Prevas A/S
Software Developer

Hedeager 3, DK-8200 Aarhus N
Phone +45 87438070
Mobile +45 25562438
martin.hundeb...@prevas.dk
www.prevas.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] When are file checksums gathered from files, for tasks? During recipe parsing?

[Martin Hundebøll]

Hi Paul,

On 2017-11-22 09:10, Paul Knopf wrote:

I have a recipe that depends on a deployed output from an image.

--
SRC_URI += 
"file://${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.tar.gz;subdir=update"

do_fetch[depends] += "my-image:do_build"
--

Will the hash for "do_fetch" be computed after "my-image:do_build" is 
executed?


The "dependency" hash is based on the hash of the my-image recipe, so 
that if you change the my-image.bb, then the hash of your dependent 
recipe changes too.



If not, how would you propose I do something like this?


Don't put deployed images in SRC_URI, and don't put task dependencies in 
do_fetch, as that messes with do_fetchall, should you ever need to run that.


Look at what other recipes are doing when using images from 
DEPLOY_DIR_IMAGE. A reworked example from one of our recipes:


  do_image[depends] += "my-image:do_image_complete"

  IMAGE_PREPROCESS_COMMAND += "image_prepare"
  image_prepare() {
install ${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.tar.gz 
${IMAGE_ROOTFS}/

  }


I hope that helps!

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

[yocto] [meta-oracle-java][PATCH] Fix warning in do_populate_sysroot: sstate found an absolute path symlink

[Vincent Prince]

Signed-off-by: Vincent Prince 
---
 recipes-devtools/oracle-java/oracle-jse-jdk.inc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk.inc 
b/recipes-devtools/oracle-java/oracle-jse-jdk.inc
index 6b3aabe..1ec172f 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk.inc
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk.inc
@@ -16,10 +16,10 @@ do_install_class-native() {
cp -a ${S}/${JDK_JRE}${PV}_${PV_UPDATE} ${D}${JDK_HOME}
 
install -d  ${D}${bindir}
-   ln -sf ${JDK_HOME}/bin/java ${D}${bindir}
-   ln -sf ${JDK_HOME}/bin/javac${D}${bindir}
-   ln -sf ${JDK_HOME}/bin/javah${D}${bindir}
-   ln -sf ${JDK_HOME}/bin/jar  ${D}${bindir}
+   ln -sf ../lib/jvm/${JDK_DIR}/bin/java   ${D}${bindir}
+   ln -sf ../lib/jvm/${JDK_DIR}/bin/javac  ${D}${bindir}
+   ln -sf ../lib/jvm/${JDK_DIR}/bin/javah  ${D}${bindir}
+   ln -sf ../lib/jvm/${JDK_DIR}/bin/jar${D}${bindir}
 
install -d  ${D}${JDK_HOME}/bin
ln -sf javah${D}${JDK_HOME}/bin/gjavah
-- 
2.7.4

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

Re: [yocto] When are file checksums gathered from files, for tasks? During recipe parsing?

[Paul Knopf]

This recipe is not an image recipe. It is a recipe that packages up our
image for deployment/updates in the field. Your method assumes I am editing
the image recipe.

On Wed, Nov 22, 2017 at 4:01 AM, Martin Hundebøll  wrote:

> Hi Paul,
>
> On 2017-11-22 09:10, Paul Knopf wrote:
>
>> I have a recipe that depends on a deployed output from an image.
>>
>> --
>> SRC_URI += "file://${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.
>> tar.gz;subdir=update"
>> do_fetch[depends] += "my-image:do_build"
>> --
>>
>> Will the hash for "do_fetch" be computed after "my-image:do_build" is
>> executed?
>>
>
> The "dependency" hash is based on the hash of the my-image recipe, so that
> if you change the my-image.bb, then the hash of your dependent recipe
> changes too.
>
> If not, how would you propose I do something like this?
>>
>
> Don't put deployed images in SRC_URI, and don't put task dependencies in
> do_fetch, as that messes with do_fetchall, should you ever need to run that.
>
> Look at what other recipes are doing when using images from
> DEPLOY_DIR_IMAGE. A reworked example from one of our recipes:
>
>   do_image[depends] += "my-image:do_image_complete"
>
>   IMAGE_PREPROCESS_COMMAND += "image_prepare"
>   image_prepare() {
> install ${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.tar.gz
> ${IMAGE_ROOTFS}/
>   }
>
>
> I hope that helps!
>
> // Martin
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEPENDS python-xml not working in pyro2.3

[Khem Raj]

Check the configure logs, or post the logs somewhere. You should be looking
at the test which is done to assert presence
of libxml2 and then see why its failing. btw. you might need to
inherit pkgconfig if pkgconfig is used for conguring lib deps.

On Tue, Nov 21, 2017 at 11:37 PM, Viraj Mistry 
wrote:

> Hi KhemRaj,
>
>
>
> Thank you for update.
>
> Yes we have added libxml2 to DEPENDS but same error.
>
> But what we observe is when we inherit setuptools then it is showing this
> error “*checking python module: libxml2... no”*.
>
> But when we don’t inherit setuptools then it will take PC’s libxml2
> package. However we want target libxml2 package.
>
> In daisy version we used *python-xml* and it resolve our issue. However
> in pyro we are facing this issue.
>
>
>
> Please help us in this matter.
>
>
>
> *Regards,*
>
> *Viraj Mistry*
>
>
>
> *From:* Khem Raj [mailto:raj.k...@gmail.com]
> *Sent:* Tuesday, November 21, 2017 10:29 PM
> *To:* Amit Gondaliya 
> *Cc:* yocto@yoctoproject.org; Viraj Mistry 
> *Subject:* Re: [yocto] DEPENDS python-xml not working in pyro2.3
>
>
>
> you might need to add libxml2 to DEPENDS
>
>
>
> On Tue, Nov 21, 2017 at 3:26 AM, Amit Gondaliya <
> amit.gondal...@einfochips.com> wrote:
>
> Hello All,
>
>
>
> I am configuring one package using pyro 2.3 I sticked at below error..
>
>
>
>
>
> *checking python module: libxml2... no configure: error: failed to find
> required module libxml2*
>
>
>
> *checking python module: curses... yes checking python module: libxml2...
> no configure: error: failed to find required module libxml2*
>
>
>
> I have "python-xml" in my "application.bb" file as *DEPENDS* variable, *this
> is working fine yocto daisy1.6, however this is not working with yocto
> pyro2.3*
>
>
>
> *Best Regards,*
> *Amit Gondaliya*
>
> 
> 
> * 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 company accepts
> no liability for any damage caused by any virus transmitted by this email.
> 
> 
> *
>
>
> --
> ___
> 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] Contribute meta-installer to yocto

[Khem Raj]

On Tue, Nov 21, 2017 at 12:55 AM, Hongxu Jia  wrote:
> Hi all,
>
> Wind River has maintained meta-installer for several years,
> and now we want to contribute it to yocto community.
>
> This layer provides an installation program based on
> OE platform. The installation program is anaconda from
> fedora, which is the installer of distribution Fedora,
> RedHat and Centos.
>
> The version of anaconda in meta-installer is 26.21.11
> which is based on Fedora 26.
>
> The meta-insatller requires:
> - systemd as init manager
> - python3
> - dnf2/rpm4
> - gobject-introspection which requires qemu-usermode
>   in MACHINE_FEATURES
>
> The meta-installer provides:
> - graphic install and text install.
>
> - package based (dnf/rpm) install and image (copy)
>   based install.
>
> - package based (dnf/rpm) install from local and
>   remote rpm sources such as CDs and DVDs, images
>   stored on a hard drive, NFS, HTTP, and FTP.
>
> - kickstart install which provides a fully unattended
>   installation that can be duplicated on scores of machines.
>
> - install over VNC on headless machines.
>
> - timezone setting.
>
> - root password setting.
>
> - user account creation.
>
> - a variety of advanced storage devices including
>   LVM, Btrfs, Ext4, and filesystem encryption.
>
> The repository of meta-installer is temporary on the github
> for review:
> https://github.com/jiahongxujia/meta-installer
>
> In above github, the logo picture is undefined, if yocto
> could accept this layer, I will update the picture with
> "Yocto project Compatible".
>
> The attachments are the snapshots of a package based
> installation.
>
> Hopefully it is helpful for yocto, and any feedback is
> appreciated.
>
> If yocto is interested in this layer and will accept it,
> I could send pull request or some one directly fetch
> from above github master branch.
>

This is a very good work. Thanks for contributing it. We should definitely
put it under meta-openembedded framework.

> //Hongxu
>
> --
> ___
> 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] When are file checksums gathered from files, for tasks? During recipe parsing?

[Khem Raj]

On Wed, Nov 22, 2017 at 5:51 AM, Paul Knopf  wrote:
> This recipe is not an image recipe. It is a recipe that packages up our
> image for deployment/updates in the field. Your method assumes I am editing
> the image recipe.

there are post/pre processing hooks for Extra operations on final
image, if you were to use those to achieve the tasks specific for your
deployment/field-update, it will fit well into workflow and you can
leverage the dependency mechanisms stated above

then you could combine this with some extra image specific tasks to
operate on rootfs during image creation.

In short, perhaps you should think about getting this done during the
final image creation instead of creating another recipe.

>
> On Wed, Nov 22, 2017 at 4:01 AM, Martin Hundebøll  wrote:
>>
>> Hi Paul,
>>
>> On 2017-11-22 09:10, Paul Knopf wrote:
>>>
>>> I have a recipe that depends on a deployed output from an image.
>>>
>>> --
>>> SRC_URI +=
>>> "file://${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.tar.gz;subdir=update"
>>> do_fetch[depends] += "my-image:do_build"
>>> --
>>>
>>> Will the hash for "do_fetch" be computed after "my-image:do_build" is
>>> executed?
>>
>>
>> The "dependency" hash is based on the hash of the my-image recipe, so that
>> if you change the my-image.bb, then the hash of your dependent recipe
>> changes too.
>>
>>> If not, how would you propose I do something like this?
>>
>>
>> Don't put deployed images in SRC_URI, and don't put task dependencies in
>> do_fetch, as that messes with do_fetchall, should you ever need to run that.
>>
>> Look at what other recipes are doing when using images from
>> DEPLOY_DIR_IMAGE. A reworked example from one of our recipes:
>>
>>   do_image[depends] += "my-image:do_image_complete"
>>
>>   IMAGE_PREPROCESS_COMMAND += "image_prepare"
>>   image_prepare() {
>> install ${DEPLOY_DIR_IMAGE}/my-image-${MACHINE}.wic.update.tar.gz
>> ${IMAGE_ROOTFS}/
>>   }
>>
>>
>> I hope that helps!
>>
>> // Martin
>
>
>
> --
> ___
> 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] DEPENDS python-xml not working in pyro2.3

[Viraj Mistry]

Hi KhemRaj,

Thank you for update.
Yes we have added libxml2 to DEPENDS but same error.
But what we observe is when we inherit setuptools then it is showing this error 
“checking python module: libxml2... no”.
But when we don’t inherit setuptools then it will take PC’s libxml2 package. 
However we want target libxml2 package.
In daisy version we used python-xml and it resolve our issue. However in pyro 
we are facing this issue.

Please help us in this matter.

Regards,
Viraj Mistry

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Tuesday, November 21, 2017 10:29 PM
To: Amit Gondaliya 
Cc: yocto@yoctoproject.org; Viraj Mistry 
Subject: Re: [yocto] DEPENDS python-xml not working in pyro2.3

you might need to add libxml2 to DEPENDS

On Tue, Nov 21, 2017 at 3:26 AM, Amit Gondaliya 
mailto:amit.gondal...@einfochips.com>> wrote:

Hello All,



I am configuring one package using pyro 2.3 I sticked at below error..


checking python module: libxml2...
no
configure: error: failed to find required module libxml2
checking python module: curses... yes
checking python module: libxml2... no
configure: error: failed to find required module libxml2

I have "python-xml" in my "application.bb" file as 
DEPENDS variable, this is working fine yocto daisy1.6, however this is not 
working with yocto pyro2.3

Best Regards,
Amit Gondaliya





*
 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 company accepts no 
liability for any damage caused by any virus transmitted by this email. 
*

--
___
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] Generating Package/Image Developer Documentation

[Koehler, Yannick]

Thanks,

I am using Yocto 1.9/2.0 and a quick grep doesn't seems to indicate support for 
this DISTRO_FEATURE.

In my case, the package I care about all use CMake and have a similar structure

/CMakeLists.txt # A dev doc target exists here
/doc
/CMakeLists.txt
/Doxyfile.in

As such, I can have a single script to handle them, using "make devdoc".  I may 
not be able to push this upstream but I'll see what I can do.

Maybe the "target" to build doc could be per-recipe.  

--
Yannick Koehler

-Message d'origine-
De : Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Envoyé : 21 novembre 2017 04:56
À : Koehler, Yannick ; yocto@yoctoproject.org
Objet : Re: [yocto] Generating Package/Image Developer Documentation

On 11/20/2017 09:53 PM, Koehler, Yannick wrote:
>The image would then install those documentation in the sysroot under some 
> folder, maybe /usr/share/devdoc// and potentially create a 
> tarball of this documentation.
> 
> Anyway, let me know if something similar pre-exists or if such a project 
> has been started somehow please, as I would like to contribute/participate.


Yes. Add "api-documentation" to DISTRO_FEATURES and you will get manpages and 
gtk-doc based documentation generated, packaged and added to SDKs. It will slow 
down the build significantly, so use with care.

I considered adding doxygen support as well, but generating and installing that 
needs to be hand-crafted for each recipe, and so it wasn't done. You are 
welcome to work on that, subject to api-documentation being enabled. I have a 
recipe for doxygen itself here:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/enable-doxygen

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

Re: [yocto] Generating Package/Image Developer Documentation

[Alexander Kanavin]

On 11/22/2017 06:16 PM, Koehler, Yannick wrote:


I am using Yocto 1.9/2.0 and a quick grep doesn't seems to indicate support for 
this DISTRO_FEATURE.


This was added about a year ago and Yocto 1.9 is a lot older. If you 
want to submit your work upstream, you have to rebase it to the master 
branch first.


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

Re: [yocto] Contribute meta-installer to yocto

[Hongxu Jia]

On 2017年11月22日 23:41, Khem Raj wrote:

If yocto is interested in this layer and will accept it,
I could send pull request or some one directly fetch
from above github master branch.


This is a very good work. Thanks for contributing it. We should definitely
put it under meta-openembedded framework.



Thanks very much, I will send the pull request for review.

//Hongxu


//Hongxu



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

Re: [yocto] DEPENDS python-xml not working in pyro2.3

[Viraj Mistry]

Hi,

Yes In my configure.in file there is condition which checks availability of 
libxml2 module as a Python Module i.e. it use AX_PYTHON_MODULE(libxml2,fatal).
Now in other Modules I have not seen any  kind checking of Python Libxml2 
module. i.e they don’t use AX_PYTHON_MODULE(libxml2,fatal).
As I stated earlier due to AX_PYTHON_MODULE condition it will check libxml2 
module in PC  if I am not inherit setuptools. ( In this case my PC have libxml2 
so no errors).
But if I inherit setuptools then it search for Cross Platform Libxml2 and it 
shows error.(  I guess this is correct way )

Yes in My bb file I am inherit pkgconfig also. But again it shows same error.

Any idea how to overcome above error ?

Regards,
Viraj Mistry

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, November 22, 2017 9:09 PM
To: Viraj Mistry 
Cc: yocto@yoctoproject.org; Amit Gondaliya 
Subject: Re: [yocto] DEPENDS python-xml not working in pyro2.3

Check the configure logs, or post the logs somewhere. You should be looking at 
the test which is done to assert presence
of libxml2 and then see why its failing. btw. you might need to
inherit pkgconfig if pkgconfig is used for conguring lib deps.

On Tue, Nov 21, 2017 at 11:37 PM, Viraj Mistry 
mailto:viraj.mis...@einfochips.com>> wrote:
Hi KhemRaj,

Thank you for update.
Yes we have added libxml2 to DEPENDS but same error.
But what we observe is when we inherit setuptools then it is showing this error 
“checking python module: libxml2... no”.
But when we don’t inherit setuptools then it will take PC’s libxml2 package. 
However we want target libxml2 package.
In daisy version we used python-xml and it resolve our issue. However in pyro 
we are facing this issue.

Please help us in this matter.

Regards,
Viraj Mistry

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Tuesday, November 21, 2017 10:29 PM
To: Amit Gondaliya 
mailto:amit.gondal...@einfochips.com>>
Cc: yocto@yoctoproject.org; Viraj Mistry 
mailto:viraj.mis...@einfochips.com>>
Subject: Re: [yocto] DEPENDS python-xml not working in pyro2.3

you might need to add libxml2 to DEPENDS

On Tue, Nov 21, 2017 at 3:26 AM, Amit Gondaliya 
mailto:amit.gondal...@einfochips.com>> wrote:

Hello All,



I am configuring one package using pyro 2.3 I sticked at below error..


checking python module: libxml2...
no
configure: error: failed to find required module libxml2
checking python module: curses... yes
checking python module: libxml2... no
configure: error: failed to find required module libxml2

I have "python-xml" in my "application.bb" file as 
DEPENDS variable, this is working fine yocto daisy1.6, however this is not 
working with yocto pyro2.3

Best Regards,
Amit Gondaliya





*
 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 company accepts no 
liability for any damage caused by any virus transmitted by this email. 
*

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


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

[yocto] [meta-chip][PATCH] linux: remove usage of deprecated linux-dtb.inc

[Petter Mabäcker]

Signed-off-by: Petter Mabäcker 
---
 recipes-kernel/linux/linux-chip_git.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-chip_git.bb 
b/recipes-kernel/linux/linux-chip_git.bb
index 38df4ad..955d6e7 100644
--- a/recipes-kernel/linux/linux-chip_git.bb
+++ b/recipes-kernel/linux/linux-chip_git.bb
@@ -6,7 +6,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 COMPATIBLE_MACHINE = "chip"
 
 inherit kernel
-require recipes-kernel/linux/linux-dtb.inc
 
 LINUX_VERSION ?= "4.3.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"
-- 
2.14.2

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