Re: [yocto] Possible to rename file when using KERNEL_DEVICETREE_APPEND?

[Brendan Ta]

On 14/08/17 14:20, Khem Raj wrote:

On Sun, Aug 13, 2017 at 3:50 PM, Brendan Ta  wrote:

As the title states, I am including my modified device tree using
KERNEL_DEVICETREE_APPEND= and I was wondering if there was the possibility
where I could rename the file here?

I understand that IMAGE_BOOT_FILES has the option of:
IMAGE_BOOT_FILES = "oldname;newname" which uses the OpenEmbedded Image
Creator; wic.

Is it possible to easily rename the included device tree file using
KERNEL_DEVICETREE_APPEND= ?


I dont think so. But you can insert a function to do so easily. See
meta-raspberrypi for some
guidance, it doesnt do exactly what you want but you can get enough
hints for what can
be done.


Is it possible for you to provide further clarification on which 
function in the meta-raspberrypi to achieve this?  I am just having some 
trouble finding this.


Thanks

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

Re: [yocto] Possible to rename file when using KERNEL_DEVICETREE_APPEND?

[Khem Raj]

On Sun, Aug 13, 2017 at 3:50 PM, Brendan Ta  wrote:
>
> As the title states, I am including my modified device tree using
> KERNEL_DEVICETREE_APPEND= and I was wondering if there was the possibility
> where I could rename the file here?
>
> I understand that IMAGE_BOOT_FILES has the option of:
> IMAGE_BOOT_FILES = "oldname;newname" which uses the OpenEmbedded Image
> Creator; wic.
>
> Is it possible to easily rename the included device tree file using
> KERNEL_DEVICETREE_APPEND= ?
>

I dont think so. But you can insert a function to do so easily. See
meta-raspberrypi for some
guidance, it doesnt do exactly what you want but you can get enough
hints for what can
be done.

> Thanks
>
>
> --
> ___
> 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] [meta-security][PATCH] samhain: update to 4.2.2

[jackie.huang]

From: Jackie Huang 

* update to version 4.2.2
* Add new recipe for standalone mode
* Add systemd support
* Add patches to fix several issues
* samhain-standalone: add ptest support
* samhain-server: no need to depend on samhain-server-native
* Move common things from the bb to the inc file

Signed-off-by: Jackie Huang 
---
 recipes-security/samhain/files/run-ptest   |   3 +
 .../samhain-configure-add-option-for-ps.patch  | 108 ++
 .../samhain/files/samhain-cross-compile.patch  |  51 +++
 .../samhain-mips64-aarch64-dnmalloc-hash-fix.patch |  44 ++
 .../files/samhain-not-run-ptest-on-host.patch  |  24 
 .../samhain/files/samhain-pid-path.patch   |  27 
 .../samhain-samhainrc-fix-files-dirs-path.patch|  61 
 .../samhain/files/samhain-samhainrc.patch  | 158 +
 .../samhain/files/samhain-sha256-big-endian.patch  |  22 +++
 .../samhain/files/samhain-standalone.default   |   3 +
 .../samhain/files/samhain-standalone.init  | 123 
 recipes-security/samhain/files/samhain.service |  12 ++
 ...ain-client_4.2.1.bb => samhain-client_4.2.2.bb} |   6 +-
 ...ain-server_4.2.1.bb => samhain-server_4.2.2.bb} |  35 +
 .../samhain/samhain-standalone_4.2.2.bb|  31 
 recipes-security/samhain/samhain.inc   |  98 +
 16 files changed, 743 insertions(+), 63 deletions(-)
 create mode 100755 recipes-security/samhain/files/run-ptest
 create mode 100644 
recipes-security/samhain/files/samhain-configure-add-option-for-ps.patch
 create mode 100644 recipes-security/samhain/files/samhain-cross-compile.patch
 create mode 100644 
recipes-security/samhain/files/samhain-mips64-aarch64-dnmalloc-hash-fix.patch
 create mode 100644 
recipes-security/samhain/files/samhain-not-run-ptest-on-host.patch
 create mode 100644 recipes-security/samhain/files/samhain-pid-path.patch
 create mode 100644 
