Date   

Re: Alternative to _git.bb convention for unstable versions?

Keith Derrick
 

Thanks Martin.

 

I was trying to avoid everyone in my org having to add anything manually to their local.conf (we will be using the _git version) – and dealing with the “help me” emails whenever they forgot.

 

I was thinking that you would want one or the other, but I suppose if there’s a way to screw up, users will find it

 

Eventually, we’ll switch our build to a custom DISTRO and the problem will go away. Just wish there was somewhere else the PREFERRED_VERSION statements could go.

 

 

 

From: Martin Jansa <martin.jansa@...>
Date: Friday, September 13, 2019 at 8:35 AM
To: "Keith Derrick/LGEUS Advanced Platform(keith.derrick@...)" <keith.derrick@...>
Cc: "yocto@..." <yocto@...>
Subject: Re: [yocto] Alternative to _git.bb convention for unstable versions?

 

You can easily add .inc file which will set all the PREFERRED_VERSIONs for all components you need and then the users will just add an "require" of this .inc files to their local.conf.

 

"somepackage-unstable.bb" or "somepackage-devel.bb" this will make it 2 different components - not 2 different versions of the same component - which makes this much more complicated, you'll need PREFERRED_PROVIDERs for every dependency and in the end you will need to make sure that whole build is using the same set of providers, because if

 

A depends on somepackage-unstable

B depends on A and somepackage-devel

 

then building B will fail in prepare-recipe-sysrooot, because A will pull somepackage-unstable which will probably conflict with somepackage-devel by providing the same files (in just different version). You can see how openssl10 and openssl "worked" if you build didn't use the same one for all the recipes.

 

Cheers,

 

On Fri, Sep 13, 2019 at 5:27 PM keith.derrick <keith.derrick@...> wrote:

I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable"  one.

 

Currently I have somepackage_1.0.bb and somepackage_git.bb which are working fine.

 

However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work.

 

If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer.

 

I'm considering instead using either "somepackage-unstable.bb" or "somepackage-devel.bb" instead of "sompackage_git.bb". This allows a simple selection of either  RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image.

 

However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions  say) it might well be completely stable.

 

Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file?

 

Thanks

Keith Derrick

 

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


Re: Patch a package with condition

Ross Burton
 

On 13/09/2019 06:55, PRASANTH R wrote:
I need to patch my custom recipe, let say "Package-A.bb" in which I need to add a patch to the test recipe if the yocto build has a specific package like let's say if "Package-B" is available patch should be applied for Package-A.bb
I am trying with below step in Package-A.bb
SRC_URI_append_Package-B = " file://0001-add-new-line.patch"
But it doesn't work, I could see this SRC_URI_append_* works only for some specific tokens like board name, Architecture, library or native-class as such
Have u come across the scenario to make a dependency in patching with reference to another package? which way I can use this?
You can't patch a recipe depending on whether another recipe is going to be built, because the process is that recipes produce packages, and packages built images.

So you're building two images, one of which contains Package-A and the other contains Package-A and Package-B. Bitbake will only build those recipes once.

Ross


Re: Alternative to _git.bb convention for unstable versions?

Martin Jansa
 

You can easily add .inc file which will set all the PREFERRED_VERSIONs for all components you need and then the users will just add an "require" of this .inc files to their local.conf.

"somepackage-unstable.bb" or "somepackage-devel.bb" this will make it 2 different components - not 2 different versions of the same component - which makes this much more complicated, you'll need PREFERRED_PROVIDERs for every dependency and in the end you will need to make sure that whole build is using the same set of providers, because if

A depends on somepackage-unstable
B depends on A and somepackage-devel

then building B will fail in prepare-recipe-sysrooot, because A will pull somepackage-unstable which will probably conflict with somepackage-devel by providing the same files (in just different version). You can see how openssl10 and openssl "worked" if you build didn't use the same one for all the recipes.

Cheers,

On Fri, Sep 13, 2019 at 5:27 PM keith.derrick <keith.derrick@...> wrote:

I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable"  one.


Currently I have somepackage_1.0.bb and somepackage_git.bb which are working fine.


However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work.


If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer.


I'm considering instead using either "somepackage-unstable.bb" or "somepackage-devel.bb" instead of "sompackage_git.bb". This allows a simple selection of either  RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image.


