Date   

Re: OEM supplied yocto image is impossible to work with

Josef Holzmayr <holzmayr@...>
 

Hello Kent!

Sorry to hear that your presumably first contact with Yocto respectively
OpenEmbedded technology is being so painful. Please find some thought
and comments inline.

On Fri, Dec 27, 2019 at 12:00:13PM -0500, Kent Dorfman wrote:
Oh, and this is the THIRD time I've tried posting this...you certainly
don't make the yocto mailing lists easy to subscribe to.

Lemme appologize in avance because parts of this are going to come
across as rants directed at both our OEM and yocto. Hopefully "yinz"
have thick skins.
We have, by now.

I've been doing embedded system design since the beginning of the
millenium (mostly VXworks, with some linux intel embedded, PPC
cross-dev chain stuff, and bare metal C/C++ microcontrollers) and now
I'm tasked with implementing a very mission critical set of embedded
processors in an aerospace project. I've not used yocto before. The
closest thing being buildroot.
"close" is really somewhat relative here. The words that trigger my
alarm here are "mission critical" and "aerospace". Anything that I will
write below is no legal advice, and not fit for any form of
certification or audit. If these are your requirements, then there are
companies in the Yocto ecosystem that are willing to offer their
services.

Anyway, the OEM for our boards was chosen before I came on board and
while I can find no fault with the zynq based hardware, their software
SDK and support is fracking terrible.
BSPs are a constant cause of pain for us giving Yocto support too. If
a board vendor screws up, we get to pick up the pieces too many times.

Like most OEMs, their prefered model is to give the customer just
enough information to try and force us to pay them to build a turnkey
solution on our behalf, which is not an option in our enterprise.
Little to add, besides... that it might have been a bad choice or
negotiation, if you're only now learning that they want to charge you
additionally. Thats something we obviously can't help you with.

Their minimal yocto based SDK and reference implementation:

1) as is, isn't suitable for our mission needs, where we must make
changes to the base image, kernel, and initramfs. They seem to
expect customers to only add on apps to the UBI rootfs and not screw
with anything else.
If they are not willing to hand out all sources plus metadata layers,
then thats a total red flag. Yet again, not something we could change.

2) has many closed source packages in it that will only build from
source when in their local intranet. Deleting the cache and
attempting a complete source level rebuild consistently fails.
Red flag. Once again.

3) isn't documented at all, and they will only answer direct, well
phrased questions, instead of volunteering information that meets our
stated goals.
And another one.

4) them being a multinational company causes additional legal,
information sharing, and logistical problems
Sorry, I mean... didn't you request at least some form of eval kit? Demo
boards? To actually understand what you are buying?

Up to this point, yes, I can feel your frustration, but there's little
to say other than that you probably have a bad partnership by now.

So now, on to things that I can hopefully say more positive things.

Questions/problems in yocto where the documentation kind of sucks, are:

1) the necessity to "clean build" is inherent in any software
endeavour, yet the simple equivalent of "make clean && make image" is
nowhere to be easily found in yocto. It is implied that deleting the
tmp/ and sstate_cache/ directories should have the same affect, but is
that safe? What will it break? I need to be confident in the process
when I go scream at the OEM, telling them that their build tool is
incomplete for our air-gapped environment.
The cleanest without throwing away the whole build that you can do is
remove everything in the build directory besides "conf". Yet there are
probably two sides to your actual question. a "bitbake -c clean
$YOURRECIPE" is the perfect equivalent to make clean, "bitbake
$YOURRECIPE" equivalates to "make". Wiping tmp and sstate cache is
pretty close to a full clean rebuild of the whole system, and no, it
shall not break. If it does, there is either something wrong with your
build setup (can happen) or you hit a bug (happens less often, but
happens too). The second side is actually running a full system rebuild,
which includes the complete build setup. Actually there is no
Yocto-inhernt way to do it, as different people have different needs -
and nobody managed a one size fits all solution until now. You can look
at the autobuilder as provided by the Yocto Project, and at the various
approaches here [1];

2) related to above, yocto needs a much better description of the
expected directory tree within a project.
Within a project? Could you please elaborate?

3) the relationship between bitbake and devtool needs to be better
documented and both utilities need to be better documented themselves.
trying to run bitbake manually causes path errors (null entry in path)
when in fact, bitbake itself is setting a path somewhere incorrectly.
my path has no null entries or "." in it.
bitbake and devtool can and should be used side by side. Running bitbake
manually, as you put it, is the definitively primary way of doing
things. So if that eeks out for, there is probably something strange
with your setup. If you can provide a more extensive log or error
message, we will happily...erm, at least honestly try to help.

4) yocto documentation fails in presenting a good explanation of the
difference between packages, layers, recipes, and images. Also, I've
seen cases where virtual/kernel is used to check-out the kernel to
work on it, yet no virtual/kernel directory exists in the layers
directory tree, so a better explanation of the mapping between real
directories and virtual names is warranted. ... and yes, I know what
BB files are for.
I tend to agree on the mapping part.

