From: Wenzong Fan <wenzong.fan@...>

* Allow kernel_t to lower file level
* Allow kernel_t to set process level

Signed-off-by: Wenzong Fan <wenzong.fan@...>
---
...-kernel_t-mls-trusted-for-lowering-file-l.patch | 74 ++++++++++++++++++++++
...-kernel_t-mls-trusted-for-setting-process.patch | 43 +++++++++++++
.../refpolicy/refpolicy_2.20170204.inc | 2 +
3 files changed, 119 insertions(+)
create mode 100644 recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-lowering-file-l.patch
create mode 100644 recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-setting-process.patch

diff --git a/recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-lowering-file-l.patch b/recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-lowering-file-l.patch
new file mode 100644
index 0000000..a3b4803
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-lowering-file-l.patch
@@ -0,0 +1,74 @@
+From 04643644acfa30eaa0a2f7902ea48cf79f571f6d Mon Sep 17 00:00:00 2001
+From: Wenzong Fan <wenzong.fan@...>
+Date: Fri, 13 Oct 2017 07:20:40 +0000
+Subject: [PATCH] poky-policy: kernel_t mls trusted for lowering file level
+
+The boot process hangs with the error while using MLS policy:
+
+ [!!!!!!] Failed to mount API filesystems, freezing.
+ [ 4.085349] systemd[1]: Freezing execution.
+
+Make kernel_t mls trusted for lowering the level of files to fix below
+avc denials and remove the hang issue.
+
+ op=security_validate_transition seresult=denied \
+ oldcontext=system_u:object_r:device_t:s15:c0.c1023 \
+ newcontext=system_u:object_r:device_t:s0 \
+ taskcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=dir
+ systemd[1]: Unable to fix SELinux security context of /dev: Operation not permitted
+
+ avc: denied { create } for pid=1 comm="systemd" name="shm" \
+ scontext=system_u:system_r:kernel_t:s15:c0.c1023 \
+ tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
+ systemd[1]: Failed to mount tmpfs at /dev/shm: No such file or directory
+
+ avc: denied { create } for pid=1 comm="systemd" name="pts" \
+ scontext=system_u:system_r:kernel_t:s15:c0.c1023 \
+ tcontext=system_u:object_r:devpts_t:s0-s15:c0.c1023 tclass=dir permissive=0
+
+ op=security_validate_transition seresult=denied \
+ oldcontext=system_u:object_r:unlabeled_t:s0 \
+ newcontext=system_u:object_r:var_run_t:s0-s15:c0.c1023 \
+ taskcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=dir
+
+ op=security_validate_transition seresult=denied \
+ oldcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 \
+ newcontext=system_u:object_r:var_run_t:s0-s15:c0.c1023 \
+ taskcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=dir
+ systemd[1]: Unable to fix SELinux security context of /run: Operation not permitted
+
+ op=security_validate_transition seresult=denied \
+ oldcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 \
+ newcontext=system_u:object_r:cgroup_t:s0 \
+ taskcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=dir
+ systemd[1]: Unable to fix SELinux security context of /sys/fs/cgroup: Operation not permitted
+
+ avc: denied { create } for pid=1 comm="systemd" name="pstore" \
+ scontext=system_u:system_r:kernel_t:s15:c0.c1023 \
+ tcontext=system_u:object_r:pstore_t:s0 tclass=dir permissive=0
+
+Reference: https://bugzilla.redhat.com/show_bug.cgi?id=667370
+
+Upstream-Status: Pending
+
+Signed-off-by: Wenzong Fan <wenzong.fan@...>
+---
+ policy/modules/kernel/kernel.te | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
+index 4794f29..363381c 100644
+--- a/policy/modules/kernel/kernel.te
++++ b/policy/modules/kernel/kernel.te
+@@ -328,6 +328,8 @@ mls_file_write_all_levels(kernel_t)
+ mls_file_read_all_levels(kernel_t)
+ mls_socket_write_all_levels(kernel_t)
+ mls_fd_use_all_levels(kernel_t)
++# https://bugzilla.redhat.com/show_bug.cgi?id=667370
++mls_file_downgrade(kernel_t)
+
+ ifdef(`distro_redhat',`
+ # Bugzilla 222337
+--
+2.13.3
+
diff --git a/recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-setting-process.patch b/recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-setting-process.patch
new file mode 100644
index 0000000..530b30d
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20170204/poky-policy-kernel_t-mls-trusted-for-setting-process.patch
@@ -0,0 +1,43 @@
+From 5a47be14ff03ae0d959908ad39b429787670d40e Mon Sep 17 00:00:00 2001
+From: Wenzong Fan <wenzong.fan@...>
+Date: Fri, 13 Oct 2017 08:16:18 +0000
+Subject: [PATCH] poky-policy: kernel_t mls trusted for setting process level
+
+Because of selinux-init.service always checks the label of init
+process to determine if the system needs to be re-labeled and re-
+booted, a failed transition will cause the target falls into loop
+of re-label & re-boot.
+
+Make kernel_t MLS trusted for setting the level of processes it
+executes to fix below avc denial and remove the error:
+
+ avc: denied { dyntransition } for pid=1 comm="systemd" \
+ scontext=system_u:system_r:kernel_t:s15:c0.c1023 \
+ tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 \
+ tclass=process permissive=0
+
+ systemd[1]: Failed to transition into init label \
+ 'system_u:system_r:init_t:s0-s15:c0.c1023', ignoring.
+
+Upstream-Status: Pending
+
+Signed-off-by: Wenzong Fan <wenzong.fan@...>
+---
+ policy/modules/kernel/kernel.te | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
+index 363381c..8105b91 100644
+--- a/policy/modules/kernel/kernel.te
++++ b/policy/modules/kernel/kernel.te
+@@ -328,6 +328,7 @@ mls_file_write_all_levels(kernel_t)
+ mls_file_read_all_levels(kernel_t)
+ mls_socket_write_all_levels(kernel_t)
+ mls_fd_use_all_levels(kernel_t)
++mls_process_set_level(kernel_t)
+ # https://bugzilla.redhat.com/show_bug.cgi?id=667370
+ mls_file_downgrade(kernel_t)
+
+--
+2.13.3
+
diff --git a/recipes-security/refpolicy/refpolicy_2.20170204.inc b/recipes-security/refpolicy/refpolicy_2.20170204.inc
index 51c5050..06e8c08 100644
--- a/recipes-security/refpolicy/refpolicy_2.20170204.inc
+++ b/recipes-security/refpolicy/refpolicy_2.20170204.inc
@@ -53,6 +53,8 @@ SRC_URI += " \
file://poky-policy-fix-setfiles-statvfs-get-file-count.patch \
file://poky-policy-fix-dmesg-to-use-dev-kmsg.patch \
file://ftp-add-ftpd_t-to-mlsfilewrite.patch \
+ file://poky-policy-kernel_t-mls-trusted-for-lowering-file-l.patch \
+ file://poky-policy-kernel_t-mls-trusted-for-setting-process.patch \
"

# Backport from upstream
--
2.13.0

I have now combined the last 2 answers:

I did not want to put more customization than machine and distro into
my local.conf and since I already have my own distro conf I have now
put the include conf/machine/${MACHINE}-extra.conf into my own distro
conf file and made colibri-vf-extra.conf, both files are now inside my
own layer folder and under my project's version control so it won't
get lost. This works. Thank you

2017-10-13 10:56 GMT+02:00 Bernd <prof7bit@...>:

On 12/10/2017 20:47, Ayoub Zaki wrote:

Hi,


On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories
layout for expl:


foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
     └── var
         └── lib
             ├── config
             └── data

It should contains only those directories an nothing else, is there
anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes
that populate those directories. Means: no packagegroup-core-boot, no
base-passwd, no.... -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:

IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"

It looks like you inherit "core-image" instead of just "image". I can
confirm that this work, I have this simple recipe:


# Copyright (C) 2017 Stefano Babic <sbabic@...>
# Released under the MIT license (see COPYING.MIT for the terms)

DESCRIPTION = "Image with user processes"
LICENSE = "CLOSED"
SECTION = "Application"

inherit image

IMAGE_INSTALL = " \
projects-firmware \
"

And project firmware has just the layout I want.

Regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@...
=====================================================================

From: John Ernberg

Looks like you're overriding SRC_URI instead of appending it.

I had a feeling I was doing something dumb. Thanks.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

On 10/13/2017 05:52 AM, Paul D. DeRocco wrote:

From: Khem Raj [mailto:raj.khem@...]

You can apply the patch to all binutils variants, its fine.
Send a patch or if you
want, file a ticket in bugzilla and we will take care.

Yocto's Bugzilla isn't recognizing my password, and when it says that it's
emailed me a password change message, it doesn't show up. However, the
four small patches are in the Sourceware binutils-gdb GIT repo, at the
link I mentioned:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366

Just to verify, my binutils-crosssdk_%.bbappend file contains:

FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"

SRC_URI = " \

Looks like you're overriding SRC_URI instead of appending it. Try with
'+=' instead of just '='.

file://gas_as.h.patch \
file://gas_ChangeLog.patch \
file://gas_input-scrub.c.patch \
file://gas_listing.c.patch \
"

and the patches from that Bugzilla page are in a binutils directory. The
errors I get indicate that the patches are being attempted, but aren't
matching up with any source files.

// John

From: Khem Raj [mailto:raj.khem@...]

you can just make 1 patch download

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=com

mitdiff_plain;h=> 39865a7f420ab4ca4dec6ed27339618a5d5dc366;hp=fe22022617a7122491aa83c893a10a8d861cde73

and delete the hunk which contains changeslog entry and rest
should apply
cleanly. And add it to SRC_URI in binutils-2.29.inc

That didn't change anything. (Pyro is using 2.28, BTW.)

The crosssdk recipe is built in x86_64-linux/binutils-crosssdk-x86_64-pokysdk-linux/2.28-r0/git. All I see in there are a couple of quilt directories containing my patch files, no source files. So I decided to run a devshell. Since that doesn't happen until after the patches are supplied, that failed, too. So I removed the .bbappend and ran the devshell. There they were, a half-bazillion nice source files, including the gas directory. So I put the .bbappend back and ran the devshell again, and the first thing it did was clean that directory, after which the patches failed again.

I have no clue how this build system works. Is the source directory supposed to be where the files are patched? What cleans the source directory? I notice that after any build, there never seem to be any source files hanging around.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

On Thu, Oct 12, 2017 at 8:52 PM, Paul D. DeRocco <pderocco@...> wrote:

From: Khem Raj [mailto:raj.khem@...]

You can apply the patch to all binutils variants, its fine.
Send a patch or if you
want, file a ticket in bugzilla and we will take care.

Yocto's Bugzilla isn't recognizing my password, and when it says that it's
emailed me a password change message, it doesn't show up. However, the
four small patches are in the Sourceware binutils-gdb GIT repo, at the
link I mentioned:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366

Just to verify, my binutils-crosssdk_%.bbappend file contains:

FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"

SRC_URI = " \
file://gas_as.h.patch \
file://gas_ChangeLog.patch \
file://gas_input-scrub.c.patch \
file://gas_listing.c.patch \
"

you can just make 1 patch download

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff_plain;h=39865a7f420ab4ca4dec6ed27339618a5d5dc366;hp=fe22022617a7122491aa83c893a10a8d861cde73

and delete the hunk which contains changeslog entry and rest should apply
cleanly. And add it to SRC_URI in binutils-2.29.inc

and the patches from that Bugzilla page are in a binutils directory. The
errors I get indicate that the patches are being attempted, but aren't
matching up with any source files.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

From: Khem Raj [mailto:raj.khem@...]

You can apply the patch to all binutils variants, its fine.
Send a patch or if you
want, file a ticket in bugzilla and we will take care.

Yocto's Bugzilla isn't recognizing my password, and when it says that it's
emailed me a password change message, it doesn't show up. However, the
four small patches are in the Sourceware binutils-gdb GIT repo, at the
link I mentioned:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366

Just to verify, my binutils-crosssdk_%.bbappend file contains:

FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"

SRC_URI = " \
file://gas_as.h.patch \
file://gas_ChangeLog.patch \
file://gas_input-scrub.c.patch \
file://gas_listing.c.patch \
"

and the patches from that Bugzilla page are in a binutils directory. The
errors I get indicate that the patches are being attempted, but aren't
matching up with any source files.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

On Thu, Oct 12, 2017 at 03:33:53AM +0000, Gutierrez, Hernan Ildefonso (Boise R&D, FW) wrote:

Raj,

Thanks for the response.

Is there an example of what you mentioned below which is open source?

So far my two references have been Freescale and Mali. I found mali much simpler than Freescale, however Mali GPU doesn't really have a refactor of mesa, they only do a simple bbappend to mesa with
the PROVIDES_remove statement I stated in my original note.

you can also look at meta-raspberrypi

For reference here: https://github.com/ARM-software/meta-mali

--Hernan

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Wednesday, October 11, 2017 7:01 PM
To: Gutierrez, Hernan Ildefonso (Boise R&D, FW)
<hernan_gutierrez@...>
Cc: yocto <yocto@...>
Subject: Re: [yocto] How to use two recipes to satisfy different PROVIDES --
gpu support

On Wed, Oct 11, 2017 at 3:15 PM, Gutierrez, Hernan Ildefonso (Boise R&D,
FW) <hernan_gutierrez@...> wrote:

Hi,

We have a GPU in our system. We created a recipe to satisfy all the

dependencies for core-image-weston (virtual/egl, virtual/libgl, etc.), except
virtual/mesa, which is not provided by our GPU recipe.

When one builds core-image-weston, the image requires mesa to build as

well.

Our approach to satisfy dependencies is very similar to what Freescale and

other vendors with Mali GPU support use, which is through the following
statements:

PREFERRED_PROVIDER_virtual/egl = "my-gpu-recipe"
PREFERRED_PROVIDER_virtual/libgles1 = " my-gpu-recipe "
PREFERRED_PROVIDER_virtual/libgles2 = " my-gpu-recipe "
PREFERRED_PROVIDER_virtual/libgl = "my-gpu-recipe"
PREFERRED_PROVIDER_virtual/mesa = "mesa"

The way to remove mesa support for virtual/egl, virtual/libgles1, etc. is by

adding a mesa_%.bbappend where it states explicitly to remove those
provides from mesa recipe.

e.g.
PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/libopenvg

virtual/egl"

The problem I am running into is that bitbake complains stating that
virtual/mesa is not satisfied (Nothing PROVIDES 'virtual/mesa')

When I do bitbake-layers show-recipes, I see that mesa recipe is skipped

because it gave priority to my-gpu-recipe.

How can two recipes be used and let bitbake satisfy parts of each recipe?

Any hints will be appreciated.

there is no easy way to control providers once a recipe is pulled in.
you can refactor mesa recipe like we have done for mesa and mesa-gl which
will mean adding a another recipe which just builds the needed portions of
mesa in each recipe, if your GPU driver provides everything you need to run
weston, then you can let it provide everything that mesa provides and
bitbake wont pick up mesa at all.

Thanks,

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

update to 1.2.15

plus
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: /usr/lib/openscap/ptest/tests/probes/process58/all.sh contained in package openscap-ptest requires /bin/bash, but no providers found in RDEPENDS_openscap-ptest? [file-rdeps]
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: /usr/lib/openscap/ptest/tests/xmldiff.pl contained in package openscap-ptest requires /usr/bin/perl, but no providers found in RDEPENDS_openscap-ptest? [file-rdeps]
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: /usr/lib/openscap/ptest/tests/nist/test_worker.py contained in package openscap-ptest requires /usr/bin/python2, but no providers found in RDEPENDS_openscap-ptest? [file-rdeps]

Signed-off-by: Armin Kuster <akuster808@...>
---
.../openscap/{openscap_1.2.14.bb => openscap_1.2.15.bb} | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
rename meta-security-compliance/recipes-openscap/openscap/{openscap_1.2.14.bb => openscap_1.2.15.bb} (94%)

diff --git a/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb b/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
similarity index 94%
rename from meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb
rename to meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
index 0d26959..4dacfa2 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
@@ -11,7 +11,7 @@ DEPENDS = "autoconf-archive pkgconfig gconf procps curl libxml2 rpm \

DEPENDS_class-native = "autoconf-archive-native pkgconfig-native swig-native curl-native libxml2-native libxslt-native dpkg-native libgcrypt-native nss-native"

-SRCREV = "7a924c0eea10d05f512660192c8c4aef447801a6"
+SRCREV = "240930d42611983c65ecae16dbca3248ce130921"
SRC_URI = "git://github.com/akuster/openscap.git;branch=oe \
file://crypto_pkgconfig.patch \
file://run-ptest \
@@ -66,6 +66,7 @@ do_install_append_class-native () {
TESTDIR = "tests"

do_compile_ptest() {
+ sed -i 's:python2:python:' ${S}/${TESTDIR}/nist/test_worker.py
echo 'buildtest-TESTS: $(check)' >> ${TESTDIR}/Makefile
oe_runmake -C ${TESTDIR} buildtest-TESTS
}
@@ -78,5 +79,6 @@ do_install_ptest() {
FILES_${PN} += "${PYTHON_SITEPACKAGES_DIR}"

RDEPENDS_${PN} += "libxml2 python libgcc"
+RDEPENDS_${PN}-ptest = "bash perl python"

BBCLASSEXTEND = "native"
--
2.7.4

On Thu, Oct 12, 2017 at 06:23:03AM +0000, Paul D. DeRocco wrote:

I found a bug in the GNU assembler that makes it produce corrupted
listings, reported it on sourceware bugzilla, and it has been fixed. Now
I'd like to take those small patches and apply them to the assembler that
winds up in the SDK. The patches are shown here:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366

The only recipe I found in Pyro that seemed appropriate was
meta/recipes-devtools/binutils/binutils-crosssdk_2.28.bb, so I created a
binutils-crosssdk_%.bbappend in my layer with a FILESEXTRAPATHS_prepend
and a SRC_URI listing the patches, which I put into a binutils
subdirectory.

When I ran the populate_sdk task, the patches failed because they didn't
find the source files, which are supposed to be in a subdirectory called
gas.

So I'm wondering, is this the wrong recipe? Does something else build gas?
Or am I just doing this wrong? The workings of the build system are pretty
opaque and mysterious.

You can apply the patch to all binutils variants, its fine. Send a patch or if you
want, file a ticket in bugzilla and we will take care.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

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

I'm confused as to how the devtool sdk-install command is supposed to work. Take for example:

devtool sdk-install cxxtest

This installs all the /usr/lib and /usr/include stuff into the sysroot, but doesn't install the /usr/bin stuff required to actually use cxxtest.

So should I install nativesdk-cxxtest instead? Still doesn't work, but I was just curious about the nativesdk- prefix.
cxxtest-native doesn't work either.
Does the cxxtest recipe need a SYSROOT_DIRS_append = " ${bindir}" in order to get the /usr/bin files installed in the eSDK when someone installs it?



PS - often devtool sdk-install <recipe> will act like it is working and then print an error at the end:

NOTE: Tasks Summary: Attempted 105 tasks of which 71 didn't need to be rerun and all succeeded.
ERROR: Failed to install nativesdk-cxxtest - unavailable



PPS - a google search for devtool sdk-install returns nothing, so hopefully the mailing list can help.

Hi All,

Had a question about kernel-fitimage.bbclass. I am enabling the fitimage using KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPE = "fitImage".
It works and I see fitimage in my deploy directory without any issues.

However when I enable initramfs along with fitimage, using INITRAMFS_IMAGE = "core-image-minimal" and INITRAMFS_IMAGE_BUNDLE = "1", kernel build fails.
It's mostly from kernel.bbclass because it tries to deploy fitimage https://github.com/openembedded/openembedded-core/blob/master/meta/classes/kernel.bbclass#L639
Am I using this featurecorrectly? anyone else facing same issue?

Below is a initial patch which I did to get me across the error, but I am not sure if this is the correct answer.

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 756707a..d5342b4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -208,14 +208,16 @@ do_bundle_initramfs () {
# Backing up kernel image relies on its type(regular file or symbolic link)
tmp_path=""
for type in ${KERNEL_IMAGETYPES} ; do
- if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
- linkpath=`readlink -n ${KERNEL_OUTPUT_DIR}/$type`
- realpath=`readlink -fn ${KERNEL_OUTPUT_DIR}/$type`
- mv -f $realpath $realpath.bak
- tmp_path=$tmp_path" "$type"#"$linkpath"#"$realpath
- elif [ -f ${KERNEL_OUTPUT_DIR}/$type ]; then
- mv -f ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type.bak
- tmp_path=$tmp_path" "$type"##"
+ if [ "$type" != "fitImage" ]; then
+ if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
+ linkpath=`readlink -n ${KERNEL_OUTPUT_DIR}/$type`
+ realpath=`readlink -fn ${KERNEL_OUTPUT_DIR}/$type`
+ mv -f $realpath $realpath.bak
+ tmp_path=$tmp_path" "$type"#"$linkpath"#"$realpath
+ elif [ -f ${KERNEL_OUTPUT_DIR}/$type ]; then
+ mv -f ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type.bak
+ tmp_path=$tmp_path" "$type"##"
+ fi
fi
done
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
@@ -627,8 +629,10 @@ MODULE_TARBALL_DEPLOY ?= "1"

kernel_do_deploy() {
for type in ${KERNEL_IMAGETYPES} ; do
- base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} ${DEPLOYDIR}/${base_name}.bin
+ if [ "$type" != "fitImage" ]; then
+ base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} ${DEPLOYDIR}/${base_name}.bin
+ fi
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -637,21 +641,25 @@ kernel_do_deploy() {
fi

for type in ${KERNEL_IMAGETYPES} ; do
- base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
- symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
- ln -sf ${base_name}.bin ${DEPLOYDIR}/${symlink_name}.bin
- ln -sf ${base_name}.bin ${DEPLOYDIR}/${type}
+ if [ "$type" != "fitImage" ]; then
+ base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+ symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
+ ln -sf ${base_name}.bin ${DEPLOYDIR}/${symlink_name}.bin
+ ln -sf ${base_name}.bin ${DEPLOYDIR}/${type}
+ fi
done

cd ${B}
# Update deploy directory
for type in ${KERNEL_IMAGETYPES} ; do
- if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
- echo "Copying deploy ${type} kernel-initramfs image and setting up links..."
- initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
- initramfs_symlink_name=${type}-initramfs-${MACHINE}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs ${DEPLOYDIR}/${initramfs_base_name}.bin
- ln -sf ${initramfs_base_name}.bin ${DEPLOYDIR}/${initramfs_symlink_name}.bin
+ if [ "$type" != "fitImage" ]; then
+ if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+ echo "Copying deploy ${type} kernel-initramfs image and setting up links..."
+ initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
+ initramfs_symlink_name=${type}-initramfs-${MACHINE}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs ${DEPLOYDIR}/${initramfs_base_name}.bin
+ ln -sf ${initramfs_base_name}.bin ${DEPLOYDIR}/${initramfs_symlink_name}.bin
+ fi
fi
done
}

Thanks,
Manju

Hi

On 12.10.2017 20:47, Ayoub Zaki wrote:

Hi,
On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories layout for expl:


foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
     └── var
         └── lib
             ├── config
             └── data

It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no.... -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"
Regards

Probably you're inheriting from some more complex image class that pulls in the undesired packages. Have you already checked bitbake -e to see how the variables get expanded?

Greetz

--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Hi,


On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories layout for expl:


foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
     └── var
         └── lib
             ├── config
             └── data

It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no.... -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:

IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"

Regards

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile : +4917662901545
Email : ayoub.zaki@...
Homepage : https://embexus.com

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories layout for expl:
foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
    └── var
        └── lib
            ├── config
            └── data
It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no.... -> then nothing should bring along other directories.

Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Hi,

On 12.10.2017 12:32, Bernd wrote:

Suppose I have the following bugfix patch for a 3rd party machine conf
file I am using:

diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf
index 3ddef79..ba47488 100644
--- a/conf/machine/colibri-vf.conf
+++ b/conf/machine/colibri-vf.conf
@@ -35,6 +35,6 @@ MKUBIFS_ARGS = " -c 8112 -e 124KiB -m 2KiB -F"
UBINIZE_ARGS = " -p 128KiB -m 2048 -s 2048"
UBI_VOLNAME = "rootfs"

-SERIAL_CONSOLE ?= "115200 ttyLP0"
+SERIAL_CONSOLE = "115200 ttyLP0"

MACHINE_FEATURES += "usbgadget usbhost vfat alsa touchscreen"

Is there a proper way to somehow temporarily add something to my layer
to apply this patch until it makes its way upstream and into the
branch I am using? Or should I make my own machine file, include the
original one and then change the variable?

you can add to local.conf or distro.conf :

include conf/machine/${MACHINE}-extra.conf

then create in your meta layer or bsp layer :

conf/machine/beaglebone-extra.conf
conf/machine/rasberrypi-extra.conf
conf/machine/xyz-extra.conf

which contains overrides for your machine settings.
Note that is an include and not require, which means that if you machine has no *extra.conf then it's simply skkiped ( no overrides)

So far I have not found any elegant way to otherwise force this
variable to its correct value in my image recipe, the only way I have
found to work around this bug is to .bbappend the inittab recipe where
this variable is actually used and change the value of another
variable (SERIAL_CONSOLES, note the S at the end) which is derived
from SERIAL_CONSOLE right there in this bbappend file. This seems to
help.

But while doing this I have also noticed a strange anomaly in the
output of bitbake -e:

* When I change the variable in my image recipe then bitbake -e will
show another "set" access and both variables SERIAL_CONSOLE and
SERIAL_CONSOLES will have the correct value as intended by me but the
produced image will have the **wrong** entry in its inittab.

* When I bbappend the inittab recipe to set SERIAL_CONSOLES right
there where it is used then my final image will have a correct inittab
and the serial console will work bit there is **no** mention of that
variable change in the output of bitbake -e

* Only when I change the machine conf file iitself to set the variable
then bitbake -e and the produced image both show the correct entry.
Why does it behave that way?

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile : +4917662901545
Email : ayoub.zaki@...
Homepage : https://embexus.com

When publishing a layer, send an email notification to all of that
layer's maintainers.

Fixes [YOCTO #11208]

Signed-off-by: Amanda Brindle <amanda.r.brindle@...>
---
layerindex/views.py | 22 +++++++++++++++++++++-
templates/layerindex/publishemail.txt | 7 +++++++
templates/layerindex/publishemailsubject.txt | 1 +
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 templates/layerindex/publishemail.txt
create mode 100644 templates/layerindex/publishemailsubject.txt

diff --git a/layerindex/views.py b/layerindex/views.py
index bcf6671..35949dd 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -5,7 +5,7 @@
# Licensed under the MIT license, see COPYING.MIT for details

import sys
-from django.shortcuts import get_object_or_404, render
+from django.shortcuts import get_object_or_404, get_list_or_404, render
from django.http import HttpResponse, HttpResponseRedirect, HttpResponseForbidden, Http404
from django.core.urlresolvers import reverse, reverse_lazy, resolve
from django.core.exceptions import PermissionDenied
@@ -261,6 +261,26 @@ def _check_url_branch(kwargs):
def publish(request, name):
if not (request.user.is_authenticated() and request.user.has_perm('layerindex.publish_layer')):
raise PermissionDenied
+ from_email = settings.SUBMIT_EMAIL_FROM
+ plaintext = get_template('layerindex/publishemail.txt')
+ subjecttext = get_template('layerindex/publishemailsubject.txt')
+ e = Context({
+ 'layer_name': layeritem.name,
+ 'site_name': request.META['HTTP_HOST'],
+ })
+ subject = subjecttext.render(e).rstrip()
+ layeritem = get_object_or_404(LayerItem, name=name)
+ layerbranch = get_object_or_404(LayerBranch, layer=layeritem)
+ maintainers = get_list_or_404(LayerMaintainer, layerbranch=layerbranch)
+ layer_url = request.build_absolute_uri(reverse('layer_item', args=(layerbranch.branch, layeritem.name)))
+ for m in maintainers:
+ d = Context({
+ 'maintainer_name': m.name,
+ 'layer_name': layeritem.name,
+ 'layer_url': layer_url,
+ })
+ text_content = plaintext.render(d)
+ tasks.send_email.apply_async((subject, text_content, from_email, [m.email]))
return _statuschange(request, name, 'P')

def _statuschange(request, name, newstatus):
diff --git a/templates/layerindex/publishemail.txt b/templates/layerindex/publishemail.txt
new file mode 100644
index 0000000..2500bff
--- /dev/null
+++ b/templates/layerindex/publishemail.txt
@@ -0,0 +1,7 @@
+Hi {{ maintainer_name }},
+
+You are listed as a maintainer for the new layer, {{ layer_name }}. This layer has been published. You can view it at the following URL:
+
+ {{ layer_url }}
+
+Thanks!
diff --git a/templates/layerindex/publishemailsubject.txt b/templates/layerindex/publishemailsubject.txt
new file mode 100644
index 0000000..a46eaf2
--- /dev/null
+++ b/templates/layerindex/publishemailsubject.txt
@@ -0,0 +1 @@
+{{layer_name }} was published to {{site_name}}
--
2.7.4

The following changes since commit ad1aac4ea5d4f2b327f7bd9611aed13f7c31ff7e:

Show note if layer branch hasn't been indexed (2017-10-04 13:49:00 +1300)

are available in the git repository at:

git://git.yoctoproject.org/layerindex-web abrindle/email_notification_publication
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=abrindle/email_notification_publication

Amanda Brindle (1):
Send email notification on publication

layerindex/views.py | 22 +++++++++++++++++++++-
templates/layerindex/publishemail.txt | 7 +++++++
templates/layerindex/publishemailsubject.txt | 1 +
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 templates/layerindex/publishemail.txt
create mode 100644 templates/layerindex/publishemailsubject.txt

--
2.7.4