However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions  say) it might well be completely stable.


Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file?


Thanks

Keith Derrick


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


Alternative to _git.bb convention for unstable versions?

Keith Derrick
 

I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable"  one.


Currently I have somepackage_1.0.bb and somepackage_git.bb which are working fine.


However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work.


If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer.


I'm considering instead using either "somepackage-unstable.bb" or "somepackage-devel.bb" instead of "sompackage_git.bb". This allows a simple selection of either  RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image.


However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions  say) it might well be completely stable.


Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file?


Thanks

Keith Derrick



Image for sassive test for Qt QML

Mauro Ziliani
 

Hi all.

I need to check a small diversion on qt5-qtdeclarative package.

I disable SSE2 check feature for qv8engine.


There  is a way to execute a massive test of all QtQuick QML features over final platform?


MZ


Patch a package with condition

prasanth
 

Hi,

I need to patch my custom recipe, let say "Package-A.bb" in which I need to add a patch to the test recipe if the yocto build has a specific package like let's say if "Package-B" is available patch should be applied for Package-A.bb
I am trying with below step in Package-A.bb
SRC_URI_append_Package-B = " file://0001-add-new-line.patch"

But it doesn't work, I could see this SRC_URI_append_* works only for some specific tokens like board name, Architecture, library or native-class as such

Have u come across the scenario to make a dependency in patching with reference to another package? which way I can use this?

Thanks,



Yocto Project Summit 2019 - CFP Reminder

Volosincu, Andreea S
 

The Yocto Project Summit 2019 is quickly approaching and, with that, the CFP closing date.

 

Quick reminder for everyone that plans to submit an abstract:  

CFP Closes: 11:59 PM PST on Monday, September 16

CFP Notifications: Monday, September 23

Schedule Announcement: Thursday, September 30

Slide Due Date: Monday, October 21

 

CFP list of topics:

ü  DevTool

ü  Layer quality: e.g. creating robust layers, safely using existing layers

ü  Future languages (e.g. Rust)

ü  Productivity tricks and tools

ü  Security

ü  Reproducibility

ü  Init systems: pros and cons, selection, configuration

ü  Leveraging the new runqueue optimizations for mirrors, reproducible builds

ü  Supporting the Application Developer

ü  DevOps

ü  Working with/creating BSPs

ü  Practical use of the Yocto Project

 

Submit your proposals at conferences@...

 

Best regards,

Yocto Project Advocacy Team

 

 

 


how to generate an SPDX "notice file" from a build?

Robert P. J. Day
 

colleague just asked how to generate an SPDX license "notice file"
(whatever that is) from a build for a zynq ultrascale+ board, which
shouldn't be hard other than that:

1) it's not pure YP, it's petalinux
2) petalinux is being driven by a docker build container

so it may be that one or the other of the above is causing side
effects.

in any event, i already pointed out how YP automatically generates
all the license info on a per-recipe basis, but there is apparently
some fancier format of SPDX output, so after a few seconds inspection,
i stumbled over the spdx.bbclass file. i added the line:

INHERIT += "spdx"

to the petalinux version of local.conf, started the build, and noticed
numerous error messages of the form:

SPDX: Could not set up required directories ... /home/yocto

which i'm *guessing* is due to the docker container having some
default idea of where output files are supposed to go.

in any event, if the above had worked, what would i have seen and
where would i have seen it?

more to the point, as i did more research, i noticed a number of
things related to collecting licensing info, such as a
meta-spdxscanner layer, and something called DoSOCSv2, of which i know
nothing.

anyway, what is the simplest way to generate said "notice file", if
there is a formal definition of such a thing? i'll try that this
evening on a pure YP build just to verify proper operation before
trying to cram it into petalinux.

rday

--

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

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


Re: One second timestamp resolution?

Paul D. DeRocco
 

From: Jussi Kukkonen [mailto:jku@goto.fi]