recipes-security/samhain/files/samhain-samhainrc-fix-files-dirs-path.patch
 create mode 100644 recipes-security/samhain/files/samhain-samhainrc.patch
 create mode 100644 
recipes-security/samhain/files/samhain-sha256-big-endian.patch
 create mode 100644 recipes-security/samhain/files/samhain-standalone.default
 create mode 100644 recipes-security/samhain/files/samhain-standalone.init
 create mode 100644 recipes-security/samhain/files/samhain.service
 rename recipes-security/samhain/{samhain-client_4.2.1.bb => 
samhain-client_4.2.2.bb} (50%)
 rename recipes-security/samhain/{samhain-server_4.2.1.bb => 
samhain-server_4.2.2.bb} (28%)
 create mode 100644 recipes-security/samhain/samhain-standalone_4.2.2.bb

diff --git a/recipes-security/samhain/files/run-ptest 
b/recipes-security/samhain/files/run-ptest
new file mode 100755
index 000..2a4a765
--- /dev/null
+++ b/recipes-security/samhain/files/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/sh
+current_dir=$(dirname $(readlink -f $0))
+$current_dir/cutest
diff --git 
a/recipes-security/samhain/files/samhain-configure-add-option-for-ps.patch 
b/recipes-security/samhain/files/samhain-configure-add-option-for-ps.patch
new file mode 100644
index 000..8de0735
--- /dev/null
+++ b/recipes-security/samhain/files/samhain-configure-add-option-for-ps.patch
@@ -0,0 +1,108 @@
+From 02a143f0068cbc6cea71359169210fbb3606d4bb Mon Sep 17 00:00:00 2001
+From: Jackie Huang 
+Date: Mon, 18 Jan 2016 00:24:57 -0500
+Subject: [PATCH] configure: add option for ps
+
+The configure searches hardcoded host paths for PSPATH
+and run ps commands to decide PSARG which will fail
+on host without ps:
+| configure: error: Cannot find ps in any of /usr/ucb /bin /usr/bin
+
+So add an option so we can specify the ps at configure
+to avoid host contamination.
+
+Upstream-Status: Inappropriate [cross compile specific]
+
+Signed-off-by: Jackie Huang 
+---
+ aclocal.m4   |  2 +-
+ configure.ac | 60 ++--
+ 2 files changed, 11 insertions(+), 51 deletions(-)
+
+diff --git a/aclocal.m4 b/aclocal.m4
+index a2e59a6..cd20a2f 100644
+--- a/aclocal.m4
 b/aclocal.m4
+@@ -409,7 +409,7 @@ x_includes=NONE
+ x_libraries=NONE
+ DESTDIR=
+ SH_ENABLE_OPTS="selinux posix-acl asm ssp db-reload xml-log message-queue 
login-watch process-check port-check mounts-check logfile-monitor userfiles 
debug ptrace static network udp nocl stealth micro-stealth install-name 
identity khide suidcheck base largefile mail external-scripts encrypt srp 
dnmalloc ipv6 shellexpand suid"
+-SH_WITH_OPTS="prelude libprelude-prefix database libwrap cflags libs console 
altconsole timeserver alttimeserver rnd egd-socket port logserver altlogserver 
kcheck gpg keyid checksum fp recipient sender trusted tmp-dir config-file 
log-file pid-file state-dir data-file html-file"
++SH_WITH_OPTS="prelude libprelude-prefix database libwrap cflags libs console 
altconsole 

Re: [yocto] Errors while tring rpi-test-image for rpi3

[Khem Raj]

On Sat, Aug 12, 2017 at 11:42 PM, Petter Mabacker  wrote:
> On Sat, 2017-08-12 at 15:10 +0300, Jussi Kukkonen wrote:
>
>> ERROR: Nothing PROVIDES 'libav' (but
>>
>> /u/hope_poky/poky_for_mon/poky/meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb
>> DEPENDS on or otherwise requires it)
>> ERROR: ffmpeg PROVIDES libav but was skipped: because it has a
>> restricted license not whitelisted in LICENSE_FLAGS_WHITELIST
>
> Searching the Yocto reference manual for this term will lead to
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes
> which should have the details you need to resolve the issue.
>
> Jussi
>
>
> Hi,
>
> This info is actually also present in the meta-raspberrypi documentation, in
> 'docs/extra-apps.md':
>
> $ cat docs/extra-apps.md
> # Extra apps
>
> ## omxplayer
>
> omxplayer depends on libav which has a commercial license. So in order to be
> able to compile omxplayer you will need to whiteflag the commercial
> license in your local.conf:
>
> LICENSE_FLAGS_WHITELIST = "commercial"
>

