[yocto] [meta-selinux][PATCH] e2fsprogs: Update patch for current master

[Jeremy Puhlman]

Signed-off-by: Jeremy Puhlman 
---
 .../files/misc_create_inode.c-label_rootfs.patch | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git 
a/recipes-devtools/e2fsprogs/files/misc_create_inode.c-label_rootfs.patch 
b/recipes-devtools/e2fsprogs/files/misc_create_inode.c-label_rootfs.patch
index 1de0dde..046e521 100644
--- a/recipes-devtools/e2fsprogs/files/misc_create_inode.c-label_rootfs.patch
+++ b/recipes-devtools/e2fsprogs/files/misc_create_inode.c-label_rootfs.patch
@@ -8,15 +8,17 @@ When copying a file system using the -d option the xattrs 
from the root
 directory need to be copied before the populate_fs recusion starts.
 
 Signed-off-by: Philip Tricca 
+Signed-off-by: Jeremy Puhlman 
+
 ---
- misc/create_inode.c | 7 +++
- 1 file changed, 7 insertions(+)
+ misc/create_inode.c | 8 
+ 1 file changed, 8 insertions(+)
 
 diff --git a/misc/create_inode.c b/misc/create_inode.c
-index 0de5719..ee21186 100644
+index a7b6d348..cfd15922 100644
 --- a/misc/create_inode.c
 +++ b/misc/create_inode.c
-@@ -890,8 +890,15 @@ errcode_t populate_fs(ext2_filsys fs, ext2_ino_t 
parent_ino,
+@@ -979,6 +979,13 @@ errcode_t populate_fs2(ext2_filsys fs, ext2_ino_t 
parent_ino,
return retval;
}
  
@@ -26,12 +28,18 @@ index 0de5719..ee21186 100644
 +  _("while setting xattrs for \"%s\""), source_dir);
 +  goto out;
 +  }
-   retval = __populate_fs(fs, parent_ino, source_dir, root, );
++
+   file_info.path_len = 0;
+   file_info.path_max_len = 255;
+   file_info.path = calloc(file_info.path_max_len, 1);
+@@ -987,6 +994,7 @@ errcode_t populate_fs2(ext2_filsys fs, ext2_ino_t 
parent_ino,
+  _info, fs_callbacks);
  
+   free(file_info.path);
 +out:
free(hdlinks.hdl);
return retval;
  }
 -- 
-2.1.4
+2.11.1
 
-- 
2.14.1.459.g238e487

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

Re: [yocto] Hook for layer-only actions?

[Jeremy Puhlman]

On 7/10/2018 1:04 PM, Michael Habibi wrote:
Well I should have just used what I want to actually do as the 
example, and not a QA action.


I want to create a new type of manifest that is only my layer, that 
will include line items that basically has like: package name, 
version, download URL, checksum, license.


I have no idea yet how to implement it, but wanted to make sure it was 
feasible.


It is.

You more or less just need to figure out which layer the recipe comes 
from. Then you can build functions on top of that.


https://github.com/MontaVista-OpenSourceTechnology/meta-montavista-cgx/blob/master/conf/layerinfo.inc

We modify the mirror we point to based on what layer the recipe resides 
in...The specific function that would interest you is

get_layername

Which we set LAYER_NAME to, then we use functions to do things with 
LAYER_NAME.




On Tue, Jul 10, 2018 at 2:27 PM Burton, Ross > wrote:


Hypothetically a new QA action should be added at the distro level, by
writing a class and adding it to INHERIT.

(I've several new QA tests added in this way)

Ross

On 10 July 2018 at 19:53, Alexander Kanavin
mailto:alex.kana...@gmail.com>> wrote:
> Yes. Implement a class and inherit it from the recipes.
>
> Alex
>
> 2018-07-10 20:50 GMT+02:00 Michael Habibi mailto:mikehab...@gmail.com>>:
>> I was wondering if there is a way I can apply a global
modification to all
>> recipes in a layer? For instance, we have our own layer for our
changes that
>> sit on top of the base Yocto/OE layers.
>>
>> What if, hypothetically, I wanted to insert a do_package_qa
action globally,
>> for everything in our layer. Is there a way to codify that,
beyond actually
>> adding this to every recipe in our layer?
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org 
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto





--
Jeremy A. Puhlman
jpuhl...@mvista.com

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

[yocto] [meta-cgl][PATCH] Add LAYERSERIES_COMPAT

[Jeremy Puhlman]

From: "Jeremy A. Puhlman" 

---
 meta-cgl-common/conf/layer.conf  | 2 +-
 meta-cgl-fsl-ppc/conf/layer.conf | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-common/conf/layer.conf
index bdf5f3f..9384ec7 100644
--- a/meta-cgl-common/conf/layer.conf
+++ b/meta-cgl-common/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "cgl-common"
 BBFILE_PATTERN_cgl-common = "^${LAYERDIR}/"
 BBFILE_PRIORITY_cgl-common = "7"
-
+LAYERSERIES_COMPAT_cgl-common = "sumo"
 LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer perl-layer 
filesystems-layer security selinux"
 
 require conf/distro/include/cgl_common_security_flags.inc
diff --git a/meta-cgl-fsl-ppc/conf/layer.conf b/meta-cgl-fsl-ppc/conf/layer.conf
index 353824d..525080c 100644
--- a/meta-cgl-fsl-ppc/conf/layer.conf
+++ b/meta-cgl-fsl-ppc/conf/layer.conf
@@ -10,3 +10,4 @@ BBFILE_PATTERN_cgl-fsl-ppc = "^${LAYERDIR}/"
 BBFILE_PRIORITY_cgl-fsl-ppc = "7"
 
 LAYERDEPENDS_cgl-fsl-ppc = "cgl-common"
+LAYERSERIES_COMPAT_cgl-fsl-ppc = "sumo"
-- 
2.6.2

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

Re: [yocto] initramfs support in Yocto

[Jeremy Puhlman]

 Can you be more specific about what you are looking for? When you build
 an image with the cpio.gz image type, you can boot that as an initramfs
 with the following kernel command line:

 initrd=core-image-minimal-fri2.cpio.gz root=/dev/ram0

 If you are looking for something beyond that, please elaborate.


When most people refer to initramfs support it is compiling a built
image in to the kernel binary(e.g.  CONFIG_INITRAMFS_SOURCE).
INITRAMFS_IMAGE
is part of the kernel class that should enable that in the build.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] recipe priority in multiple metas

[Jeremy Puhlman]

On 6/8/2011 4:17 PM, sushisan wrote:
 Hi:

 I have a project that use openssl.

 I practically all recipes used are in yocto project
 but I need someones that are in meta-oe (ie: fuse)

 openssl is in  meta/recipes-connectivity AND in meta-oe/recipes
 connectivity

 I've putted meta first than meta-oe in my bblayers.conf, but when I
 try to do a bitbake openssl
 bitbake try to compile ever the meta-oe recipe

 How I set priority in search recipes?

Search priority is set via BBFILE_PRIORITY_layer name that is set in
the layer.conf files.

-- 
Jeremy Puhlman
Montavista Sofware, LLC.

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

Re: [yocto] [PATCH 1/1] meta-intel: fix BBFILE_COLLECTIONS overrides

[Jeremy Puhlman]

 The crownbay has two BBFILE_COLLECTIONS in the same file, one for
 crownbay and one for crownbay-noemgd.  The conditional append allows
 them to be selected based on the machine selected.

The BBFILE_COLLECTIONS var basically give you a hook so you can find:

BBFILE_PATTERN_value set in BBFILE_COLLECTIONS
BBFILE_PRIORITY_value set in BBFILE_COLLECTIONS


While it certainly is true you could have different sets, for different
machines, you set those subsequent values identically. At the moment
there appears to be no need unless your using the value in some other
manner else where. FWIW it probably doesn't matter either way, but it
doesn't appear to be needed by the way you are configuring it.

Jeremy Puhlman
Montavista Sofware, LLC.

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

[yocto] In consistancy in the defition of BBFILE_COLLECTIONS in layer.conf

[Jeremy Puhlman]

Opps sent from wrong account.

I was working with some layerinfo code, and I noticed that the values of
BBFILE_COLLECTIONS in layer.conf in the meta-intel repo are kind of all over 
the map:

 for each in */conf/layer.conf; do cat $each; done | grep BBFILE_COLLECTIONS
BBFILE_COLLECTIONS_crownbay += crownbay
BBFILE_COLLECTIONS_crownbay-noemgd += crownbay-noemgd
BBFILE_COLLECTIONS_fishriver += fishriver
BBFILE_COLLECTIONS_jasperforest += jasperforest
BBFILE_COLLECTIONS_sugarbay += sugarbay

For the above layers when I just list out oe-core and one of the above,
the results from BBFILE_COLLECTIONS ends up
just being what ever was set above.

BBFILE_COLLECTIONS += n450
BBFILE_COLLECTIONS += emenlow

When using these layers, the final BBFILE_COLLECTIONS is the list of all
the layers as expected.

Was just curious if there was a intentional reason why the
difference(i.e. is there some code that I am missing that fixes this up)?
-- Jeremy Puhlman Montavista Sofware, LLC.

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

Re: [yocto] In consistancy in the defition of BBFILE_COLLECTIONS in layer.conf

[Jeremy Puhlman]

 No, not intentional - looks like a case of an overzealous overriding
 typo that propagated.  I'll cook up a patch to make them all just
 'BBFILE_COLLECTIONS += '

 Tom

Good  deal.  Just wanted to double check. Thanks for the quick response.

-- 
Jeremy Puhlman
Montavista Sofware, LLC.

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