I think file timestamp resolution on ext4 is one of the things that
depend on inode size (ext4 does not enforce reasonable values because
of compatibility with earlier versions I guess). So maybe check inode
size (should be 256 bytes I think?).
I don't have tune2fs on my embedded system, so I can't check, but that sounds like the probable reason. The nanoseconds that ext4 added are in the upper 128 bytes of a 256 byte inode, for compatibility reasons, so somehow I must have ext4 configured to use 128 byte inodes. Where would this be configured in a Yocto build? I'm still on Pyro.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Re: Debug-files in SDK

Ross Burton
 

On 12/09/2019 11:13, Teemu K wrote:
Hi,
I'm not entirely sure if this is bug or feature.
I've created sdk to my image with populate_sdk - command. I noticed
that in the SDK the x86_64 - directory is 384MB and that contains all
the toolchains etc., but the target side
(cortexa9hf-neon-poky-linux-gnueabi) is 5.7GB. Majority of it is in
.debug - directories.
What causes the confusion here is that I haven't enabled debug-symbols
in my local.conf and I don't have any other debug stuff enabled there
either. Are those the debug-symbols that can be used to debug software
on target with GDB for example? I thought that debug symbol
information needs to be separately enabled.
If they are not, then can I get rid of them somehow?
SDKIMAGE_FEATURES ??= "dev-pkgs dbg-pkgs src-pkgs ${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', 'doc-pkgs', '', d)}"

SDKs by default contain debug symbols, and yes they can be used with gdb to debug on target.

If you don't want them in the SDK, remove dbg-pkgs (and src-pkgs whilst you're there) from SDKIMAGE_FEATURES.

Ross


Debug-files in SDK

Teemu K.
 

Hi,

I'm not entirely sure if this is bug or feature.

I've created sdk to my image with populate_sdk - command. I noticed
that in the SDK the x86_64 - directory is 384MB and that contains all
the toolchains etc., but the target side
(cortexa9hf-neon-poky-linux-gnueabi) is 5.7GB. Majority of it is in
.debug - directories.

What causes the confusion here is that I haven't enabled debug-symbols
in my local.conf and I don't have any other debug stuff enabled there
either. Are those the debug-symbols that can be used to debug software
on target with GDB for example? I thought that debug symbol
information needs to be separately enabled.

If they are not, then can I get rid of them somehow?

-Teemu Keskinarkaus


Re: source an environment file in bitbake recipe.

Bas Mevissen
 

On 9/11/19 5:09 PM, Pandey, Kamal wrote:
Hi,
Is there any way by which I can use the source command inside a bitbake recipe for example if I need to source some environment file before compiling.
source <filename> doesn't seem to work
Will the command . <filename> work
What exactly I need to inherit for source command to work
I ran into something similar in a Makefile. There the problem was that the default sub shell used is /bin/sh and does not support the "source" command. Solution for the Makefile I used is like:

SHELL=/bin/bash

MY_VAR = $(shell source func_defs.sh && call_func 1 2)

So maybe do something like (untested):

bash -c 'source source func_defs.sh && call_func 1 2'

in the bitbake recipe. You obviously depend on bash-native for that recipe.

Hope this helps,

-- Bas.


[meta-selinux][PATCH] audit: explicitly disable golang bindings

Yi Zhao
 

Disable golang bindings to avoid potential host contamination issue.
Fixes: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13166

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-security/audit/audit_2.8.5.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-security/audit/audit_2.8.5.bb b/recipes-security/audit/audit_2.8.5.bb
index d3b9b51..2b47812 100644
--- a/recipes-security/audit/audit_2.8.5.bb
+++ b/recipes-security/audit/audit_2.8.5.bb
@@ -39,6 +39,7 @@ EXTRA_OECONF += "--without-prelude \
--libdir=${base_libdir} \
--sbindir=${base_sbindir} \
--without-python3 \
+ --without-golang \
--disable-zos-remote \
"
EXTRA_OECONF_append_arm = " --with-arm=yes"
--
2.7.4


Re: One second timestamp resolution?

Jussi Kukkonen
 

On Wed, 11 Sep 2019 at 08:53, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:

I just noticed that I'm getting one-second resolution on all my
timestamps. This is for both ext4 and vfat partitions, and shows up in ls
--full-time and the stat command. What could account for this? My uname -a
output is "Linux CHROMA1 4.10.17-yocto-preempt-rt #1 SMP PREEMPT Wed Oct
11 12:33:54 PDT 2017 i686 i686 i386 GNU/Linux" if that's any help. Also,
my ext4 mount options are "rw,noatime,nodiratime,data=ordered".
I think file timestamp resolution on ext4 is one of the things that
depend on inode size (ext4 does not enforce reasonable values because
of compatibility with earlier versions I guess). So maybe check inode
size (should be 256 bytes I think?).

Jussi


Re: [meta-raspberrypi][ostree] build errors

Alex Kiernan
 

On Thu, Sep 12, 2019 at 12:17 AM Greg Wilson-Lindberg
<GWilson@sakuraus.com> wrote:

I'm trying to include ostree into a raspberry pi boot2qt build based on thud.

I'm getting a warning:
WARNING: linux-raspberrypi-1_4.14.112+gitAUTOINC+6b5c4a2508-r0 do_kernel_metadata: defconfig detected in WORKDIR. bcm2709_defconfig skipped

Which I figure that I can probably ignore, but may find I have a problem with it if it is missing out on my config changes.

More concerning is the following error:

ERROR: ostree-v2018.9-r0 do_unpack: gitsm: submodule unpack failed: UnpackError Unpack failure for URL: 'gitsm://gitlab.gnome.org/GNOME/libglnx.git;protocol=https;name=libglnx;subpath=libglnx;bareclone=1;nobranch=1'. No up to date source found: clone directory not available or not up to date: /home/gwilson/Qt/Qt-5.13.1/Yocto-build-RPi3/build-raspberrypi3/../downloads/git2/gitlab.gnome.org.GNOME.libglnx.git; shallow clone not enabled

The 'gitlab.gnome.org/GNOME/libglnx' subdirectory is there, so that would imply that something is wrong with the initial protocol or other decorators. I also did a clean on ostree just to make sure there wasn't any problem with git -> gitsm changes.

Is there anyone with familiarity with the ostree system that could give me a hand on this? It is possible that I'm missing some configuration, the docs are not the clearest.
My immediate thought was add:

PREMIRRORS = ""

to your ostree recipe - there's an old copy of the source sitting in
the yocto mirrors and the gitsm fetcher doesn't update the submodules
correctly, but looking at the error, I'm not sure if that's actually
your problem.

I'm a couple of upstream patches away from an ostree recipe that's I
think should be in a fit state to go into meta-oe:

https://github.com/akiernan/meta-ostree-core/blob/master/recipes-ostree/ostree/ostree.inc

--
Alex Kiernan


[meta-raspberrypi][ostree] build errors

Greg Wilson-Lindberg
 

I'm trying to include ostree into a raspberry pi boot2qt build based on thud.

I'm getting a warning:
WARNING: linux-raspberrypi-1_4.14.112+gitAUTOINC+6b5c4a2508-r0 do_kernel_metadata: defconfig detected in WORKDIR. bcm2709_defconfig skipped

Which I figure that I can probably ignore, but may find I have a problem with it if it is missing out on my config changes.

More concerning is the following error:

ERROR: ostree-v2018.9-r0 do_unpack: gitsm: submodule unpack failed: UnpackError Unpack failure for URL: 'gitsm://gitlab.gnome.org/GNOME/libglnx.git;protocol=https;name=libglnx;subpath=libglnx;bareclone=1;nobranch=1'. No up to date source found: clone directory not available or not up to date: /home/gwilson/Qt/Qt-5.13.1/Yocto-build-RPi3/build-raspberrypi3/../downloads/git2/gitlab.gnome.org.GNOME.libglnx.git; shallow clone not enabled

The 'gitlab.gnome.org/GNOME/libglnx' subdirectory is there, so that would imply that something is wrong with the initial protocol or other decorators. I also did a clean on ostree just to make sure there wasn't any problem with git -> gitsm changes.

Is there anyone with familiarity with the ostree system that could give me a hand on this? It is possible that I'm missing some configuration, the docs are not the clearest.

Thanks in advance,
Greg Wilson-Lindberg


Re: assembler error: missing immediate expression at operand 1 -- `dsb`

Ross Burton
 

On 11/09/2019 15:51, Pandey, Kamal wrote:
I was trying to compile the rpmsg-lite library provided by NXP for my ZC102 board. While compiling I was getting the error as follows:
Try asking NXP directly.

