Re: [yocto] WARNING: bluez5-5.50-r0 do_fetch: Failed to fetch URL file://variscite-bt.conf

[Zoran Stojsavljevic]

BTW, I have created the complete description of this problem!
https://github.com/ZoranStojsavljevic/imx6-sabre-automotive-bsp/tree/master/Issues

Best Regards,
Zoran
___

On Mon, Aug 26, 2019 at 5:23 PM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Folks,
>
> While doing the following YOCTO build:
>
> http://variwiki.com/index.php?title=Yocto_Build_Release=RELEASE_MORTY_V1
>
> Actually, using the latest available tag: thud-fslc-4.14.78-mx6ul-v1.1
> 
> From https://github.com/varigit/variscite-bsp-platform/tags
>
> I've got the following error, while compiling for both:
> bitbake -k fsl-image-gui
> bitbake -k fsl-image-qt5
>
> Seems, that the local file: file://variscite-bt.conf is somehow missing?!
>
> I can add this file artificially, but, the question is: why this file is
> missing???
> ___
>
> Transcript follows:
> bluez5-5.50-r0 do_fetch: Failed to fetch variscite-bt.conf
> https://pastebin.com/U9LRtNwr
>
> Thank you,
> Zoran
> ___
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] metadata mismatch between image and package (uninative)

[Tim Blechmann]

> i've been able to build by `INHERIT_remove`ing "uninative", but this
> feels like a hack.
> 
> so i'm wondering: what could cause a reparse error when `uninative` is
> enabled?

i think i've tracked down the error:
`uninative_event_enable` extends `PATH`, but only if `UNINATIVE_LOADER`
points to a valid path
https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/uninative.bbclass#n128


`UNINATIVE_LOADER` only points to a valid path after
`uninative_event_fetchloader` succeeds.
https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/uninative.bbclass#n33

but `uninative_event_fetchloader` is only executed during
`bb.event.BuildStarted`, while `uninative_event_enable` is called during
`bb.event.ConfigParsed
`.
https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/uninative.bbclass#n16



afaict this leads to the following situation:
* the initial `uninative_event_enable` "fails", as no `UNINATIVE_LOADER
` path exists
* the recipes are parsed with original `PATH`
* during `BuildStarted`, the `UNINATIVE_LOADER` is populated and
`enable_uninative` is called from `uninative_event_fetchloader`,
extending `PATH`
* reparsing sees a different `PATH`



now i'm wondering, what's the correct way to fix this?

thanks a lot,
tim

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

Re: [yocto] [meta-mingw] QEMU on thud mingw SDK is broken

[Sinan Kaya]

On 8/26/2019 9:47 PM, Joshua Watt wrote:
> No, I don't think that is supported. Just to make sure, did you try
> building with
> 
>  SDKMACHINE = "x86_64-mingw32"
> 
> to try building the entire SDK as 64-bit?

Yup, that's what I have been using.

SDKMACHINE = "x86_64-mingw32"


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

Re: [linux-yocto] [PATCH] module: Fix build failure due to cracked commit

[Bruce Ashfield]

oops. Sorry about that, I forgot to push the resolution I did earlier
today for this. It should be in the tree now.

Bruce