5) a big area that seems to be lacking is the ability to inquire in a
yocto build as to what is included in it. This is especially
important if the responsible party didn't actually create the build,
as is our case. We're left with trying to guess what the OEM did, and
why.
Now this is certainly not true. Even in the utmost default setup, a
manifest file will be created along the image which tells you which
packages including version and license that went into it.

bitbake -g $TARGETOFYOURCHOICE will give you a dot file to inspect the
complete dependency graph of your chosen target. This is a bit too much
in-depth at times, but extremely powerful.

And last but not least, its a good practise to have buildhistory enabled
[2]. This offers extremely detailed information about each and every
package and dependency that went into your build, down to each single
file, package size,...

6) the seeming inability of yocto to build reproducable binary images
is a serious shortcoming in IA environments. The first step in
development for us is to baseline the reference build provided by the
OEM and then make incremental changes to it, but yocto doesn't seem to
have a way to validate that the build done in-house is identical to
the pre-built images supplied on the board. Is there a way to "forced
sequentialize" the yocto process so that images can be reproducable?
There is work being done on reproductible builds, but we're not there
yet. Might not be the answer you want or need, but the honest state of
affairs.

7) a large part of me wants to throw away the OEM build and start from
scratch, but I have no information about how to correctly import their
"blob only" packages into a separate yocto project. Hell, I am not
convinced that their blobs will remain persistent if I delete the
cache because I don't know whether they were created in their network
and expected to always live in the cache, thus negating the ability
of a customer to do a "clean build"
Including pre-produced blobs in a Yocto build is not pretty, but often
handy or impossible to avoid. Please see [3] for the documentation on
it.

Anyway, yes, I've read what docs I can find on yocto, and aside from
falling asleep several times in the process, the docs really are not
helping me with the problem at hand: using an existing yocto build
provided by a possibly unscrupulous vendor.
In a nutshell: whenever somebody hands you a binary build, without the
corresponding set of sources and metadata, then you are out of luck and
in for a lot of pain. That exactly the way of how to NOT use yocto when
selling hardware. Some do, and unfortunately we, as the Yocto community
can't do much about it, other than try and help the folks who struggle
with it. And go buy our hardware in another place.

Having said all this. Yes, we know that we have a very steep learning
curve and lots of places to go wrong - yet on the other hand if you make
it through *AND* if it fits your needs, then you are awarded with an
amount of power that is beyond comparison to about any other build
system. But those are two big ifs, yes, and the latter we cannot answer
for you. Only help in the first one.

This might not be the best time of the year as most of us are on
vacation, but feel free to head into #yocto on the freenode network,
where you can easily get in touch with us directly, and we really try to
offer good help and advice. Starting from Jan 7th, you can also expect
better response times :)

And while maybe not an exact fit for you, there still might be
interesting sessions in this playlist for you [4].

With that, I hope I could give a somewhat helpful but certainly
honest answer.

Greetz

[1] https://stackoverflow.com/questions/58863254/how-to-manage-meta-layers-for-a-yocto-project-build-configs-in-git/58865947#58865947
[2] https://www.yoctoproject.org/docs/3.0.1/dev-manual/dev-manual.html#maintaining-build-output-quality
[3] https://www.yoctoproject.org/docs/3.0.1/dev-manual/dev-manual.html#packaging-externally-produced-binaries
[4] https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

--
———————————————
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


OEM supplied yocto image is impossible to work with

Kent Dorfman <kent.dorfman766@...>
 

Oh, and this is the THIRD time I've tried posting this...you certainly
don't make the yocto mailing lists easy to subscribe to.

Lemme appologize in avance because parts of this are going to come
across as rants directed at both our OEM and yocto. Hopefully "yinz"
have thick skins.

I've been doing embedded system design since the beginning of the
millenium (mostly VXworks, with some linux intel embedded, PPC
cross-dev chain stuff, and bare metal C/C++ microcontrollers) and now
I'm tasked with implementing a very mission critical set of embedded
processors in an aerospace project. I've not used yocto before. The
closest thing being buildroot.

Anyway, the OEM for our boards was chosen before I came on board and
while I can find no fault with the zynq based hardware, their software
SDK and support is fracking terrible.

Like most OEMs, their prefered model is to give the customer just
enough information to try and force us to pay them to build a turnkey
solution on our behalf, which is not an option in our enterprise.

Their minimal yocto based SDK and reference implementation:

1) as is, isn't suitable for our mission needs, where we must make
changes to the base image, kernel, and initramfs. They seem to
expect customers to only add on apps to the UBI rootfs and not screw
with anything else.

2) has many closed source packages in it that will only build from
source when in their local intranet. Deleting the cache and
attempting a complete source level rebuild consistently fails.

3) isn't documented at all, and they will only answer direct, well
phrased questions, instead of volunteering information that meets our
stated goals.

4) them being a multinational company causes additional legal,
information sharing, and logistical problems

Questions/problems in yocto where the documentation kind of sucks, are:

1) the necessity to "clean build" is inherent in any software
endeavour, yet the simple equivalent of "make clean && make image" is
nowhere to be easily found in yocto. It is implied that deleting the
tmp/ and sstate_cache/ directories should have the same affect, but is
that safe? What will it break? I need to be confident in the process
when I go scream at the OEM, telling them that their build tool is
incomplete for our air-gapped environment.