it is better to be cautious about it and enable what you want and
ensure you can do so from licesning perspective.

LICENSE_FLAGS_WHITELIST_append = " commercial_libomxil "

e.g. will enable only for libomxil and keep adding to this list the
licenses you want to white list.

>
>
> To make full use of the documentation I recommend that you are generating
> the documentation within docs/ in for example html format and make use of
> the searching functionality in there.
>
>
> BR Petter
>
> --
> ___
> 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] [yocto-docs][PATCH] kernel-dev: fix typo

[Andrea Galbusera]

Signed-off-by: Andrea Galbusera 
---
 documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml 
b/documentation/kernel-dev/kernel-dev-advanced.xml
index 0394e08..c7e5a3a 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -867,7 +867,7 @@
 When stored outside of the recipe-space, the kernel Metadata
 files reside in a separate repository.
 The OpenEmbedded build system adds the Metadata to the build as
-a "ktype=meta" repository through the
+a "type=kmeta" repository through the
 SRC_URI
 variable.
 As an example, consider the following SRC_URI
-- 
2.7.4

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

[yocto] release management

[Russell Peterson]

Hello.

As I learn more about yocto and more importantly gain practical experience with 
it I have started to think about my release structure.  Is there a “best 
practices” document or something like that that speaks to this?

For example, how does everyone deal with “external” meta layer dependencies?  
My software uses poky and meta-openembedded, of course.  It also relies on some 
recipes in meta-linaro and meta-virtualization.  I suspect there will be more 
as time goes by.  I have tweaked my layer priorities as well as used BBMASK to 
avoid unwanted bbappend files etc… works but seems slightly clunky… still 
better than duplicating recipes in my meta layer I think.

Also… I quickly came to the conclusion that “thou shall not modify poky or 
meta-openembedded”.  That is, ALWAYS use bbappend files instead of modifying 
external layers.  If I think that poky or some other layer has a recipe bug or 
want to change something in poky, for example, I plan to upstream a fix to the 
project and when that becomes available I rebase my poky and remove the 
bbappend from my meta layer. One thing about modifying poky and not using 
bbappend files is that I would then need to ship patches for poky instead of 
just directing users to to use this branch and this commit for release x.y.z.

Comments and suggestions welcome.

Regards,

Russell



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

Re: [yocto] Errors while tring rpi-test-image for rpi3

[Petter Mabacker]

On Sat, 2017-08-12 at 15:10 +0300, Jussi Kukkonen wrote:
> > ERROR: Nothing PROVIDES 'libav' (but
> > /u/hope_poky/poky_for_mon/poky/meta-raspberrypi/recipes-
> multimedia/omxplayer/omxplayer_git.bb
> > DEPENDS on or otherwise requires it)
> > ERROR: ffmpeg PROVIDES libav but was skipped: because it has a
> > restricted license not whitelisted in LICENSE_FLAGS_WHITELIST
> 
> Searching the Yocto reference manual for this term will lead to http:
> //www.yoctoproject.org/docs/current/ref-manual/ref-
> manual.html#enabling-commercially-licensed-recipes which should have
> the details you need to resolve the issue. 
> 
> Jussi

Hi,
This info is actually also present in the meta-raspberrypi
documentation, in 'docs/extra-apps.md':
$ cat docs/extra-apps.md# Extra apps
## omxplayer
omxplayer depends on libav which has a commercial license. So in order
to beable to compile omxplayer you will need to whiteflag the
commerciallicense in your local.conf:
LICENSE_FLAGS_WHITELIST = "commercial"


To make full use of the documentation I recommend that you are
generating the documentation within docs/ in for example html format
and make use of the searching functionality in there.

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