On Mon, Aug 26, 2019 at 10:14 PM  wrote:
>
> From: He Zhe 
>
> This is the missing half of the following commit that is cracked during 
> merging,
> which causes build failure.
> 3b5be16c7e90 ("modules: page-align module section allocations only for arches 
> supporting strict module rwx")
>
> Signed-off-by: He Zhe 
> ---
> This is for every branches of linux-yocto-dev.
>
>  kernel/module.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 92e3c2e..9ee9342 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -69,6 +69,9 @@
>   */
>  #ifdef CONFIG_ARCH_HAS_STRICT_MODULE_RWX
>  # define debug_align(X) ALIGN(X, PAGE_SIZE)
> +#else
> +# define debug_align(X) (X)
> +#endif
>
>  /* If this is set, the section belongs in the init part of the module */
>  #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
> --
> 2.7.4
>


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

[linux-yocto] [PATCH] module: Fix build failure due to cracked commit

[zhe.he]

From: He Zhe 

This is the missing half of the following commit that is cracked during merging,
which causes build failure.
3b5be16c7e90 ("modules: page-align module section allocations only for arches 
supporting strict module rwx")

Signed-off-by: He Zhe 
---
This is for every branches of linux-yocto-dev.

 kernel/module.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/module.c b/kernel/module.c
index 92e3c2e..9ee9342 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -69,6 +69,9 @@
  */
 #ifdef CONFIG_ARCH_HAS_STRICT_MODULE_RWX
 # define debug_align(X) ALIGN(X, PAGE_SIZE)
+#else
+# define debug_align(X) (X)
+#endif
 
 /* If this is set, the section belongs in the init part of the module */
 #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
-- 
2.7.4

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

Re: [yocto] [meta-mingw] QEMU on thud mingw SDK is broken

[Joshua Watt]

On Mon, Aug 26, 2019 at 4:47 PM Sinan Kaya  wrote:
>
> On 8/26/2019 5:33 PM, Joshua Watt wrote:
> > On 8/19/19 7:30 AM, Sinan Kaya wrote:
> >> I noticed last week that qemu packaged into mingw sdk is broken while
> >> the qemu in linux sdk works fine.
> >>
> >> Qemu crashes very early while launching the kernel boot.
> >> This used to work fine on sumo.
> >>
> >> Does anybody see this problem too?
> >
> > Doesn't look like it. I wasn't aware that QEMU even worked in MinGW in
> > the first place :)
> >
> > Is it included in the default SDK, or did you add it manually?
>
> It is included by default similar to Linux SDK. The difference is mingw
> one doesn't work :)
>
> I tried cross-compiling QEMU 3.0.0 against mingw32 and didn't have much
> luck either.
>
> The only thing that worked is mingw64.
>
> I don't know if we can mix and match ming64 with meta-mingw.

No, I don't think that is supported. Just to make sure, did you try
building with

 SDKMACHINE = "x86_64-mingw32"

to try building the entire SDK as 64-bit?

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

Re: [yocto] [meta-mingw] QEMU on thud mingw SDK is broken

[Sinan Kaya]

On 8/26/2019 5:33 PM, Joshua Watt wrote:
> On 8/19/19 7:30 AM, Sinan Kaya wrote:
>> I noticed last week that qemu packaged into mingw sdk is broken while
>> the qemu in linux sdk works fine.
>>
>> Qemu crashes very early while launching the kernel boot.
>> This used to work fine on sumo.
>>
>> Does anybody see this problem too?
> 
> Doesn't look like it. I wasn't aware that QEMU even worked in MinGW in
> the first place :)
> 
> Is it included in the default SDK, or did you add it manually?

It is included by default similar to Linux SDK. The difference is mingw
one doesn't work :)

I tried cross-compiling QEMU 3.0.0 against mingw32 and didn't have much
luck either.

The only thing that worked is mingw64.

I don't know if we can mix and match ming64 with meta-mingw.

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

Re: [yocto] [meta-mingw] QEMU on thud mingw SDK is broken

[Joshua Watt]

On 8/19/19 7:30 AM, Sinan Kaya wrote:

I noticed last week that qemu packaged into mingw sdk is broken while
the qemu in linux sdk works fine.

Qemu crashes very early while launching the kernel boot.
This used to work fine on sumo.

Does anybody see this problem too?


Doesn't look like it. I wasn't aware that QEMU even worked in MinGW in 
the first place :)


Is it included in the default SDK, or did you add it manually?

If you do happen to get it fixed, can you look at writing a test case 
for it so that it doesn't break in the future?






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

Re: [yocto] npm nodejs

[Jonas Andersson]

cool, get the feeling that this is an way in the right  direction.
Have you dropped the use of shrinkwrap an lockdown files?
As I understand npm package lock files have replaced this?

Den ons 21 aug. 2019 kl 21:24 skrev Stefan Herbrechtsmeier <
ste...@herbrechtsmeier.net>:

> Hi Jonas,
>
> Am 21.08.19 um 14:55 schrieb Jonas Andersson:
> > I have used Yocto and npm/nodejs now for about 1 year and think it works
> > but I not without some extra work. Are there any group working on
> > npm/nodejs? As I use it quite frequent and puts some extra work every
> > time i create an recipe I have some interest in supporting the work on
> > npm/nodejs to make it an better experience.
> >
> > I thinks It quite hard to follow all the npm/nodejs parts of
> > Yocto(devtool, fetcher and meta-oe/../nodejs), I get the feeling that
> > all parts not are in sync.
>
> I have start reworking the nodejs support but haven't the time to finish
> it.
>
> I have remove the use of the bitbake npm fetcher. I create a recipe per
> npm package major version. Thereby the recipe downloads the npm archive
> via https, extract it to /usr/lib/node_modules/name-major and creates
> links for the dependency packages and binaries. This avoids duplicated
> npm packages and allows a per package optimization like the remove of
> scripts, tests and documentations. Furthermore I can patch npm packages
> to use dynamic linking or build native packages.
>
> I have add a new plugin to the recipetool which creates a recipe from a
> npm package. It extract the license, dependencies and binaries from the
> package.json. Thereby the dependencies string is parsed and translated
> into a - or -0. version> if major version is below 0. I assume that I can ignore the
> minor and patch version number and always use the latest compatible
> version.
>
> On top of recipetool I have a script with creates a recipe for a npm
> package and all its dependencies.
>
>
> Regards
>Stefan
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel modul install