2) related to above, yocto needs a much better description of the
expected directory tree within a project.

3) the relationship between bitbake and devtool needs to be better
documented and both utilities need to be better documented themselves.
trying to run bitbake manually causes path errors (null entry in path)
when in fact, bitbake itself is setting a path somewhere incorrectly.
my path has no null entries or "." in it.

4) yocto documentation fails in presenting a good explanation of the
difference between packages, layers, recipes, and images. Also, I've
seen cases where virtual/kernel is used to check-out the kernel to
work on it, yet no virtual/kernel directory exists in the layers
directory tree, so a better explanation of the mapping between real
directories and virtual names is warranted. ... and yes, I know what
BB files are for.

5) a big area that seems to be lacking is the ability to inquire in a
yocto build as to what is included in it. This is especially
important if the responsible party didn't actually create the build,
as is our case. We're left with trying to guess what the OEM did, and
why.

6) the seeming inability of yocto to build reproducable binary images
is a serious shortcoming in IA environments. The first step in
development for us is to baseline the reference build provided by the
OEM and then make incremental changes to it, but yocto doesn't seem to
have a way to validate that the build done in-house is identical to
the pre-built images supplied on the board. Is there a way to "forced
sequentialize" the yocto process so that images can be reproducable?

7) a large part of me wants to throw away the OEM build and start from
scratch, but I have no information about how to correctly import their
"blob only" packages into a separate yocto project. Hell, I am not
convinced that their blobs will remain persistent if I delete the
cache because I don't know whether they were created in their network
and expected to always live in the cache, thus negating the ability
of a customer to do a "clean build"

Anyway, yes, I've read what docs I can find on yocto, and aside from
falling asleep several times in the process, the docs really are not
helping me with the problem at hand: using an existing yocto build
provided by a possibly unscrupulous vendor.


[meta-selinux][PATCH] audit: fix host contamination for swig

Yi Zhao
 

The audit build uses swig to generate a python wrapper. But there is a
hardcoded include directory in auditswig.i, which causes header files on
the host to be used when building. This will cause build error on some
old systems. e.g. on CentOS7 with buildtools:
audit_wrap.c: In function '_wrap_audit_rule_flags_set':
audit_wrap.c:5018:19: error: dereferencing pointer to incomplete type 'struct audit_rule'
5018 if (arg1) (arg1)->flags = arg2;
^~

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../Fixed-swig-host-contamination-issue.patch | 57 +++++++++++++++++++
recipes-security/audit/audit_2.8.5.bb | 1 +
2 files changed, 58 insertions(+)
create mode 100644 recipes-security/audit/audit/Fixed-swig-host-contamination-issue.patch

diff --git a/recipes-security/audit/audit/Fixed-swig-host-contamination-issue.patch b/recipes-security/audit/audit/Fixed-swig-host-contamination-issue.patch
new file mode 100644
index 0000000..7c26995
--- /dev/null
+++ b/recipes-security/audit/audit/Fixed-swig-host-contamination-issue.patch
@@ -0,0 +1,57 @@
+From a07271f1cce82122610b622bcea4a8a37528f321 Mon Sep 17 00:00:00 2001
+From: Li xin <lixin.fnst@...>
+Date: Sun, 19 Jul 2015 02:42:58 +0900
+Subject: [PATCH] audit: Fixed swig host contamination issue
+
+The audit build uses swig to generate a python wrapper.
+Unfortunately, the swig info file references host include
+directories. Some of these were previously noticed and
+eliminated, but the one fixed here was not.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Anders Hedlund <anders.hedlund@...>
+Signed-off-by: Joe Slater <jslater@...>
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ bindings/swig/python3/Makefile.am | 3 ++-
+ bindings/swig/src/auditswig.i | 2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/bindings/swig/python3/Makefile.am b/bindings/swig/python3/Makefile.am
+index 9938418..fa46aac 100644
+--- a/bindings/swig/python3/Makefile.am
++++ b/bindings/swig/python3/Makefile.am
+@@ -22,6 +22,7 @@
+ CONFIG_CLEAN_FILES = *.loT *.rej *.orig
+ AM_CFLAGS = -fPIC -DPIC -fno-strict-aliasing $(PYTHON3_CFLAGS)
+ AM_CPPFLAGS = -I. -I$(top_builddir) -I${top_srcdir}/lib $(PYTHON3_INCLUDES)
++STDINC ?= /usr/include
+ LIBS = $(top_builddir)/lib/libaudit.la
+ SWIG_FLAGS = -python -py3 -modern
+ SWIG_INCLUDES = -I. -I$(top_builddir) -I${top_srcdir}/lib $(PYTHON3_INCLUDES)
+@@ -37,7 +38,7 @@ _audit_la_DEPENDENCIES =${top_srcdir}/lib/libaudit.h ${top_builddir}/lib/libaudi
+ _audit_la_LIBADD = ${top_builddir}/lib/libaudit.la
+ nodist__audit_la_SOURCES = audit_wrap.c
+ audit.py audit_wrap.c: ${srcdir}/../src/auditswig.i
+- swig -o audit_wrap.c ${SWIG_FLAGS} ${SWIG_INCLUDES} ${srcdir}/../src/auditswig.i
++ swig -o audit_wrap.c ${SWIG_FLAGS} ${SWIG_INCLUDES} -I$(STDINC) ${srcdir}/../src/auditswig.i
+
+ CLEANFILES = audit.py* audit_wrap.c *~
+
+diff --git a/bindings/swig/src/auditswig.i b/bindings/swig/src/auditswig.i
+index 7ebb373..424fb68 100644
+--- a/bindings/swig/src/auditswig.i
++++ b/bindings/swig/src/auditswig.i
+@@ -39,7 +39,7 @@ signed
+ #define __attribute(X) /*nothing*/
+ typedef unsigned __u32;
+ typedef unsigned uid_t;
+-%include "/usr/include/linux/audit.h"
++%include "linux/audit.h"
+ #define __extension__ /*nothing*/
+ #include <stdint.h>
+ %include "../lib/libaudit.h"
+--
+2.7.4
+
diff --git a/recipes-security/audit/audit_2.8.5.bb b/recipes-security/audit/audit_2.8.5.bb
index 1e76d5f..ee3b3b5 100644
--- a/recipes-security/audit/audit_2.8.5.bb
+++ b/recipes-security/audit/audit_2.8.5.bb
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"

SRC_URI = "git://github.com/linux-audit/${BPN}-userspace.git;branch=2.8_maintenance \
file://Add-substitue-functions-for-strndupa-rawmemchr.patch \
+ file://Fixed-swig-host-contamination-issue.patch \
file://auditd \
file://auditd.service \
file://audit-volatile.conf \
--
2.17.1


Re: [meson][PATCH] meson: Allow for llvm-native tools to be used

Alexander Kanavin
 

This should be going to the oe-core list.

Alex

On Wed, 25 Dec 2019 at 12:24, <fdk17@...> wrote:
I created a bbappend to build the LLVM recipe so that all the libraries were available for use on the host.
These libraries are then used by a host/sdk tool to prepare binary files for use by an application on the target.
When building our tool using meson it wasn't able to find the Yocto built LLLVM libraries.
This fixes the issue so meson uses the correct llvm-config tool.

Author: Fred Baksik <fred.baksik@...>
Date:   Tue Dec 24 20:38:47 2019 -0500

    meson: Allow for llvm-native tools to be used
   
    Signed-off-by: Fred Baksik <fred.baksik@...>

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index e1a13bbbf7..b5cd2ee8c4 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -33,6 +33,7 @@ EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
 MESON_CROSS_FILE = ""
 MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
 MESON_CROSS_FILE_class-nativesdk = "--cross-file ${WORKDIR}/meson.cross"
+MESON_CROSS_FILE_class-native = "--native-file ${WORKDIR}/meson.native"
 
 def meson_array(var, d):
     items = d.getVar(var).split()
@@ -110,6 +111,14 @@ endian = '${@meson_endian('TARGET', d)}'
 EOF
 }
 
+do_write_config_class-native() {
+    # This needs to be Py to split the args into single-element lists
+    cat >${WORKDIR}/meson.native <<EOF
+[binaries]
+llvm-config = 'llvm-config${LLVMVERSION}'
+EOF
+}
+
 CONFIGURE_FILES = "meson.build"
 
 meson_do_configure() { -=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47821): https://lists.yoctoproject.org/g/yocto/message/47821
Mute This Topic: https://lists.yoctoproject.org/mt/69260511/1686489
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [alex.kanavin@...]
-=-=-=-=-=-=-=-=-=-=-=-


[meson][PATCH] meson: Allow for llvm-native tools to be used

Fred Baksik
 

I created a bbappend to build the LLVM recipe so that all the libraries were available for use on the host.
These libraries are then used by a host/sdk tool to prepare binary files for use by an application on the target.
When building our tool using meson it wasn't able to find the Yocto built LLLVM libraries.
This fixes the issue so meson uses the correct llvm-config tool.

Author: Fred Baksik <fred.baksik@...>
Date:   Tue Dec 24 20:38:47 2019 -0500

    meson: Allow for llvm-native tools to be used
   
    Signed-off-by: Fred Baksik <fred.baksik@...>

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index e1a13bbbf7..b5cd2ee8c4 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -33,6 +33,7 @@ EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
 MESON_CROSS_FILE = ""
 MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
 MESON_CROSS_FILE_class-nativesdk = "--cross-file ${WORKDIR}/meson.cross"
+MESON_CROSS_FILE_class-native = "--native-file ${WORKDIR}/meson.native"
 
 def meson_array(var, d):
     items = d.getVar(var).split()
@@ -110,6 +111,14 @@ endian = '${@meson_endian('TARGET', d)}'
 EOF
 }
 
+do_write_config_class-native() {
+    # This needs to be Py to split the args into single-element lists
+    cat >${WORKDIR}/meson.native <<EOF
+[binaries]
+llvm-config = 'llvm-config${LLVMVERSION}'
+EOF
+}
+
 CONFIGURE_FILES = "meson.build"
 
 meson_do_configure() {


Re: [meta-selinux][PATCH 4/6] selinux-initsh.inc: install selinux-init.sh and selinux-labeldev.sh when using systemd

Yi Zhao
 

On 12/24/19 10:22 PM, Joe MacDonald wrote:
Hi Yi,

I've merged the others in this series, can you elaborate a bit on how
this ensures we don't have a problem coming back that 5fd3c5b71 was
intended to address?

There are 3 recipes require selinux-initsh.inc: selinux-init_0.1.bb, selinux-labeldev_0.1.bb and selinux-autorelabel_0.1.bb. The ${SELINUX_SCRIPT_SRC}.sh will expand to different script name  in each of recipes: selinux-init.sh, selinux-labeldev.sh and selinux-autorelabel.sh. These scripts will be invoked by systemd services. The commit 5fd3c5b71edb99659aeb5cb5903088d84517382e move all installation codes to selinux-autorelabel_0.1.bb which make the selinux-init.sh and selinux-labeldev.sh will be not installed. This patch keeps the touching .autorelabel code in the selinux-autorelabel recipe and move the rest codes back to selinux-initsh.inc.


//Yi



Thanks,
-J.

[[meta-selinux][PATCH 4/6] selinux-initsh.inc: install selinux-init.sh and selinux-labeldev.sh when using systemd] On 19.12.23 (Mon 16:21) Yi Zhao wrote:

The commit 5fd3c5b71edb99659aeb5cb5903088d84517382e introduced an issue
that selinux-init.sh and selinux-labeldev.sh are not installed when
using systemd which will cause the selinux-ini.service and
selinux-labeldev.service fail to startup. Move the do_install codes from
selinux-autorelabel to selinux-initsh.inc to make sure install these
scripts when using systemd.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-autorelabel_0.1.bb | 3 ---
recipes-security/selinux/selinux-initsh.inc | 9 +++++++--
2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/recipes-security/selinux/selinux-autorelabel_0.1.bb b/recipes-security/selinux/selinux-autorelabel_0.1.bb
index 7e7d08c..b898c3b 100644
--- a/recipes-security/selinux/selinux-autorelabel_0.1.bb
+++ b/recipes-security/selinux/selinux-autorelabel_0.1.bb
@@ -21,9 +21,6 @@ require selinux-initsh.inc
do_install_append() {
if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
- install -d ${D}${bindir}
- install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh ${D}${bindir}
- sed -i -e '/.*HERE$/d' ${D}${bindir}/${SELINUX_SCRIPT_SRC}.sh
echo "# first boot relabelling" > ${D}/.autorelabel
fi
}
diff --git a/recipes-security/selinux/selinux-initsh.inc b/recipes-security/selinux/selinux-initsh.inc
index 6084762..0a6cf4b 100644
--- a/recipes-security/selinux/selinux-initsh.inc
+++ b/recipes-security/selinux/selinux-initsh.inc
@@ -27,8 +27,13 @@ do_install () {
-e '/.*HERE$/d' -e '/.*Contents.*sysvinit/d' \
${D}${sysconfdir}/init.d/${SELINUX_SCRIPT_DST}
- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.service ${D}${systemd_unitdir}/system
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ install -d ${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.service ${D}${systemd_unitdir}/system
+ install -d ${D}${bindir}
+ install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh ${D}${bindir}
+ sed -i -e '/.*HERE$/d' ${D}${bindir}/${SELINUX_SCRIPT_SRC}.sh
+ fi
}
sysroot_stage_all_append () {
--
2.17.1


[meta-selinux][PATCH 1/2] libselinux-python: add DEPENDS on libpcre and libsepol

Yi Zhao
 

We encountered a libselinux-python compile error when bitbake world
without selinux DISTRO_FEATURES:
In file included from label_file.h:16,
from label_file.c:24:
regex.h:10:10: fatal error: pcre.h: No such file or directory
10 | #include <pcre.h>
| ^~~~~~~~
compilation terminated.

Add missing DEPENDS on libpcre and libsepol.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/libselinux-python.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/selinux/libselinux-python.inc b/recipes-security/selinux/libselinux-python.inc
index 24407e8..9f10e15 100644
--- a/recipes-security/selinux/libselinux-python.inc
+++ b/recipes-security/selinux/libselinux-python.inc
@@ -9,7 +9,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/libselinux:"

inherit python3-dir

-DEPENDS += "python3 swig-native"
+DEPENDS += "python3 swig-native libpcre libsepol"
RDEPENDS_${PN} += "libselinux python3-core python3-shell"

def get_policyconfigarch(d):
--
2.17.1


[meta-selinux][PATCH 2/2] setools: add DEPENDS on libselinux

Yi Zhao
 

We encountered a setools compile error when bitbake world without
selinux DISTRO_FEATURES:

setools/policyrep.c:666:10: fatal error: selinux/selinux.h: No such file or directory
666 | #include <selinux/selinux.h>
| ^~~~~~~~~~~~~~~~~~~
compilation terminated.

Add missing DEPENDS on libselinux.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/setools/setools_4.2.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/setools/setools_4.2.2.bb b/recipes-security/setools/setools_4.2.2.bb
index 6e5a950..3d89700 100644
--- a/recipes-security/setools/setools_4.2.2.bb
+++ b/recipes-security/setools/setools_4.2.2.bb
@@ -19,7 +19,7 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=83a5eb6974c11f30785e90d0eeccf40c \
file://${S}/COPYING.GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
file://${S}/COPYING.LGPL;md5=4fbd65380cdd255951079008b364516c"

-DEPENDS += "bison-native flex-native swig-native python3 python3-cython-native libsepol"
+DEPENDS += "bison-native flex-native swig-native python3 python3-cython-native libsepol libselinux"

RDEPENDS_${PN} += "python3-networkx python3-decorator python3-setuptools \
python3-logging python3-json libselinux-python"
--
2.17.1


Re: building vlc

Khem Raj
 



On Tue, Dec 24, 2019 at 4:31 AM Sheraz Ali <sheraz.ali@...> wrote:

Hi,

    I am trying to build vlc,

I have added vlc to rootfs by adding following line in conf/local.conf

IMAGE_INSTALL_append = " vlc "

CORE_IMAGE_EXTRA_INSTALL +="vlc"

In both the cases i was getting the following error when i was try to start the vlc player

root@iWave-G15:~# vlc -vvv
VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
[001450d0] core libvlc debug: VLC media player - 2.2.2 Weatherwax
[001450d0] core libvlc debug: Copyright �© 1996-2016 the VideoLAN team
[001450d0] core libvlc debug: revision 2.2.2-0-g6259d80
[001450d0] core libvlc debug: configured with ../vlc-2.2.2/configure '--build=x86_64-linux' '--host=arm-poky-linux-gnueabi' '--target=arm-poky-linux-gnueabi' '--prefix=/usr' '
[001450d0] core libvlc debug: searching plug-in modules
[001450d0] core libvlc debug: loading plugins cache file /usr/lib/vlc/plugins/plugins.dat
[001450d0] core libvlc warning: cannot read /usr/lib/vlc/plugins/plugins.dat: No such file or directory
[001450d0] core libvlc debug: recursively browsing `/usr/lib/vlc/plugins'
Segmentation fault


Perhaps you should connect gdb to it and see if you can get stacktrace at this segfault

Am i missing any steps?

-- 
Thanks and Regards
Sheraz Ali Shah
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
You automatically follow any topics you start or reply to.

View/Reply Online (#47815): https://lists.yoctoproject.org/g/yocto/message/47815
Mute This Topic: https://lists.yoctoproject.org/mt/69248290/1997914
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [raj.khem@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [meta-selinux][PATCH 4/6] selinux-initsh.inc: install selinux-init.sh and selinux-labeldev.sh when using systemd

Joe MacDonald
 

Hi Yi,

I've merged the others in this series, can you elaborate a bit on how
this ensures we don't have a problem coming back that 5fd3c5b71 was
intended to address?

Thanks,
-J.

[[meta-selinux][PATCH 4/6] selinux-initsh.inc: install selinux-init.sh and selinux-labeldev.sh when using systemd] On 19.12.23 (Mon 16:21) Yi Zhao wrote:

The commit 5fd3c5b71edb99659aeb5cb5903088d84517382e introduced an issue
that selinux-init.sh and selinux-labeldev.sh are not installed when
using systemd which will cause the selinux-ini.service and
selinux-labeldev.service fail to startup. Move the do_install codes from
selinux-autorelabel to selinux-initsh.inc to make sure install these
scripts when using systemd.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-autorelabel_0.1.bb | 3 ---
recipes-security/selinux/selinux-initsh.inc | 9 +++++++--
2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/recipes-security/selinux/selinux-autorelabel_0.1.bb b/recipes-security/selinux/selinux-autorelabel_0.1.bb
index 7e7d08c..b898c3b 100644
--- a/recipes-security/selinux/selinux-autorelabel_0.1.bb
+++ b/recipes-security/selinux/selinux-autorelabel_0.1.bb
@@ -21,9 +21,6 @@ require selinux-initsh.inc

do_install_append() {
if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
- install -d ${D}${bindir}
- install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh ${D}${bindir}
- sed -i -e '/.*HERE$/d' ${D}${bindir}/${SELINUX_SCRIPT_SRC}.sh
echo "# first boot relabelling" > ${D}/.autorelabel
fi
}
diff --git a/recipes-security/selinux/selinux-initsh.inc b/recipes-security/selinux/selinux-initsh.inc
index 6084762..0a6cf4b 100644
--- a/recipes-security/selinux/selinux-initsh.inc
+++ b/recipes-security/selinux/selinux-initsh.inc
@@ -27,8 +27,13 @@ do_install () {
-e '/.*HERE$/d' -e '/.*Contents.*sysvinit/d' \
${D}${sysconfdir}/init.d/${SELINUX_SCRIPT_DST}

- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.service ${D}${systemd_unitdir}/system
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ install -d ${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.service ${D}${systemd_unitdir}/system
+ install -d ${D}${bindir}
+ install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh ${D}${bindir}
+ sed -i -e '/.*HERE$/d' ${D}${bindir}/${SELINUX_SCRIPT_SRC}.sh
+ fi
}

sysroot_stage_all_append () {
--
2.17.1
--
-Joe MacDonald.
:wq


building vlc

Sheraz Ali <sheraz.ali@...>
 

Hi,

    I am trying to build vlc,

I have added vlc to rootfs by adding following line in conf/local.conf

IMAGE_INSTALL_append = " vlc "

CORE_IMAGE_EXTRA_INSTALL +="vlc"

In both the cases i was getting the following error when i was try to start the vlc player

root@iWave-G15:~# vlc -vvv
VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
[001450d0] core libvlc debug: VLC media player - 2.2.2 Weatherwax
[001450d0] core libvlc debug: Copyright �© 1996-2016 the VideoLAN team
[001450d0] core libvlc debug: revision 2.2.2-0-g6259d80
[001450d0] core libvlc debug: configured with ../vlc-2.2.2/configure '--build=x86_64-linux' '--host=arm-poky-linux-gnueabi' '--target=arm-poky-linux-gnueabi' '--prefix=/usr' '
[001450d0] core libvlc debug: searching plug-in modules
[001450d0] core libvlc debug: loading plugins cache file /usr/lib/vlc/plugins/plugins.dat
[001450d0] core libvlc warning: cannot read /usr/lib/vlc/plugins/plugins.dat: No such file or directory
[001450d0] core libvlc debug: recursively browsing `/usr/lib/vlc/plugins'
Segmentation fault

Am i missing any steps?

-- 
Thanks and Regards
Sheraz Ali Shah


Re: Raspberry pi 4 recipe and layer issues.

Josef Holzmayr <holzmayr@...>
 

Howdy.

On Mon, Dec 23, 2019 at 09:11:07PM +0000, Ed Vidal wrote:
The Makefile executes several lines, which set variables ARACHNE_VER, GIT_REV, and VER_HASH.   These are used in the rule which creates a file src/version_$(VER_HASH).cc.The line below appears to be the one that causes the error.VER_HASH = $(shell echo "$(ARACHNE_VER) $(GIT_REV)" | sum | cut -d ' ' -f -1)
src/version_$(VER_HASH).cc: echo "const char *version_str = \"arachne-pnr $(ARACHNE_VER) (git sha1 $(GIT_REV), $(notdir $(CXX)) `$(CXX) --version | tr ' ()' '\n' | grep '^[0-9]' | head -n1` $(filter -f% -m% -O% -DNDEBUG,$(CXXFLAGS)))\";" > src/version_$(VER_HASH).cc
bin/arachne-pnr$(EXE): src/arachne-pnr.o src/netlist.o src/blif.o src/pack.o src/place.o src/util.o src/io.o src/route.o src/chipdb.o src/location.o src/configuration.o src/line_parser.o src/pcf.o src/global.o src/constant.o src/designstate.o src/version_$(VER_HASH).o $(CXX) $(CXXFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
These variables are based on git revision.   So I can not hard code them.This is the error that I get.
/bin/sh: 1: sum: not found
If a Makefile does such _stupid_ things, then better patch it. An
example of patching something like this is

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/util-linux/util-linux/configure-sbindir.patch

which targets configure.ac, but hey, little difference to a Makefile.

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


Re: Raspberry pi 4 recipe and layer issues.

Ed Vidal
 

Hi 


The Makefile executes several lines, which set variables ARACHNE_VER, GIT_REV, and VER_HASH.   These are used in the rule which creates a file src/version_$(VER_HASH).cc.
The line below appears to be the one that causes the error.
VER_HASH = $(shell echo "$(ARACHNE_VER) $(GIT_REV)" | sum | cut -d ' ' -f -1)

src/version_$(VER_HASH).cc:
echo "const char *version_str = \"arachne-pnr $(ARACHNE_VER) (git sha1 $(GIT_REV), $(notdir $(CXX)) `$(CXX) --version | tr ' ()' '\n' | grep '^[0-9]' | head -n1` $(filter -f% -m% -O% -DNDEBUG,$(CXXFLAGS)))\";" > src/version_$(VER_HASH).cc

bin/arachne-pnr$(EXE): src/arachne-pnr.o src/netlist.o src/blif.o src/pack.o src/place.o src/util.o src/io.o src/route.o src/chipdb.o src/location.o src/configuration.o src/line_parser.o src/pcf.o src/global.o src/constant.o src/designstate.o src/version_$(VER_HASH).o
$(CXX) $(CXXFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)

These variables are based on git revision.   So I can not hard code them.
This is the error that I get.

/bin/sh: 1: sum: not found

I have tried adding busybox & coreutils to DEPENDS 
Thanks 
Best Regards,

Edward Vidal Jr. e-mail develone@... 915-595-1613


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 301 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-security][PATCH] meta-integrity/../systemd: fix pollution issue

Armin Kuster
 



On 12/23/19 10:18 AM, Anders Montonen wrote:
Hi,

These look like typos:

thanks.

will fix and send v2

- armin

On 23 Dec 2019, at 19:18, Armpit <akuster808@...> wrote:
only include changes of systemd is enabled.
of -> if

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-integrity/recipes-core/systemd/systemd_%.bbappend | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-integrity/recipes-core/systemd/systemd_%.bbappend b/meta-integrity/recipes-core/systemd/systemd_%.bbappend
index 3b45541..f33e563 100644
--- a/meta-integrity/recipes-core/systemd/systemd_%.bbappend
+++ b/meta-integrity/recipes-core/systemd/systemd_%.bbappend
@@ -1,11 +1,11 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+FILESEXTRAPATHS_prepend_ima := "${THISDIR}/files:"

-SRC_URI += " \
+SRC_URI_iam += “ \
iam -> ima

    file://machine-id-commit-sync.conf \
    file://random-seed-sync.conf \
"

-do_install_append () {
+do_install_append_iam () {
iam -> ima

    for i in machine-id-commit random-seed; do
        install -d ${D}/${systemd_system_unitdir}/systemd-$i.service.d
        install -m 0644 ${WORKDIR}/$i-sync.conf ${D}/${systemd_system_unitdir}/systemd-$i.service.d
-- 
2.17.1
Regards,
Anders

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47810): https://lists.yoctoproject.org/g/yocto/message/47810
Mute This Topic: https://lists.yoctoproject.org/mt/69235591/1024635
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [akuster@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [meta-security][PATCH] meta-integrity/../systemd: fix pollution issue

Anders Montonen
 

Hi,

These look like typos:

On 23 Dec 2019, at 19:18, Armpit <akuster808@...> wrote:

only include changes of systemd is enabled.
of -> if


Signed-off-by: Armin Kuster <akuster808@...>
---
meta-integrity/recipes-core/systemd/systemd_%.bbappend | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-integrity/recipes-core/systemd/systemd_%.bbappend b/meta-integrity/recipes-core/systemd/systemd_%.bbappend
index 3b45541..f33e563 100644
--- a/meta-integrity/recipes-core/systemd/systemd_%.bbappend
+++ b/meta-integrity/recipes-core/systemd/systemd_%.bbappend
@@ -1,11 +1,11 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+FILESEXTRAPATHS_prepend_ima := "${THISDIR}/files:"

-SRC_URI += " \
+SRC_URI_iam += “ \
iam -> ima

file://machine-id-commit-sync.conf \
file://random-seed-sync.conf \
"

-do_install_append () {
+do_install_append_iam () {
iam -> ima

for i in machine-id-commit random-seed; do
install -d ${D}/${systemd_system_unitdir}/systemd-$i.service.d
install -m 0644 ${WORKDIR}/$i-sync.conf ${D}/${systemd_system_unitdir}/systemd-$i.service.d
--
2.17.1
Regards,
Anders


[meta-security][PATCH] meta-integrity/../systemd: fix pollution issue

Armin Kuster
 

only include changes of systemd is enabled.

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-integrity/recipes-core/systemd/systemd_%.bbappend | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-integrity/recipes-core/systemd/systemd_%.bbappend b/meta-integrity/recipes-core/systemd/systemd_%.bbappend
index 3b45541..f33e563 100644
--- a/meta-integrity/recipes-core/systemd/systemd_%.bbappend
+++ b/meta-integrity/recipes-core/systemd/systemd_%.bbappend
@@ -1,11 +1,11 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+FILESEXTRAPATHS_prepend_ima := "${THISDIR}/files:"

-SRC_URI += " \
+SRC_URI_iam += " \
file://machine-id-commit-sync.conf \
file://random-seed-sync.conf \
"

-do_install_append () {
+do_install_append_iam () {
for i in machine-id-commit random-seed; do
install -d ${D}/${systemd_system_unitdir}/systemd-$i.service.d
install -m 0644 ${WORKDIR}/$i-sync.conf ${D}/${systemd_system_unitdir}/systemd-$i.service.d
--
2.17.1


Re: installing and rolling back packages in yocto at runtime

Ross Burton <ross.burton@...>
 

On 23/12/2019 14:38, learning yocto wrote:
Is it possible to ftp the image to the board and then do something
like dpkg -i, this would help in deinstall as well?
Yes. By default rpm/smart is used, but you can use apt/dpkg or opkg if you prefer.

You can either copy packages onto the target and use the tool to install directly (dpkg -i for example), or use a HTTP daemon to share your tmp/deploy/deb folder and set PACKAGE_FEED_URIS to configure the feed in your images.

Ross


installing and rolling back packages in yocto at runtime

learning yocto
 

Hi List,

This must be a trivial thing, since am a newbie and couldnt find
googling the same in the archive, please pardon my ignorance.

I have created a thin rootfs using yocto which works well on my board.
Suppose now I have to add a package, I can add using
IMAGE_INSTALL_append but that would create a new image.
I dont want to upload a complete image, it seems like an overkill.

Is it possible to ftp the image to the board and then do something
like dpkg -i, this would help in deinstall as well?

thanks


Setting DEBUG_BUILD in local.conf

Fred Baksik
 

Why does setting something like 'PREFERRED_VERSION_u-boot-imx = "2013-04"' in local.conf work to pick the correct version of a recipe,
but setting 'DEBUG_BUILD_kmscube' doesn't enable DEBUG_BUILD in the kmscube recipe? I can't find any examples other than creating a bbappend for the recipe itself.

9561 - 9580 of 57384