Re: [yocto] dynamic-layers?
Hello.
I further did some debugging and BBFOLE_COLLECTION when used in the following
'for' expansion contains only subset of what is avilable finally in
BBFILE_COLLECTION (as appears in '-e' log).
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend'
>% layer \
> for layer in BBFILE_COLLECTIONS.split())}"
I am confused if this is a normal behavior.
From: Takashi Matsuzawa
Sent: Thursday, May 25, 2017 10:03 AM
To: Nicolas Dechesne
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?
Hello.
>e.g. if you have meta-qt5 in BBLAYERS in /conf/bblayers.conf, then the
>recipes from "dynamic-layers/qt5-layer" are used as well.
Thanks now I can see how it is expected to work.
My issue here now is that some dynamyc-layers/ not being added to
BBFILES list.
I tried '-e' switch with my build tree and here is what I can see.
I think this is caused by BBFILE_COLLECTIONS evaluation timing? - but I am
still looking into to find the cause.
1) .conf files read
I think these are the conf files recognized by the build sytem.
I cansee meta-qt5 there.
#
# INCLUDE HISTORY:
#
# /home/xxx/build-root/build/conf/bblayers.conf
# /home/xxx/build-root/meta-freescale/conf/layer.conf
# /home/xxx/build-root/meta-freescale-3rdparty/conf/layer.conf
# /home/xxx/build-root/meta-freescale-distro/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-netboot/conf/layer.conf
#
/home/xxx/build-root/meta-intel-iot-security/meta-security-smack/conf/layer.conf
#
/home/xxx/build-root/meta-intel-iot-security/meta-security-framework/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-app-framework/conf/layer.conf
# /home/xxx/build-root/meta-qt5/conf/layer.conf
...
2) BBFILE_COLLECTIONS
And I can see 'qt5-layer' is being added to BBFILE_COLLECTIONS, so it
'qt5-layer' folder in every dynamic-layers should be picked into BBFILE list.
BBFILE_COLLECTIONS=" freescale-layer fsl-arm-extra fsl-demos
meta-netboot security-smack security-framework app-framework qt5-layer
agl-demo openembedded-layer multimedia-layer efl-layer
networking-layer meta-python ivi-common agl agl-distro aglbsp core
yocto"
3) BBFILES
But I cannot find it in BBFILES list.
Only the first 4 layers (freescale-layer/fsl-arm-extra/fsl-demos/meta-netboot)
in BBFILE_COLLECTIONS are used in wildecard parameter.
BBFILES="/home/xxx/build-root/meta-freescale/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale/recipes-*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bbappend
...
From: Nicolas Dechesne
Sent: Wednesday, May 24, 2017 11:19 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?
On Wed, May 24, 2017 at 12:30 PM, Takashi Matsuzawa wrote:
> Hello, Yocto.
> I am a bit confused with dynamic-layers included in some of the recent
> layers in various BSPs.
>
> e.g.
>
> https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf
>
>># The .bbappend and .bb files are included if the respective layer
>># collection is available.
>>BBFILES += "${@'
>> '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
>> for layer in BBFILE_COLLECTIONS.split())}"
>>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>> layer \
>> for layer in BBFILE_COLLECTIONS.split())}"
>
> In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc.
> for conditional inclusion.
> And I think they are included only their names (browser-layer, etc.) are
> BBFILE_COLLECIONS.
>
> Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS
> when I want to include browser-layer in my build.
>
> Is it something to be done in my local.conf or customized distro conf file?
what that means is that recipe from the dynamic-layers/ will be
parsed/added *only if* is already added in your build
environment. e.g. if you have meta-qt5 in BBLAYERS in
/conf/bblayers.conf, then the recipes from
"dynamic-layers/qt5-layer" are used as well.
This is mostly to allow a BSP layer to be used with as many
combinations of layers as possible.
--
___
yocto mailing list
yocto@yoctoprojec
Re: [yocto] webkitgtk2 progress bar
On Wed, May 24, 2017 at 9:17 PM, Trevor Woerner wrote: > On Wed, May 24, 2017 at 1:16 PM, Martin Jansa wrote: >> My "bitbake world" builds have few components like this, webkitgtk (used to >> have webkit1, webkit2 and webkit2-efl as separate builds), 2 chromiums (x11 >> and wayland), cef (luckily broken and whitelisted for a while), firefox, >> qtwebengine, qtwebkit. Each taking usually even more time than "simplest" >> webkitgtk2. > > ...speaking of which... > > It's probably about time someone sends a patch to remove cef, it has > been a while since anyone cared for it. yes please remove it. I was the one who was probably most interested in it in past. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can Yocto treat layers like an external package?
Il 25 mag 2017 6:12 AM, "Trevor Woerner" ha scritto: Hi Yannick, This is a feature many people have been wanting for a while, but getting there has been slow. So slow, in fact, that many projects have simply gone ahead and implemented their own solutions, all of which are different from each other, making it all that much harder to get everyone back together to support one idea :-( As Gary mentions, "repo" is a popular solution. See, for example, how the Linaro people have done it with their "rpb" distro and associated setup tools/scripts: https://github.com/96boards/oe-rpb-manifest The freescale project was the first such instance I saw (but I can't say whether they were the first or not): https://github.com/Freescale/fsl-community-bsp-platform http://freescale.github.io/#download Mark Hatle (windriver) has been working on and releasing a tool they've been using internally for a while: https://www.openembedded.org/wiki/OEDEM_2016#Windriver_.E2. 80.98setup.E2.80.99_Demo I'm sure there are better links for Mark's work, but I can't find them at the moment. Hopefully someone jumps in and fills in the blanks :-) https://github.com/Wind-River/wr-lx-setup I'm sure there are other such examples. -- ___ 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] sstate-cache question
On 2017-05-23 07:27, Gary Thomas wrote: On 2017-05-22 22:35, Paul Eggleton wrote: Hi Gary, On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote: I have a build where I've never manually removed anything from the sstate-cache and this same build has been used for hundreds of builds over the last 18 months. I just tried to find out why gcc-cross-arm had to be rebuilt (it seems to happen almost every time I update my Poky/Yocto tree (master)). Here's what I got: $ bitbake-diffsigs -t gcc-cross-arm compile Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to d65095d4b9aff89f6990bd17c0ab210b Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes- devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b So if I didn't remove those files, where did they go? Am I doing something wrong running this tool? (running the same command for qemu-native seemed to work correctly) Is this with master, pyro, morty or some other version? Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06 If you search for files with those hashes in their name do they show up? Only .siginfo files: $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*" sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*" sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo However, I do find some in tmp/stamps: $ ls tmp/stamps/x86_64-linux/gcc-cross-arm 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210 I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'? I do occasionally wipe tmp & downloads, so that may explain these errors. I just updated my Poky/Yocto master (a3d160f9e5826140cc8d6b2ed1b38bf022443b08) and it happened again. I'm still interested in why gcc-cross-arm had to be rebuilt _again_, so I ran: $ bitbake-diffsigs -t gcc-cross-arm compile NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466, PID: 7995 Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from d65095d4b9aff89f6990bd17c0ab210b to 1378c7a11d96284c3d53894d6434b590 Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes d65095d4b9aff89f6990bd17c0ab210b or 1378c7a11d96284c3d53894d6434b590 NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466, PID: 7995 NOTE: Terminating PRServer... $ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name "*1378c7a11d96284c3d53894d6434b590*" tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590 tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.1378c7a11d96284c3d53894d6434b590 So, a similar error/outcome, but in this case the necessary files do seem to be present. I did notice that the only files with those signatures were for do_configure, so I tried: $ bitbake-diffsigs -t gcc-cross-arm configure NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34530, PID: 8063 Hash for dependent task gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot changed from 150112323551011e0e87f99f47ad79c4 to c45aaef0cb01f463f9a1b30bd
Re: [yocto] webkitgtk2 progress bar
On Wed, May 24, 2017 at 1:16 PM, Martin Jansa wrote: > My "bitbake world" builds have few components like this, webkitgtk (used to > have webkit1, webkit2 and webkit2-efl as separate builds), 2 chromiums (x11 > and wayland), cef (luckily broken and whitelisted for a while), firefox, > qtwebengine, qtwebkit. Each taking usually even more time than "simplest" > webkitgtk2. ...speaking of which... It's probably about time someone sends a patch to remove cef, it has been a while since anyone cared for it. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can Yocto treat layers like an external package?
Hi Yannick, This is a feature many people have been wanting for a while, but getting there has been slow. So slow, in fact, that many projects have simply gone ahead and implemented their own solutions, all of which are different from each other, making it all that much harder to get everyone back together to support one idea :-( As Gary mentions, "repo" is a popular solution. See, for example, how the Linaro people have done it with their "rpb" distro and associated setup tools/scripts: https://github.com/96boards/oe-rpb-manifest The freescale project was the first such instance I saw (but I can't say whether they were the first or not): https://github.com/Freescale/fsl-community-bsp-platform http://freescale.github.io/#download Mark Hatle (windriver) has been working on and releasing a tool they've been using internally for a while: https://www.openembedded.org/wiki/OEDEM_2016#Windriver_.E2.80.98setup.E2.80.99_Demo I'm sure there are better links for Mark's work, but I can't find them at the moment. Hopefully someone jumps in and fills in the blanks :-) I'm sure there are other such examples. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include libraries?
On 2017-05-24 15:49, Gary Thomas wrote: On 2017-05-24 15:26, Burton, Ross wrote: On 24 May 2017 at 13:20, Gary Thomas mailto:g...@mlbassoc.com>> wrote: I have an image which needs to include the libcups2 package from the cups recipe. If I try adding this to my image recipe CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" I get this error: ERROR: Required build target 'my-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-demo-image', 'libcups2'] However, I can get it to build with this MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" What's the difference between these two approaches and why doesn't the first one work at all? Does the latter actually work? Recommends won't fail if the package doesn't exist, or is getting pulled in via another route. I've a feeling that you actually want the pre-renaming name here so try cups-lib. Thanks, I'm rebuilding the image (after a Poky/master pull) and will let you know. BTW, that would be awfully confusing to require cups-lib when building but my package manager (opkg) only knows about the [renamed] package libcups2. You were correct, using MACHINE_EXTRA_RRECOMMENDS didn't work, but explicitly including cups-lib did. Not very intuitive :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux] [PATCH] audit: 2.7.1 -> 2.7.6
Upgrade audit from 2.7.1 to 2.7.6
Signed-off-by: zhengrq
---
recipes-security/audit/{audit_2.7.1.bb => audit_2.7.6.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-security/audit/{audit_2.7.1.bb => audit_2.7.6.bb} (96%)
diff --git a/recipes-security/audit/audit_2.7.1.bb
b/recipes-security/audit/audit_2.7.6.bb
similarity index 96%
rename from recipes-security/audit/audit_2.7.1.bb
rename to recipes-security/audit/audit_2.7.6.bb
index 975e6e9..75d4d23 100644
--- a/recipes-security/audit/audit_2.7.1.bb
+++ b/recipes-security/audit/audit_2.7.6.bb
@@ -15,8 +15,8 @@ SRC_URI =
"http://people.redhat.com/sgrubb/${BPN}/${BPN}-${PV}.tar.gz \
file://auditd.service \
file://audit-volatile.conf \
"
-SRC_URI[md5sum] = "b224ea6f000c8281e5deee86903ac5ba"
-SRC_URI[sha256sum] =
"0441790794fd9375dbca598fa0ffb46c57ff37b3a24b94ffec0bbee3215cca09"
+SRC_URI[md5sum] = "55a81bbed973b58a90590c949e71dc3e"
+SRC_URI[sha256sum] =
"fa65289cffdc95a25bfbdba541f43ee1b12c707090a38fd027dcf9354b9014e7"
inherit autotools pythonnative update-rc.d systemd
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dynamic-layers?
Hello.
>e.g. if you have meta-qt5 in BBLAYERS in /conf/bblayers.conf, then the
>recipes from "dynamic-layers/qt5-layer" are used as well.
Thanks now I can see how it is expected to work.
My issue here now is that some dynamyc-layers/ not being added to
BBFILES list.
I tried '-e' switch with my build tree and here is what I can see.
I think this is caused by BBFILE_COLLECTIONS evaluation timing? - but I am
still looking into to find the cause.
1) .conf files read
I think these are the conf files recognized by the build sytem.
I cansee meta-qt5 there.
#
# INCLUDE HISTORY:
#
# /home/xxx/build-root/build/conf/bblayers.conf
# /home/xxx/build-root/meta-freescale/conf/layer.conf
# /home/xxx/build-root/meta-freescale-3rdparty/conf/layer.conf
# /home/xxx/build-root/meta-freescale-distro/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-netboot/conf/layer.conf
#
/home/xxx/build-root/meta-intel-iot-security/meta-security-smack/conf/layer.conf
#
/home/xxx/build-root/meta-intel-iot-security/meta-security-framework/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-app-framework/conf/layer.conf
# /home/xxx/build-root/meta-qt5/conf/layer.conf
...
2) BBFILE_COLLECTIONS
And I can see 'qt5-layer' is being added to BBFILE_COLLECTIONS, so it
'qt5-layer' folder in every dynamic-layers should be picked into BBFILE list.
BBFILE_COLLECTIONS=" freescale-layer fsl-arm-extra fsl-demos
meta-netboot security-smack security-framework app-framework qt5-layer
agl-demo openembedded-layer multimedia-layer efl-layer
networking-layer meta-python ivi-common agl agl-distro aglbsp core
yocto"
3) BBFILES
But I cannot find it in BBFILES list.
Only the first 4 layers (freescale-layer/fsl-arm-extra/fsl-demos/meta-netboot)
in BBFILE_COLLECTIONS are used in wildecard parameter.
BBFILES="/home/xxx/build-root/meta-freescale/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale/recipes-*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bbappend
...
From: Nicolas Dechesne
Sent: Wednesday, May 24, 2017 11:19 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?
On Wed, May 24, 2017 at 12:30 PM, Takashi Matsuzawa wrote:
> Hello, Yocto.
> I am a bit confused with dynamic-layers included in some of the recent
> layers in various BSPs.
>
> e.g.
>
> https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf
>
>># The .bbappend and .bb files are included if the respective layer
>># collection is available.
>>BBFILES += "${@'
>> '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
>> for layer in BBFILE_COLLECTIONS.split())}"
>>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>> layer \
>> for layer in BBFILE_COLLECTIONS.split())}"
>
> In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc.
> for conditional inclusion.
> And I think they are included only their names (browser-layer, etc.) are
> BBFILE_COLLECIONS.
>
> Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS
> when I want to include browser-layer in my build.
>
> Is it something to be done in my local.conf or customized distro conf file?
what that means is that recipe from the dynamic-layers/ will be
parsed/added *only if* is already added in your build
environment. e.g. if you have meta-qt5 in BBLAYERS in
/conf/bblayers.conf, then the recipes from
"dynamic-layers/qt5-layer" are used as well.
This is mostly to allow a BSP layer to be used with as many
combinations of layers as possible.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web][PATCH] views: support querying by layer name
Hi Jose,
Sorry for the extreme delay reviewing this.
On Tuesday, 4 April 2017 7:31:29 AM NZST Jose Lamego wrote:
> This change supports querying recipes that belong to a specific layer
> by using the prefix "layer:" + the desired layer name, for example:
> "layer: openembedded-core" and this string can be used by itself or
> combined with other supported options.
>
> [YOCTO #6618]
>
> Signed-off-by: Jose Lamego
> ---
> layerindex/views.py | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/layerindex/views.py b/layerindex/views.py
> index 65a536a..5b66892 100644
> --- a/layerindex/views.py
> +++ b/layerindex/views.py
> @@ -383,13 +383,16 @@ class RecipeSearchView(ListView):
> query_string = self.request.GET.get('q', '')
> init_qs =
Recipe.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
>
> -# Support slightly crude search on inherits field
> +# Support slightly crude search on inherits/layer fields
> query_items = query_string.split()
> inherits = []
> +layers = []
> query_terms = []
> for item in query_items:
> if item.startswith('inherits:'):
> inherits.append(item.split(':')[1])
> +elif item.startswith('layer:'):
> +layers.append(item.split(':')[1])
> else:
> query_terms.append(item)
> if inherits:
> @@ -397,6 +400,14 @@ class RecipeSearchView(ListView):
> for inherit in inherits:
> init_qs = init_qs.filter(Q(inherits=inherit) |
Q(inherits__startswith=inherit + ' ') | Q(inherits__endswith=' ' + inherit) |
Q(inherits__contains=' %s ' % inherit))
> query_string = ' '.join(query_terms)
> +if layers:
> +for layer in layers:
> +init_qs = init_qs.filter(
> +Q(layerbranch__layer__name=layer) |
> +Q(layerbranch__layer__name__startswith=layer + ' ') |
> +Q(layerbranch__layer__name__endswith=' ' + layer) |
> +Q(layerbranch__layer__name__contains=' %s ' % layer))
> +query_string = ' '.join(query_terms)
Could we instead determine which layers match the query (i.e. the IDs), and
then do an layerbranch__layer__in (or layerbranch__layer__id__in, not sure
which)? That way we can also return a specific message if no layers match the
query. I'm not sure we really need the fuzzy matches either - just exact name
match.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline
On Wed, May 24, 2017 at 4:12 PM, Philip Balister wrote: > I'd check with Marex the u-boot maintainer also. He may have something > queued up. It is entirely possible he isn't on this list. Good point. Marek just posted a 2017.05 update to oecore :-) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline
On 05/24/2017 11:05 AM, Romain Perier wrote:
> Hello,
>
>
> Le 24/05/2017 à 16:55, Trevor Woerner a écrit :
>> On Wed, May 24, 2017 at 10:46 AM, Romain Perier
>> wrote:
>>> Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
u-boot 2017.05 was released May 10. Wouldn't it be better to update
oe-core's u-boot to 2017.05 then just add any differences in
meta-rockchip?
>>> Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
>>> v2017.05 in poky (and then propose changes in meta-rockchip)
>> Changes to u-boot should be sent to openembedded-core; poky gets
>> updated from there (not vice versa).
> Even, if I Cc: the ML oe-core and yocto ? (so I have to do the changes
> in oe-core directly, I mean the repo. right ?)
I'd check with Marex the u-boot maintainer also. He may have something
queued up. It is entirely possible he isn't on this list.
Also, one factor will be timing of u-boot releases versus the next YP
release. That will determine final version.
Philip
>
> Regards,
> Romain
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline
Hi Romain,
On Wed, May 24, 2017 at 11:05 AM, Romain Perier
wrote:
> Le 24/05/2017 à 16:55, Trevor Woerner a écrit :
>> On Wed, May 24, 2017 at 10:46 AM, Romain Perier
>> wrote:
>>> Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
u-boot 2017.05 was released May 10. Wouldn't it be better to update
oe-core's u-boot to 2017.05 then just add any differences in
meta-rockchip?
>>> Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
>>> v2017.05 in poky (and then propose changes in meta-rockchip)
>> Changes to u-boot should be sent to openembedded-core; poky gets
>> updated from there (not vice versa).
> Even, if I Cc: the ML oe-core and yocto ? (so I have to do the changes
> in oe-core directly, I mean the repo. right ?)
Yes. The "home" of the u-boot recipe is in openembedded-core. Please
send any updates/changes to the u-boot recipe to the openembedded-core
mailing list [http://lists.openembedded.org/mailman/listinfo/openembedded-core].
CC'ing it to other lists would not be polite since most OE/Yocto lists
receive quite a lot of traffic already and this would be a
non-relevant email to them.
Poky is derived from a bunch of sources, primarily openembedded-core,
plus some small additions of its own. Only when you want to change one
of these small additions would you send a patch to the poky mailing
list directly (which isn't the case with u-boot).
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] webkitgtk2 progress bar
> I have 22 cores here, and it is not a luxury, but an absolute necessity to get anything done as far as oe-core maintenance goes. Webkit's do_compile takes about half an hour - I can almost see that progress bar move :) Heh, you're lucky with "oe-core maintenance". My "bitbake world" builds have few components like this, webkitgtk (used to have webkit1, webkit2 and webkit2-efl as separate builds), 2 chromiums (x11 and wayland), cef (luckily broken and whitelisted for a while), firefox, qtwebengine, qtwebkit. Each taking usually even more time than "simplest" webkitgtk2. Building world with just oe-core takes just hour(s), add few layers like me and it's day(s). So progress bars are nice, but I still hate looking at them. On Wed, May 24, 2017 at 6:43 PM, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 05/24/2017 05:23 PM, Gary Thomas wrote: > >> Now [tongue-in-cheek], can someone do something about the horrendous >> build times for such packages (webkitgtk2 can take up to 3 hours on >> my [no so slow] build host!)? >> > > In order of decreasing tongue in cheekiness. > > 1. Rewrite webkit in something that is not C++ - by far the most awful > language when it comes to compile times. > > 2. Use icecc.bbclass to 'borrow' computing power from colleagues > (untested, unproven). > > 3. Invest into a serious CPU. I have 22 cores here, and it is not a > luxury, but an absolute necessity to get anything done as far as oe-core > maintenance goes. Webkit's do_compile takes about half an hour - I can > almost see that progress bar move :) > > Alex > > > -- > ___ > 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] webkitgtk2 progress bar
On 05/24/2017 05:45 PM, Martin Jansa wrote: You can try to use gold to save a bit of time linking the beast. webkit is already using gold by default, except for some architectures (aarch64, mips) where it used to fail - maybe it is not necessary anymore. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] webkitgtk2 progress bar
On 05/24/2017 05:23 PM, Gary Thomas wrote: Now [tongue-in-cheek], can someone do something about the horrendous build times for such packages (webkitgtk2 can take up to 3 hours on my [no so slow] build host!)? In order of decreasing tongue in cheekiness. 1. Rewrite webkit in something that is not C++ - by far the most awful language when it comes to compile times. 2. Use icecc.bbclass to 'borrow' computing power from colleagues (untested, unproven). 3. Invest into a serious CPU. I have 22 cores here, and it is not a luxury, but an absolute necessity to get anything done as far as oe-core maintenance goes. Webkit's do_compile takes about half an hour - I can almost see that progress bar move :) Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH] Fix unclosed file
On Mon, Nov 28, 2016 at 7:51 PM, Frank Meerkoetter <
meerkoet...@googlemail.com> wrote:
> WARNING: /projects/meta-chip/recipes-kernel/linux/linux-chip_git.bb:
> :14: ResourceWarning: unclosed file <_io.TextIOWrapper
> name='/projects/meta-chip/recipes-kernel/linux/linux-chip/defconfig'
> mode='r' encoding='UTF-8'>
> ---
> recipes-kernel/linux/linux-chip_git.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/recipes-kernel/linux/linux-chip_git.bb
> b/recipes-kernel/linux/linux-chip_git.bb
> index 6f0b193..38df4ad 100644
> --- a/recipes-kernel/linux/linux-chip_git.bb
> +++ b/recipes-kernel/linux/linux-chip_git.bb
> @@ -69,4 +69,6 @@ python () {
> if 'CONFIG_KERNEL_LZO=y\n' in configfile.readlines():
> depends = d.getVar('DEPENDS', False)
> d.setVar('DEPENDS', depends + ' lzop-native')
> +
> +configfile.close()
> }
Fixed in master and pyro. Thank you.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-chip][PATCH] Fix missing LICENSE field for u-boot-chip
On Mon, Nov 28, 2016 at 8:45 PM, Frank Meerkoetter < meerkoet...@googlemail.com> wrote: > ERROR: /projects/meta-chip/recipes-bsp/u-boot/u-boot-chip_git.bb: This > recipe does not have the LICENSE field set (u-boot-chip) > ERROR: Failed to parse recipe: /data/projects/rpi-a2dp-sink/ > meta-chip/recipes-bsp/u-boot/u-boot-chip_git.bb > --- > recipes-bsp/u-boot/u-boot-chip_git.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/recipes-bsp/u-boot/u-boot-chip_git.bb b/recipes-bsp/u-boot/ > u-boot-chip_git.bb > index 60db3e0..a5f2624 100644 > --- a/recipes-bsp/u-boot/u-boot-chip_git.bb > +++ b/recipes-bsp/u-boot/u-boot-chip_git.bb > @@ -2,6 +2,7 @@ require recipes-bsp/u-boot/u-boot.inc > > DESCRIPTION = "U-Boot port for C.H.I.P. boards" > > +LICENSE = "GPLv2+" > LIC_FILES_CHKSUM = "file://Licenses/README;md5= > 0507cd7da8e7ad6d6701926ec9b84c95" > > DEPENDS += "dtc-native" > > Fixed in master and pyro. Thank you. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline
Hello,
Le 24/05/2017 à 16:55, Trevor Woerner a écrit :
> On Wed, May 24, 2017 at 10:46 AM, Romain Perier
> wrote:
>> Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
>>> u-boot 2017.05 was released May 10. Wouldn't it be better to update
>>> oe-core's u-boot to 2017.05 then just add any differences in
>>> meta-rockchip?
>> Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
>> v2017.05 in poky (and then propose changes in meta-rockchip)
> Changes to u-boot should be sent to openembedded-core; poky gets
> updated from there (not vice versa).
Even, if I Cc: the ML oe-core and yocto ? (so I have to do the changes
in oe-core directly, I mean the repo. right ?)
Regards,
Romain
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline
On Wed, May 24, 2017 at 10:46 AM, Romain Perier
wrote:
> Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
>> u-boot 2017.05 was released May 10. Wouldn't it be better to update
>> oe-core's u-boot to 2017.05 then just add any differences in
>> meta-rockchip?
>
> Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
> v2017.05 in poky (and then propose changes in meta-rockchip)
Changes to u-boot should be sent to openembedded-core; poky gets
updated from there (not vice versa).
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can Yocto treat layers like an external package?
On 2017-05-24 16:39, Koehler, Yannick (HPN Aruba) wrote: In our development with Yocto, we use vendor provided layers. At this time we have to pull those manually (using git or submodule or other technics) to get the vendor layer on disk before bitbake can start. Does Yocto allow to automatically pull a yocto layer given a uri, branch and other information, similar way as it can pull the source of a package? This way, we could omit the vendor layer stuff from our git and instead have Yocto fetch the layer from its source (honoring all the premirror and mirror stuff). The layer specification would be similar to SRC_URI format with an additional parameter to indicate locally where to put the files, maybe with a default of vendor/ structure? git://g...@mylayer.company.com/layer-name.git;protocol=ssh;branch=master This would pull into vendors/layer-name Prior to parse all reccipes? Not part of the default Yocto setup, but what you are asking for seems to be a perfect fit for the [Android/Google] repo tool. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline
Hello,
Le 22/05/2017 à 18:08, Trevor Woerner a écrit :
> u-boot 2017.05 was released May 10. Wouldn't it be better to update
> oe-core's u-boot to 2017.05 then just add any differences in
> meta-rockchip?
Good idea yes. I will bump u-boot-common_${PV} and u-boot_2017.01 to
v2017.05 in poky (and then propose changes in meta-rockchip)
Regards,
Romain
>
> On Mon, May 22, 2017 at 11:17 AM, Romain Perier
> wrote:
>> This set of patches add a new u-boot-common file for 2017.05, so
>> it can be shared between u-boot-rockchip and a u-boot recipe for
>> mainline. Then, it add a bbappend to bump u-boot to the last
>> v2017.05.
>>
>> Romain Perier (3):
>> u-boot: Add u-boot-common_2017.05.inc
>> u-boot-rockchip: Use u-boot-common_2017.05.inc
>> u-boot: Add bbappend for u-boot mainline
>>
>> recipes-bsp/u-boot/u-boot-common_2017.05.inc | 14 ++
>> recipes-bsp/u-boot/u-boot-rockchip_git.bb| 2 +-
>> recipes-bsp/u-boot/u-boot_%.bbappend | 5 +
>> 3 files changed, 20 insertions(+), 1 deletion(-)
>> create mode 100644 recipes-bsp/u-boot/u-boot-common_2017.05.inc
>> create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend
>>
>> --
>> 1.8.3.1
>>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] webkitgtk2 progress bar
You can try to use gold to save a bit of time linking the beast. On Wed, May 24, 2017 at 4:46 PM, Leonardo Sandoval < leonardo.sandoval.gonza...@linux.intel.com> wrote: > On Wed, 2017-05-24 at 16:23 +0200, Gary Thomas wrote: > > I see that the latest master update has brought a progress bar > > for this (and presumably other 'cmake' based packages) - very nice :-) > > > > Now [tongue-in-cheek], can someone do something about the horrendous > > build times for such packages (webkitgtk2 can take up to 3 hours on > > my [no so slow] build host!)? > > > this is not easy and from my side what I have done some profiling based > on the buildstats to figure out the top consumers recipes/tasks. As you > mentioned, webkitgtk is the winner, at least for utimes! > > https://wiki.yoctoproject.org/wiki/MortyBuildstats > https://wiki.yoctoproject.org/wiki/TipsAndTricks/InvestigatingBuildTime > > Leo > > > > > > > -- > > > > Gary Thomas | Consulting for the > > MLB Associates |Embedded world > > > > > -- > ___ > 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] Can Yocto treat layers like an external package?
In our development with Yocto, we use vendor provided layers. At this time we have to pull those manually (using git or submodule or other technics) to get the vendor layer on disk before bitbake can start. Does Yocto allow to automatically pull a yocto layer given a uri, branch and other information, similar way as it can pull the source of a package? This way, we could omit the vendor layer stuff from our git and instead have Yocto fetch the layer from its source (honoring all the premirror and mirror stuff). The layer specification would be similar to SRC_URI format with an additional parameter to indicate locally where to put the files, maybe with a default of vendor/ structure? git://g...@mylayer.company.com/layer-name.git;protocol=ssh;branch=master This would pull into vendors/layer-name Prior to parse all reccipes? -- Yannick Koehler -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] webkitgtk2 progress bar
On Wed, 2017-05-24 at 16:23 +0200, Gary Thomas wrote: > I see that the latest master update has brought a progress bar > for this (and presumably other 'cmake' based packages) - very nice :-) > > Now [tongue-in-cheek], can someone do something about the horrendous > build times for such packages (webkitgtk2 can take up to 3 hours on > my [no so slow] build host!)? this is not easy and from my side what I have done some profiling based on the buildstats to figure out the top consumers recipes/tasks. As you mentioned, webkitgtk is the winner, at least for utimes! https://wiki.yoctoproject.org/wiki/MortyBuildstats https://wiki.yoctoproject.org/wiki/TipsAndTricks/InvestigatingBuildTime Leo > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] webkitgtk2 progress bar
I see that the latest master update has brought a progress bar for this (and presumably other 'cmake' based packages) - very nice :-) Now [tongue-in-cheek], can someone do something about the horrendous build times for such packages (webkitgtk2 can take up to 3 hours on my [no so slow] build host!)? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dynamic-layers?
On Wed, May 24, 2017 at 12:30 PM, Takashi Matsuzawa wrote:
> Hello, Yocto.
> I am a bit confused with dynamic-layers included in some of the recent
> layers in various BSPs.
>
> e.g.
>
> https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf
>
>># The .bbappend and .bb files are included if the respective layer
>># collection is available.
>>BBFILES += "${@'
>> '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
>> for layer in BBFILE_COLLECTIONS.split())}"
>>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>> layer \
>> for layer in BBFILE_COLLECTIONS.split())}"
>
> In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc.
> for conditional inclusion.
> And I think they are included only their names (browser-layer, etc.) are
> BBFILE_COLLECIONS.
>
> Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS
> when I want to include browser-layer in my build.
>
> Is it something to be done in my local.conf or customized distro conf file?
what that means is that recipe from the dynamic-layers/ will be
parsed/added *only if* is already added in your build
environment. e.g. if you have meta-qt5 in BBLAYERS in
/conf/bblayers.conf, then the recipes from
"dynamic-layers/qt5-layer" are used as well.
This is mostly to allow a BSP layer to be used with as many
combinations of layers as possible.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dynamic-layers?
On 2017-05-24 12:30, Takashi Matsuzawa wrote:
Hello, Yocto.
I am a bit confused with dynamic-layers included in some of the recent layers
in various BSPs.
e.g.
https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf
># The .bbappend and .bb files are included if the respective layer
># collection is available.
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend'
% layer \
> for layer in BBFILE_COLLECTIONS.split())}"
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
layer \
> for layer in BBFILE_COLLECTIONS.split())}"
In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc. for
conditional inclusion.
And I think they are included only their names (browser-layer, etc.) are
BBFILE_COLLECIONS.
Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS when
I want to include browser-layer in my build.
Is it something to be done in my local.conf or customized distro conf file?
No, it's in /conf/layer.conf for the in question.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] dynamic-layers?
Hello, Yocto.
I am a bit confused with dynamic-layers included in some of the recent layers
in various BSPs.
e.g.
https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf
># The .bbappend and .bb files are included if the respective layer
># collection is available.
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend'
>% layer \
> for layer in BBFILE_COLLECTIONS.split())}"
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>layer \
> for layer in BBFILE_COLLECTIONS.split())}"
In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc. for
conditional inclusion.
And I think they are included only their names (browser-layer, etc.) are
BBFILE_COLLECIONS.
Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS when
I want to include browser-layer in my build.
Is it something to be done in my local.conf or customized distro conf file?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include libraries?
On 2017-05-24 15:26, Burton, Ross wrote: On 24 May 2017 at 13:20, Gary Thomas mailto:g...@mlbassoc.com>> wrote: I have an image which needs to include the libcups2 package from the cups recipe. If I try adding this to my image recipe CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" I get this error: ERROR: Required build target 'my-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-demo-image', 'libcups2'] However, I can get it to build with this MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" What's the difference between these two approaches and why doesn't the first one work at all? Does the latter actually work? Recommends won't fail if the package doesn't exist, or is getting pulled in via another route. I've a feeling that you actually want the pre-renaming name here so try cups-lib. Thanks, I'm rebuilding the image (after a Poky/master pull) and will let you know. BTW, that would be awfully confusing to require cups-lib when building but my package manager (opkg) only knows about the [renamed] package libcups2. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include libraries?
On 24 May 2017 at 13:20, Gary Thomas wrote: > I have an image which needs to include the libcups2 package from > the cups recipe. If I try adding this to my image recipe > CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" > I get this error: > ERROR: Required build target 'my-demo-image' has no buildable providers. > Missing or unbuildable dependency chain was: ['my-demo-image', > 'libcups2'] > > However, I can get it to build with this > MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" > > What's the difference between these two approaches and why doesn't the > first > one work at all? > Does the latter actually work? Recommends won't fail if the package doesn't exist, or is getting pulled in via another route. I've a feeling that you actually want the pre-renaming name here so try cups-lib. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-cgl][PATCH] core-image-cgl: Remove ROOTFS_PKGMANAGE_BOOTSTRAP
run-postinsts is now installed by default in image.bbclass, so no need
to include it in each image.
Signed-off-by: Adrian Dudau
---
meta-cgl-common/images/core-image-cgl-initramfs.bb | 2 +-
meta-cgl-common/images/core-image-cgl.bb | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta-cgl-common/images/core-image-cgl-initramfs.bb
b/meta-cgl-common/images/core-image-cgl-initramfs.bb
index 2ebbdf5..477f069 100644
--- a/meta-cgl-common/images/core-image-cgl-initramfs.bb
+++ b/meta-cgl-common/images/core-image-cgl-initramfs.bb
@@ -3,7 +3,7 @@ require core-image-cgl.bb
# Recipe is based on core-image-minimal.bb
DESCRIPTION = "Initramfs used to mount multipath device as root file system"
-PACKAGE_INSTALL = "initramfs-cgl-boot busybox base-passwd udev
${ROOTFS_BOOTSTRAP_INSTALL}"
+PACKAGE_INSTALL = "initramfs-cgl-boot busybox base-passwd udev"
# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = ""
diff --git a/meta-cgl-common/images/core-image-cgl.bb
b/meta-cgl-common/images/core-image-cgl.bb
index 7117493..86bf7d4 100644
--- a/meta-cgl-common/images/core-image-cgl.bb
+++ b/meta-cgl-common/images/core-image-cgl.bb
@@ -10,7 +10,6 @@ VALGRIND_armv7a ?= "valgrind"
# Include modules in rootfs
IMAGE_INSTALL += "\
-${ROOTFS_PKGMANAGE_BOOTSTRAP} \
packagegroup-core-buildessential \
packagegroup-core-selinux \
packagegroup-cgl \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to include libraries?
I have an image which needs to include the libcups2 package from the cups recipe. If I try adding this to my image recipe CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" I get this error: ERROR: Required build target 'my-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-demo-image', 'libcups2'] However, I can get it to build with this MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" What's the difference between these two approaches and why doesn't the first one work at all? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