[Rudolf J Streif]

Michael,

You might want to share your recipe.

Since do_install works on a private sysroot for your recipe it is
unlikely that your module conflicts with a module with the same name
from another recipe. You might install the module twice or you might
have some leftovers from your development process. You might want to
start with a clean environment: bitbake -c cleanall .

:rjs

On 8/26/19 7:15 AM, Michael Eichhorn wrote:
> Dear all,
>  
> i am new to yocto and i created a recipe for a kernel modul for my bt
> and wifi chip.
> it seems that everthing works, but in my do_install i receive an error:
> ...is trying to install files into a shared area when those files
> already exist...
> My receipe is somehow producing an bluetooth.ko which is already
> existing because
> of my linux-mainline recipe.
> What can i do? the relevant one is the one from my chip recipe.
>  
> Best regards,
> Michael
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.42

[Paul Gortmaker]

[Re: v4.18.x - stable updates comprising v4.18.42] On 25/08/2019 (Sun 22:10) 
Bruce Ashfield wrote:

> On Sun, Aug 18, 2019 at 10:14 AM Paul Gortmaker
>  wrote:
> >
> > Bruce, Yocto kernel folks:
> >
> > Here is the next 4.18.x stable update "extension" primarily created
> > for the Yocto project, continuing from the previous v4.18.41 release.

[...]

> Hey Paul,
> 
> I was merging this tonight and ran into a nasty -rt merge conflict in
> kernel/irq_work.c. Can you take a look and send a resolution ? When I
> compared the 4.19-rt and 5.x-rt branches, I didn't see an obvious way
> to resolve things.

So it might not have been obvious, but there is a 4.19-rt resolution
buried in there in linux-stable-rt

commit e51f31ad716a485ed5bada8d367df60d6a99b9ac
Merge: 3cfcdc4d74dc 0df021b2e841
Author: Steven Rostedt (VMware) 
Date:   Fri Jun 14 12:54:23 2019 -0400
Merge tag 'v4.19.47' into v4.19-rt

This is the 4.19.47 stable release

 Conflicts:
drivers/char/random.c
kernel/irq_work.c

...and since the 4.18.42 irq_work.c is identical to 4.19.47, we can just
re-use Steve's conflict resolution by wholesale importing the 4.19-rt
version of his file after his merge.

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

[yocto] WARNING: bluez5-5.50-r0 do_fetch: Failed to fetch URL file://variscite-bt.conf

[Zoran Stojsavljevic]

Hello Folks,

While doing the following YOCTO build:
http://variwiki.com/index.php?title=Yocto_Build_Release=RELEASE_MORTY_V1

Actually, using the latest available tag: thud-fslc-4.14.78-mx6ul-v1.1

>From https://github.com/varigit/variscite-bsp-platform/tags

I've got the following error, while compiling for both:
bitbake -k fsl-image-gui
bitbake -k fsl-image-qt5

Seems, that the local file: file://variscite-bt.conf is somehow missing?!

I can add this file artificially, but, the question is: why this file is
missing???
___

Transcript follows:
bluez5-5.50-r0 do_fetch: Failed to fetch variscite-bt.conf
https://pastebin.com/U9LRtNwr

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

[yocto] kernel modul install

[Michael Eichhorn]

Dear all,

 

i am new to yocto and i created a recipe for a kernel modul for my bt and wifi chip.

it seems that everthing works, but in my do_install i receive an error:

...is trying to install files into a shared area when those files already exist...

My receipe is somehow producing an bluetooth.ko which is already existing because

of my linux-mainline recipe.

What can i do? the relevant one is the one from my chip recipe.

 

Best regards,

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

Re: [linux-yocto] [linux-yocto-dev] Merge tag 'v5.3-rc6' into standard/base

[Bruce Ashfield]