Ross


source an environment file in bitbake recipe.

kamal pandey
 

Hi,
Is there any way by which I can use the source command inside a bitbake recipe for example if I need to source some environment file before compiling.
source <filename> doesn't seem to work
Will the command . <filename> work

What exactly I need to inherit for source command to work
Thanks
Kamal Pandey


assembler error: missing immediate expression at operand 1 -- `dsb`

kamal pandey
 

Hi
I was trying to compile the rpmsg-lite library provided by NXP for my ZC102 board. While compiling I was getting the error as follows:

| Scanning dependencies of target rpmsg-lite
| [ 10%] Building C object rpmsg-lite/CMakeFiles/rpmsg-lite.dir/lib/rpmsg_lite/rpmsg_lite.c.o
| [ 20%] Building C object rpmsg-lite/CMakeFiles/rpmsg-lite.dir/lib/rpmsg_lite/rpmsg_ns.c.o
| [ 30%] Building C object rpmsg-lite/CMakeFiles/rpmsg-lite.dir/lib/virtio/virtqueue.c.o
| [ 40%] Building C object rpmsg-lite/CMakeFiles/rpmsg-lite.dir/lib/rpmsg_lite/porting/environment/rpmsg_env_bm.c.o
| {standard input}: Assembler messages:
| {standard input}:199: Error: missing immediate expression at operand 1 -- `dsb'
| {standard input}:216: Error: missing immediate expression at operand 1 -- `dsb'
| {standard input}:232: Error: missing immediate expression at operand 1 -- `dsb'
| rpmsg-lite/CMakeFiles/rpmsg-lite.dir/build.make:158: recipe for target 'rpmsg-lite/CMakeFiles/rpmsg-lite.dir/lib/rpmsg_lite/porting/environment/rpmsg_env_bm.c.o' failed
| make[2]: *** [rpmsg-lite/CMakeFiles/rpmsg-lite.dir/lib/rpmsg_lite/porting/environment/rpmsg_env_bm.c.o] Error 1
| CMakeFiles/Makefile2:122: recipe for target 'rpmsg-lite/CMakeFiles/rpmsg-lite.dir/all' failed
| make[1]: *** [rpmsg-lite/CMakeFiles/rpmsg-lite.dir/all] Error 2
| Makefile:83: recipe for target 'all' failed
| make: *** [all] Error 2
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/iepl007/yocto_build/build_openamp/tmp/work/pdm3_zynqmp-pdm3-linux/vhip-bsp-r5-0/2018.3+gitAUTOINC+fb88b32f6e-r0/temp/log.do_compile.32551)
ERROR: Task (/home/iepl007/yocto_build/poky/../meta-ifm-vhip-openamp-dev/recipes-rpmsg-lite/vhip_bsp_r5_0/vhip-bsp-r5-0.bb:do_compile) failed with exit code '1'

While compiling mannualy without using bitbake recipe I am able to compile successfully.
Can someone help me resolve the issue, any pointers will be appreciated.
I am using Xilinx sdk 2018.3
Thanks & Regards
Kamal Pandey


Re: [meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers

Joe MacDonald
 

[Re: [meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers] On 19.09.11 (Wed 09:22) Yi Zhao wrote:


On 9/10/19 1:11 AM, Joe MacDonald wrote:
Hi Yi,

[[meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers] On 19.09.09 (Mon 14:01) Yi Zhao wrote:

From: Robert Yang <liezhi.yang@windriver.com>

The previous code add all BBFILE_COLLECTIONS/recipes*/*/*.bbappend to BBFILES,
which causes the parsing very slow when there are many layers, e.g., I have 87
layers:

* Before:
$ rm -fr tmp-glibc/ cache; time bitbake -p
real 0m45.173s
user 0m0.560s
sys 0m0.060s

* After:
$ rm -fr tmp-glibc/ cache; time bitbake -p
real 0m25.542s
user 0m0.572s
sys 0m0.040s

It wasted 20s which wasn't worth (The host has 128 threads, it should cost more
time on less power host), use BBFILES_DYNAMIC can fix the problem.
This seems like a big claim, I certainly haven't seen that on my setup:

* Before:
$ rm -fr tmp cache
real 0m14.751s
user 0m0.323s
sys 0m0.048s

* After:
$ rm -fr tmp cache ; time bitbake -p
real 0m14.725s
user 0m0.326s
sys 0m0.046s

but it's still a sensible change. When I ran a test before/after
configuration for augeas the configuration seemed off, though. Can you
confirm that with this change as is you're getting the correct
--with/--without and --enable/--disable and patches applied for your
layers? I just want to confirm since the ~20s difference in parsing
seems kind of out of scale for moving essentially three bbappends around
and I'm wondering if there's something else siginficant in your tree we
want to consider.

This patch is from Robert Yang. CC to him. Maybe he can give us more
explanation.

For the augeas, the current augeas_%.bbapend doesn't work because the augeas
recipe is in meta-oe layer but not meta-python layer. This patch moves the
bbappend to the correct layer to fix this issue.

It works on my local:

$ cat log.do_configure

[snip]
checking for library containing setfilecon... -lselinux
[snip]
checking for selinux/selinux.h... (cached) yes
checking selinux/context.h usability... yes
checking selinux/context.h presence... yes
checking for selinux/context.h... yes
[snip]
Okay, thanks. Funny that I randomly picked the package that was broken
in multiple ways, but this looks like an improvement overall.

-J.



//Yi



-J.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
conf/layer.conf | 11 +++++++----
.../recipes-daemons/iscsi-initiator-utils/files/initd.debian | 0
.../iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend | 0
.../iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc | 0
.../recipes-support}/augeas/augeas_%.bbappend | 0
.../recipes-containers/lxc/lxc_%.bbappend | 0
6 files changed, 7 insertions(+), 4 deletions(-)
rename {networking-layer => dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/files/initd.debian (100%)
rename {networking-layer => dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend (100%)
rename {networking-layer => dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc (100%)
rename {meta-python/recipes-extended/augeas => dynamic-layers/openembedded-layer/recipes-support}/augeas/augeas_%.bbappend (100%)
rename {virtualization-layer => dynamic-layers/virtualization-layer}/recipes-containers/lxc/lxc_%.bbappend (100%)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9dd34b1..89b9468 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -5,10 +5,13 @@ BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
-# Let us add layer-specific bbappends which are only applied when that
-# layer is included in our configuration
-BBFILES += "${@' '.join('${LAYERDIR}/%s/recipes*/*/*.bbappend' % layer \
- for layer in BBFILE_COLLECTIONS.split())}"
+BBFILES_DYNAMIC += "openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/*/*/*.bb \
+ openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/*/*/*.bbappend \
+ networking-layer:${LAYERDIR}/dynamic-layers/networking-layer/*/*/*.bb \
+ networking-layer:${LAYERDIR}/dynamic-layers/networking-layer/*/*/*.bbappend \
+ virtualization-layer:${LAYERDIR}/dynamic-layers/virtualization-layer/recipes*/*/*.bb \
+ virtualization-layer:${LAYERDIR}/dynamic-layers/virtualization-layer/recipes*/*/*.bbappend \
+ "
BBFILE_COLLECTIONS += "selinux"
BBFILE_PATTERN_selinux = "^${LAYERDIR}/"
diff --git a/networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian b/dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian
similarity index 100%
rename from networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian
rename to dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian
diff --git a/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend b/dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
similarity index 100%
rename from networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
rename to dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
diff --git a/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc b/dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
similarity index 100%
rename from networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
rename to dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
diff --git a/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend b/dynamic-layers/openembedded-layer/recipes-support/augeas/augeas_%.bbappend
similarity index 100%
rename from meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
rename to dynamic-layers/openembedded-layer/recipes-support/augeas/augeas_%.bbappend
diff --git a/virtualization-layer/recipes-containers/lxc/lxc_%.bbappend b/dynamic-layers/virtualization-layer/recipes-containers/lxc/lxc_%.bbappend
similarity index 100%
rename from virtualization-layer/recipes-containers/lxc/lxc_%.bbappend
rename to dynamic-layers/virtualization-layer/recipes-containers/lxc/lxc_%.bbappend
--
2.7.4
--
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq

8481 - 8500 of 55069