On Mon, Aug 26, 2019 at 6:50 AM Jun Miao  wrote:
>
> Hi Bruce,
>
>I am sorry to trouble you .
>
>When you merge tag 'v5.3-rc6' into standard/base, why you delete  "define 
> debug_align(X) (X)" and lose the "#endif" (#ifend ... #endif)  ?
>

Hmm. That wasn't on purpose. My builds ran overnight, so I'll have a
look and fix it up.

Bruce

>
> --
>
> commit b73b90b1d2cc6b4ba740e66479ab054482174f94
> Merge: ce4ec6f a55aa89
> Author: Bruce Ashfield 
> Date:   Sun Aug 25 22:28:04 2019 -0400
>
> Merge tag 'v5.3-rc6' into standard/base
>
> Linux 5.3-rc6
>
> Signed-off-by: Bruce Ashfield 
>
> diff --cc kernel/module.c
> index cd8df51,9ee9342..92e3c2e
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@@ -64,9 -64,14 +64,11 @@@
>
>   /*
>* Modules' sections will be aligned on page boundaries
> -  * to ensure complete separation of code and data
> +  * to ensure complete separation of code and data, but
> +  * only when CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
>*/
> + #ifdef CONFIG_ARCH_HAS_STRICT_MODULE_RWX
>   # define debug_align(X) ALIGN(X, PAGE_SIZE)
>  -#else
>  -# define debug_align(X) (X)
>  -#endif
>
>
> --
> Thanks
> Jun



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

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Ola x Nilsson]

You now have nonstandard library names, which will confuse the
package-split and automatic library dependency checker.  As a result, a
dependency is added from the applibrary on app-dev.  But depending on
-dev packages is a no-no, hence the QA error.

I have no idea whether the renameing of the library is a correct thing -
it looks weird to me - but if it is, you need to fix the packaging by
maniplating the FILES_* variables in your recipe.  You can inspect the
results of package separation in the packages-split folder for your
recipe.

/Ola


On Tue, Aug 06 2019, JH wrote:

> Thanks Alex, here is the error in my application build, it used working well:
>
> ERROR: app_library-1.0.0-0 do_package_qa: QA Issue: app_library
> rdepends on app_library-dev [dev-deps]
> ERROR: app_library-1.0.0-0 do_package_qa: QA run found fatal errors.
> Please consider fixing them.
> ERROR: app_library-1.0.0-0 do_package_qa: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /home/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/app_library/1.0.0-0/temp/log.do_package_qa.6626
> ERROR: Task 
> (/home/build/oe-core/../meta-app/recipes-core/app_library/app_library_git.bb:do_package_qa)
> failed with exit code '1'
>
> There is no do_package_qa in my app_library_git.bb, where is that
> do_package_qa from? how can I disable it? It sounds every easy in the
> document to disable it, but it did not give any clues -:(.
>
> Thank you.
>
> Kind regards,
>
> - jh
> On 8/6/19, Alexander Kanavin  wrote:
>> It may help if you copy-paste the exact error you are getting, and the
>> content of the directory where it happens.
>>
>> Alex
>>
>> On Tue, 6 Aug 2019 at 13:09, JH  wrote:
>>
>>> On 8/6/19, Alexander Kanavin  wrote:
>>> > You don't; package_qa is reporting real issues with your packaging, so
>>> you
>>> > need to address them.
>>>
>>> Well, my first issue is I need to build it, the document said it can
>>> be disabled, but did not say how, appreciate anyone helps how to
>>> disable it.
>>>
>>> Thank you
>>>
>>>
>>> > Alex
>>> >
>>> > On Tue, 6 Aug 2019 at 10:40, JH  wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> According to the latest document:
>>> >>
>>> >> "Package QA checks are now performed during a new do_package_qa task
>>> >> rather than being part of the do_package task. This allows more
>>> >> parallel execution. This change is unlikely to be an issue except for
>>> >> highly customized recipes that disable packaging tasks themselves by
>>> >> marking them as noexec. For those packages, you will need to disable
>>> >> the do_package_qa task as well."
>>> >>
>>> >> How can I disable the do_package_qa task?
>>> >>
>>> >> Thank you.
>>> >>
>>> >> Kind regards,
>>> >>
>>> >> - jh
>>> >>
>>> >> On 8/4/19, JH  wrote:
>>> >> > Hi,
>>> >> >
>>> >> > I was running my Yocto build fine until I had a minor change to move
>>> >> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so
>>> >> > to
>>> >> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
>>> >> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
>>> >> > errors, please consider fixing them.
>>> >> >
>>> >> > Even I reverse the changes back the, it still complained the same
>>> >> > error.
>>> >> >
>>> >> > I don't have do_package_qa in my bb file, where is it from? What is
>>> >> > that error about? How to fix it?
>>> >> >
>>> >> > Thank you.
>>> >> >
>>> >> > Kind regards,
>>> >> >
>>> >> > - jh
>>> >> >
>>> >> --
>>> >> ___
>>> >> 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] U-boot recipe fails for the master branch(new sbc)

[nishant poorswani]

I managed to use dtc-1.14.5. Getting other errors while compiling now.

Here is the log: https://pastebin.com/2i5vRrTx

Maybe it's because of the gcc version. I had used rocko which has gcc-7.3
as the default compiler.

Regards,
Nishant Poorswani

On Sun, Aug 25, 2019 at 11:17 PM akuster  wrote:

>
>
> On 8/25/19 2:15 AM, nishant poorswani wrote:
>
> Hi,
>
> I'm trying to add a new board called rock-pi-s to the yocto project. I've
> succesfully done it for the rocko branch. Now I'm moving it to the master
> branch. I'm facing issues with u-boot. Here is the log for it:
>
> https://pastebin.com/NAxqsvcB
>
> It seems the libfdt from dtc-1.5.0 is incompatible with the older versions
> of u-boot. Can anyone recommend a method to fix it? Any help is
> appreciated.
>
>
> You can try having your own recipe for the version you need and then use
> PREFERRED_VERSION to set the version you want.
>
> - armin
>
>
> Regards,
> Nishant Poorswani
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [linux-yocto-dev] Merge tag 'v5.3-rc6' into standard/base

[Jun Miao]

Hi Bruce,

   I am sorry to trouble you .

   When you merge tag 'v5.3-rc6' into standard/base, why you delete  
"define debug_align(X) (X)" and lose the "#endif" (#ifend ... #endif)  ?



--

commit b73b90b1d2cc6b4ba740e66479ab054482174f94
Merge: ce4ec6f a55aa89
Author: Bruce Ashfield 
Date:   Sun Aug 25 22:28:04 2019 -0400

    Merge tag 'v5.3-rc6' into standard/base

    Linux 5.3-rc6

    Signed-off-by: Bruce Ashfield 

diff --cc kernel/module.c
index cd8df51,9ee9342..92e3c2e
--- a/kernel/module.c
+++ b/kernel/module.c
@@@ -64,9 -64,14 +64,11 @@@

  /*
   * Modules' sections will be aligned on page boundaries
-  * to ensure complete separation of code and data
+  * to ensure complete separation of code and data, but
+  * only when CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
   */
+ #ifdef CONFIG_ARCH_HAS_STRICT_MODULE_RWX
  # define debug_align(X) ALIGN(X, PAGE_SIZE)
 -#else
 -# define debug_align(X) (X)
 -#endif


--
Thanks
Jun

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

Re: [yocto] Conditional include in image recipe.

[Quentin Schulz]

Hi Mauro,

On Sat, Aug 24, 2019 at 12:19:08PM +0200, Mauro Ziliani wrote:
> Hi all
> 
> I working on a image recipe.
> 
> If I include the layer meta-raspberrypi layer  I'd like to include
> recipes-code/images/rpi-basic-image-bb.
> 
> While if i not include meta-raspberrypi layer I don't include
> rpi-basic-image.
> 

Or you can just safely ignore if the file does not exist (for Yocto,
which most likely means that the layer is not included).

You have two "include" mechanisms for non-class files:
 * require
 * include

"Require" requires the file to be there and fails otherwise while
"include" tries to include the file, if it's not there, it continues.

https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#include-directive
https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#require-inclusion

Quentin
-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Conditional include in image recipe.

[Erik Botö]

Hi,

On Sat, Aug 24, 2019 at 12:20 PM Mauro Ziliani  wrote:
>
> Hi all
>
> I working on a image recipe.
>
> If I include the layer meta-raspberrypi layer  I'd like to include
> recipes-code/images/rpi-basic-image-bb.
>
> While if i not include meta-raspberrypi layer I don't include
> rpi-basic-image.
>
>
> How can I do that?

I think this should just work if you use "include
recipes-core/images/rpi-basic-image.bb" in the recipe, since "include"
only includes a file if it exist and will not fail if it doesn't
exist. As opposed to "require" which will do the same as "include" if
the file exist, but fail if it doesn't exist.

Cheers,
Erik

>
>
> I don't understand, but I suppose I need to read bitbake manual.
>
>
> MZ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto