Date   

Layer list's certificate expired

Andreas Müller
 

Hi,

On opening OE-layers browsers complain that certificate has expired
yesterday 13.th of May. Just wanted to let you know.

Cheers,

Andreas


Yocto Technical Team Minutes, Engineering Sync, for May 11, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for May 11, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Armin Kuster, Scott Murray, Joshua Watt,
Randy MacLeod, Bruce Ashfield, Tony Tascioglu (WR intern), Trevor Gamblin,
Steve Sakoman, Alexander Belloni, Michael Halstead, Paul Barker, Ross
Burton, Tim Orling, Saul Wold, Jere Viikari, Alejandro H

== notes ==
- 3.2.4 in QA, out in a couple days (this will be the final 3.2 release,
aka gatesgarth)
- significant patches going into master, lots of version updates (thanks
AlexK)
- multiconfig changes in bitbake cause challenges
- some CVEs showed up that could use help
- smp for various qemu machines added/enabled
- should we consider a different default qemu emulation (for arm?)
- serial IRQ handling issues with qemu-ppc
- gnome switched from gtk to ??

== general ==
AlexB: I’ve been looking into some of the intermittent AB issues, i believe
a couple of them can be closed now. there appear to be a lot of duplicates
(same issue, different manifestations)
Randy: good to hear, how many issues?
AlexB: we can look at them in the bug triage meeting. i’m guessing it’s
getting better. there are very few that happen regularly, and many others
happen only once. maybe 4 or 5 race conditions that are infrequent. the
improtant ones are qemu not working properly and the io load issue(s).
i’d like to get some graphs to visualize. there are issues related to
running out of memory, so maybe the solution is to not run so many things
at once
Randy: we used to use top to analyse what’s going on, but it’s tedious.
instead we can look at the tail of the cooker log that gives more
information, but is missing the total view of what’s going on at a given
time slice. we need a list of bitbake tasks and where to find their cooker
logs. once we have that the next step is to figure out who is doing all
the I/O. we’ve been looking at a tool called iotop, but i don’t think
that’s what we want.
RP: iotop is probably what we want, but requires root priv


RP: x86 cpu machine arguments in qemu
RP: i think all these RCU stalls we’re seeing is due to the cpu emulation
we’re using (which is very old) when we enabled SMP it caused everything
to fall over the edge and fail everywhere. maybe the qemu process is
locked up, rather than the system being overloaded
Randy: interesting theory
RP: i have a patch in master-next to upgrade to ivy-bridge qemu emulation. i
guess we’ll see what happens
AlexB: i don’t think it’ll solve all issues. we’ve seen RCU stalls on
other qemu machines, not just x86 (mips, arm64, arm)
RP: i thought it was just x86
AlexB: i have the list, i can confirm that we’ve seen rcu stalls on qemuarm
at least
RP: maybe there’s a pattern where the logs stop, then we get the rcu stall
kicking in. it could be we have 2 issues which are interfering with each
other. i’m not ready to give up on the theory yet
AlexB: it’s probably still useful to do regardless
RP: yes, i think we need to do it anyway. it won’t solve the ptest failures
on qemuarm, for example, but might help with others
Ross: the qemu person i talked with said that on a heavily loaded
system you'd expect some level of rcu stalls
RP: but should rcu stalls take out qemu?
Bruce: it should recover
AlexB: i’m not sure that’s a kernel thing that would kill it
JPEW: is it possible that because there’s too many rcu stalls that we end up
running out of memory
Bruce: we could turn rcu off and see if it recovers
RP: we should check if it recovers, or if it’s hanging. there might be 2
patterns here. this morning there was a lockup but there was no stack
trace
JPEW: is there a way to force the kernel to process all rcu’s?
??: i think that’s what it’s doing
AlexB: it’s the rcu stall detection. the cpu has been stalled for too long.
it’s not an issue with rcu itself, it’s just that rcu is what’s
noticed that the cpu has stopped responding
Randy: so ideally it would be nice to detect this ourselves and shed load
before the stalls happen
JPEW: tweak stall detection time?
??: takes about 80 seconds
AlexB: 20 seconds i think
JPEW: 21 seconds, according to docs. looks like it can be set on kernel
cmdline
Randy: heavily loaded system for cpu and io, tweaking the params isn’t going
to fix the issue
RP: it might help guide the debugging, might get more info turning on smp


Randy: been talking with TrevorG about job server. might get started next week


Randy: Saul are you getting back to qemu machine protocol
Saul: looking at it
Randy: how do you test it
Saul: don’t have a strong hold on it yet
RP: there is a hanging qemu on the AB, and it should have had the qmp patches
applied. so in theory there’s one there that we might be able to
interrogate
Saul: could you point me at it again?
RP: qemu-x86-64 on the AB, it should still be running


TW: topic ideas for OEDVM
PaulB: is there a way to just join the developer’s meeting without attending
the whole conference?


Armin: lgtm.com bitbake/yp is listed there. i sent in some patches to improve
the metrics
Armin: see https://lgtm.com/projects/g/openembedded/bitbake?mode=list
Armin: 31 errors, 80 warnings, 234 recommendations (currently)
ScottM: maybe we could do a checkpatch type thing for python linting
Armin: there is an integration with github, but requires corporate github
AlexB: should we open newcomer bugs?
Armin: we could, it tells you exactly where the problem is and what to do
ScottM: we don’t have tests, so fixes could end up breaking more things
AlexB: maybe we need test cases for bitbake/toaster/etc


Randy: our build quality is amazing! currently 0.2% build failures (mostly
running out of memory)


Re: Yocto with xtensa

Khem Raj
 

On 5/12/21 11:45 PM, Jack Daniels wrote:
Hello Khem,
Thank you for the information.
Is it about adding support for the xtensa build system (toolchain)? Is it work for heterogeneous SoC (CPU/ARM + DSP/xtensa) as well?
I can think of few ways

build your Xtensa firmware outside yocto and let yocto package it via recipes for prebuilts and build ARM system with yocto should work well

second option is to integrate Xtensa support into OE and then use multiconfig feature to build firmware for heterogenous systems.
this will be preferred and forward looking for future but it will be
more work

Thank you.
BR/J
On Thu, May 13, 2021 at 1:07 AM Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
Hello Jack,
I think we do not have support for Xtensa architecture working out of
box upstream. Although it should be possible to add it with little
effort, but no one has spun patches to do so
thus far.
Thanks
-Khem
On Wed, May 12, 2021 at 1:29 PM Jack Daniels <onyx22574@gmail.com
<mailto:onyx22574@gmail.com>> wrote:
>
> Dears,
>
> I am looking for a way to include sample code for DSP (xtensa)
with Yocto/Linux. what would be the procedure to include such a code
and eventually interprocessor communication between xtensa core and
CPU under Yocto/Linux?
>
> Thank you.
> BR/J
>
>
>


Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot

Andrei Gherzan
 

Hi Ross,

On Thu, 13 May 2021, at 13:37, Andrei Gherzan wrote:
Hi,

On Thu, 13 May 2021, at 13:14, Ross Burton wrote:
> Debugged, the patch is broken.

> Using a little tool I have:

> Task qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot failed
> Active tasks are:
>  virglrenderer-native-0.9.1-r0:do_rm_work
>  binutils-cross-arm-2.36.1-r0:do_patch
>  qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot
>  qemu-system-native-5.2.0-r0:do_rm_work
>  libepoxy-native-1.5.5-r0:do_rm_work
>  gcc-source-11.1.0-11.1.0-r0:do_unpack

> Note how qemu is simultaneously adding itself to the sysroot, whilst
> rm_work is running and deleting the sysroot.

> This patch isn't compatible with rm_work and should be reverted.


I'll look into it.



-- 
Andrei Gherzan 
gpg: rsa4096/D4D94F67AD0E9640


[meta-zephyr][PATCH 2/2] zephyr-qemuboot.bbclass: Remove dependency on qemu-system-native

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

runqemu only really needs the sysroot for qemu-helper-native. Pulling
other qemu dependency would get into a racing issue with rm_work. That
can also be fixed by tweaking the do_addto_recipe_sysroot order in
oe-core for qemu-system-native but that is just not needed for this
specific dependency requirement.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyr-qemuboot.bbclass | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index f508b45..c268e9e 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -36,19 +36,18 @@ python do_bootconf_write() {

addtask do_bootconf_write before do_build after do_deploy

-# The runqemu script requires the native sysroot populated for the qemu
-# recipes. Usually, this is pulled in by a do_image dependency (see
-# baremetal-helloworld_git, for example), but in this case, there is no such
-# task, so we hook in the dependency to do_bootconf_write. This also ensures
-# that builds from sstate will also have this requirement satisfied.
+# The runqemu script requires the native sysroot populated for the
+# qemu-helper-native recipes. Usually, this is pulled in by a do_image
+# dependency (see baremetal-helloworld_git, for example), but in this case,
+# there is no such task, so we hook in the dependency to do_bootconf_write.
+# This also ensures that builds from sstate will also have this requirement
+# satisfied.
python () {
- # do_addto_recipe_sysroot doesnt exist for all recipes, but we need it to have
- # /usr/bin on recipe-sysroot (qemu) populated
def extraimage_getdepends(task):
deps = ""
for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
# Make sure we only add it for qemu
- if 'qemu' in dep:
+ if 'qemu-helper-native' in dep:
deps += " %s:%s" % (dep, task)
return deps
d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot'))
--
2.31.1


[meta-zephyr][PATCH 1/2] zephyr-qemuboot.bbclass: Don't overwrite the entire elf dictionary key

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

The nios2_machdata_setfunc was overwriting the elf key in matchdata for
arc done in arc_machdata_setfunc which in turn was overwriting the one
from oe-core. This is making qemu-x86 builds (as an example)
unbuildable:

Exception: KeyError: 'i586'

This patch makes sure that the changes complement the machdata
dictionary as opposed to overwriting the entire "elf" key.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/siteinfo-zephyr.bbclass | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/classes/siteinfo-zephyr.bbclass b/classes/siteinfo-zephyr.bbclass
index d84fd3a..b84a9b2 100644
--- a/classes/siteinfo-zephyr.bbclass
+++ b/classes/siteinfo-zephyr.bbclass
@@ -1,4 +1,3 @@
-
def arc_siteinfo_setfunc(archinfo, osinfo, targetinfo, d):
archinfo['arc'] = "endian-little bit-32 "
osinfo['linux'] = "common-linux common-glibc"
@@ -8,7 +7,7 @@ def arc_siteinfo_setfunc(archinfo, osinfo, targetinfo, d):
SITEINFO_EXTRA_DATAFUNCS += "arc_siteinfo_setfunc"

def arc_machdata_setfunc(machdata, d):
- machdata["elf"] = { "arc" : (195, 0, 0, True, 32), }
+ machdata["elf"]["arc"] = (195, 0, 0, True, 32)
return machdata

PACKAGEQA_EXTRA_MACHDEFFUNCS += "arc_machdata_setfunc"
@@ -22,7 +21,7 @@ def iamcu_siteinfo_setfunc(archinfo, osinfo, targetinfo, d):
SITEINFO_EXTRA_DATAFUNCS += "iamcu_siteinfo_setfunc"

def nios2_machdata_setfunc(machdata, d):
- machdata["elf"] = {"nios2": (113, 0, 0, True, 32), }
+ machdata["elf"]["nios2"] = (113, 0, 0, True, 32)
return machdata

-PACKAGEQA_EXTRA_MACHDEFFUNCS += "nios2_machdata_setfunc"
\ No newline at end of file
+PACKAGEQA_EXTRA_MACHDEFFUNCS += "nios2_machdata_setfunc"
--
2.31.1


Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot

Andrei Gherzan
 

Hi,

On Thu, 13 May 2021, at 13:14, Ross Burton wrote:
Debugged, the patch is broken.

Using a little tool I have:

Task qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot failed
Active tasks are:
virglrenderer-native-0.9.1-r0:do_rm_work
binutils-cross-arm-2.36.1-r0:do_patch
qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot
qemu-system-native-5.2.0-r0:do_rm_work
libepoxy-native-1.5.5-r0:do_rm_work
gcc-source-11.1.0-11.1.0-r0:do_unpack

Note how qemu is simultaneously adding itself to the sysroot, whilst
rm_work is running and deleting the sysroot.

This patch isn't compatible with rm_work and should be reverted.
I'll look into it.

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640


Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot

Ross Burton <ross@...>
 

Debugged, the patch is broken.

Using a little tool I have:

Task qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot failed
Active tasks are:
virglrenderer-native-0.9.1-r0:do_rm_work
binutils-cross-arm-2.36.1-r0:do_patch
qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot
qemu-system-native-5.2.0-r0:do_rm_work
libepoxy-native-1.5.5-r0:do_rm_work
gcc-source-11.1.0-11.1.0-r0:do_unpack

Note how qemu is simultaneously adding itself to the sysroot, whilst
rm_work is running and deleting the sysroot.

This patch isn't compatible with rm_work and should be reverted.

Ross

On Thu, 13 May 2021 at 13:06, Ross Burton <ross@burtonini.com> wrote:

This is breaking our CI:

ERROR: qemu-system-native-5.2.0-r0 do_addto_recipe_sysroot: Error
executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/builds/yocto-poc/meta-arm/work/poky/meta/classes/staging.bbclass',
lineno: 502, function: extend_recipe_sysroot
0498: continue
0499:
0500: msg_adding.append(c)
0501:
*** 0502: os.symlink(c + "." + taskhash, depdir + "/" + c)
0503:
0504: manifest, d2 = oe.sstatesig.find_sstate_manifest(c,
setscenedeps[dep][2], "populate_sysroot", d, multilibs)
0505: if d2 is not d:
0506: # If we don't do this, the recipe sysroot will
be placed in the wrong WORKDIR for multilibs
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'zlib-native.0f0b3e4d16f9ad46dd8609d8c899a834104f5b572a4a5438ccccd1db88d67e97'
-> '/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/recipe-sysroot-native/installeddeps/zlib-native'
ERROR: Logfile of failure stored in:
/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/temp/log.do_addto_recipe_sysroot.7593
ERROR: Task (/builds/yocto-poc/meta-arm/work/poky/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb:do_addto_recipe_sysroot)
failed with exit code '1'
ERROR: qemu-system-native-5.2.0-r0 do_rm_work: Execution of
'/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/temp/run.do_rm_work.7583'
failed with exit code 1:
rm: cannot remove 'recipe-sysroot-native': Directory not empty

Can this be reverted whilst this is debugged?

Ross

On Fri, 7 May 2021 at 11:09, Andrei Gherzan <andrei@gherzan.com> wrote:

From: Andrei Gherzan <andrei.gherzan@huawei.com>

The runqemu script depends on having the native sysroot populated for
the qemu recipes. Add the required dependency to the mix.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyr-qemuboot.bbclass | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index 5ac1c86..f508b45 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -35,3 +35,22 @@ python do_bootconf_write() {
}

addtask do_bootconf_write before do_build after do_deploy
+
+# The runqemu script requires the native sysroot populated for the qemu
+# recipes. Usually, this is pulled in by a do_image dependency (see
+# baremetal-helloworld_git, for example), but in this case, there is no such
+# task, so we hook in the dependency to do_bootconf_write. This also ensures
+# that builds from sstate will also have this requirement satisfied.
+python () {
+ # do_addto_recipe_sysroot doesnt exist for all recipes, but we need it to have
+ # /usr/bin on recipe-sysroot (qemu) populated
+ def extraimage_getdepends(task):
+ deps = ""
+ for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
+ # Make sure we only add it for qemu
+ if 'qemu' in dep:
+ deps += " %s:%s" % (dep, task)
+ return deps
+ d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot'))
+ d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot'))
+}
--
2.31.1




Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot

Ross Burton <ross@...>
 

This is breaking our CI:

ERROR: qemu-system-native-5.2.0-r0 do_addto_recipe_sysroot: Error
executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/builds/yocto-poc/meta-arm/work/poky/meta/classes/staging.bbclass',
lineno: 502, function: extend_recipe_sysroot
0498: continue
0499:
0500: msg_adding.append(c)
0501:
*** 0502: os.symlink(c + "." + taskhash, depdir + "/" + c)
0503:
0504: manifest, d2 = oe.sstatesig.find_sstate_manifest(c,
setscenedeps[dep][2], "populate_sysroot", d, multilibs)
0505: if d2 is not d:
0506: # If we don't do this, the recipe sysroot will
be placed in the wrong WORKDIR for multilibs
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'zlib-native.0f0b3e4d16f9ad46dd8609d8c899a834104f5b572a4a5438ccccd1db88d67e97'
-> '/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/recipe-sysroot-native/installeddeps/zlib-native'
ERROR: Logfile of failure stored in:
/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/temp/log.do_addto_recipe_sysroot.7593
ERROR: Task (/builds/yocto-poc/meta-arm/work/poky/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb:do_addto_recipe_sysroot)
failed with exit code '1'
ERROR: qemu-system-native-5.2.0-r0 do_rm_work: Execution of
'/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/temp/run.do_rm_work.7583'
failed with exit code 1:
rm: cannot remove 'recipe-sysroot-native': Directory not empty

Can this be reverted whilst this is debugged?

Ross

On Fri, 7 May 2021 at 11:09, Andrei Gherzan <andrei@gherzan.com> wrote:

From: Andrei Gherzan <andrei.gherzan@huawei.com>

The runqemu script depends on having the native sysroot populated for
the qemu recipes. Add the required dependency to the mix.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyr-qemuboot.bbclass | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index 5ac1c86..f508b45 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -35,3 +35,22 @@ python do_bootconf_write() {
}

addtask do_bootconf_write before do_build after do_deploy
+
+# The runqemu script requires the native sysroot populated for the qemu
+# recipes. Usually, this is pulled in by a do_image dependency (see
+# baremetal-helloworld_git, for example), but in this case, there is no such
+# task, so we hook in the dependency to do_bootconf_write. This also ensures
+# that builds from sstate will also have this requirement satisfied.
+python () {
+ # do_addto_recipe_sysroot doesnt exist for all recipes, but we need it to have
+ # /usr/bin on recipe-sysroot (qemu) populated
+ def extraimage_getdepends(task):
+ deps = ""
+ for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
+ # Make sure we only add it for qemu
+ if 'qemu' in dep:
+ deps += " %s:%s" % (dep, task)
+ return deps
+ d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot'))
+ d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot'))
+}
--
2.31.1




Re: Yocto with xtensa

Jack Daniels <onyx22574@...>
 

Hello Khem,

Thank you for the information. 
Is it about adding support for the xtensa build system (toolchain)? Is it work for heterogeneous SoC (CPU/ARM + DSP/xtensa) as well?

Thank you.
BR/J

On Thu, May 13, 2021 at 1:07 AM Khem Raj <raj.khem@...> wrote:
Hello Jack,

I think we do not have support for Xtensa architecture working out of
box upstream. Although it should be possible to add it with little
effort, but no one has spun patches to do so
thus far.

Thanks
-Khem

On Wed, May 12, 2021 at 1:29 PM Jack Daniels <onyx22574@...> wrote:
>
> Dears,
>
> I am looking for a way to include sample code for DSP (xtensa) with Yocto/Linux. what would be the procedure to include such a code and eventually interprocessor communication between xtensa core and CPU under Yocto/Linux?
>
> Thank you.
> BR/J
>
>
>
>


Re: Yocto Zeus : facing error regarding hostapd #zeus

Zoran
 

Hello Rohit,

It is a good find. I also googled for the error, and found this as an
explanation:
https://www.yoctoproject.org/pipermail/yocto/2019-February/044153.html

I included Alex (Kanavin), who created the above mail.

Maybe Alex can give more light on the problem?

In the meantime, you should explore (by similarities) this pointer in
very details:
https://github.com/Xilinx/meta-virtualization/issues/4#issuecomment-590532621

Zoran
_______

On Thu, May 13, 2021 at 8:25 AM rohit jadhav <rohitbjadhav1@gmail.com> wrote:

Hi Zoran,
log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls command, So both files are identical.

While surfing I found similar thread but its for different package its as follows :
https://github.com/Xilinx/meta-virtualization/issues/4

Can you please help out with this for our Package Hostapd ?

Thanks and Regards
Rohit

On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

From the log log.do_rootfs.31340 file, there are the following:

[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.

HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from:
https://en.wikipedia.org/wiki/Hostapd

It is kind of a hot spot, as my best understanding is.

[2] Details of the failure are in
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.

So, my best guess, looking into log.do_rootfs will tell us much more.

Please, attach this one for our review as well.

Thank you,
Zoran
_______

On Wed, May 12, 2021 at 5:29 PM rohit jadhav <rohitbjadhav1@gmail.com> wrote:

Hi Zoran ,
I have attached the log file for your reference.
Thank You
Regards
Rohit

On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

Log file in:
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
log.do_rootfs.31340

Could you, please, attach a log file?

Thank you,
Zoran
_______


On Wed, May 12, 2021 at 2:01 PM rohit jadhav <rohitbjadhav1@gmail.com> wrote:

Facing following issue :
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: Logfile of failure stored in: /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
ERROR: Task (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'

Please guide me if anyone have any idea to resolve.

Thanks in advance.


Re: Yocto Zeus : facing error regarding hostapd #zeus

rohit jadhav
 

Hi Zoran,
   log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls command, So both files are identical.

While surfing I found similar thread but its for different package  its as follows :

Can you please help out with this for our Package Hostapd ?

Thanks and Regards
Rohit


On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
From the log log.do_rootfs.31340 file, there are the following:

[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.

HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from:
https://en.wikipedia.org/wiki/Hostapd

It is kind of a hot spot, as my best understanding is.

[2] Details of the failure are in
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.

So, my best guess, looking into log.do_rootfs will tell us much more.

Please, attach this one for our review as well.

Thank you,
Zoran
_______

On Wed, May 12, 2021 at 5:29 PM rohit jadhav <rohitbjadhav1@...> wrote:
>
> Hi Zoran ,
> I have attached the log file for your reference.
> Thank You
> Regards
> Rohit
>
> On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
>>
>> > Log file in:
>> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
>> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
>> log.do_rootfs.31340
>>
>> Could you, please, attach a log file?
>>
>> Thank you,
>> Zoran
>> _______
>>
>>
>> On Wed, May 12, 2021 at 2:01 PM rohit jadhav <rohitbjadhav1@...> wrote:
>>>
>>> Facing following issue :
>>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot,
>>> then please place them into pkg_postinst_ontarget_${PN} ().
>>> Deferring to first boot via 'exit 1' is no longer supported.
>>> Details of the failure are in /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>>> ERROR: Logfile of failure stored in: /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
>>> ERROR: Task (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'
>>>
>>> Please guide me if anyone have any idea to resolve.
>>>
>>> Thanks in advance.
>>>
>>>


Re: [meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type

Changqing Li
 

On 5/13/21 11:48 AM, Khem Raj wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]

On 5/12/21 8:42 PM, Changqing Li wrote:
From: Changqing Li <changqing.li@windriver.com>

fix below error:
/etc/udev/rules.d/99-com.rules:10 Invalid value "/bin/sh -c
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0
$ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0
$ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58:
invalid substitution type)
Can you create a pull request on github for this please.
ok

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
  recipes-core/udev/udev-rules-rpi/99-com.rules | 8 ++++----
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-core/udev/udev-rules-rpi/99-com.rules b/recipes-core/udev/udev-rules-rpi/99-com.rules
index 6bf019b..ddd1e17 100644
--- a/recipes-core/udev/udev-rules-rpi/99-com.rules
+++ b/recipes-core/udev/udev-rules-rpi/99-com.rules
@@ -1,8 +1,8 @@
  KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
      ALIASES=/proc/device-tree/aliases; \
-     if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
+     if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
              echo 0;\
-     elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
+     elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
              echo 1; \
      else \
              exit 1; \
@@ -11,9 +11,9 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\

  KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
      ALIASES=/proc/device-tree/aliases; \
-     if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
+     if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \
              echo 0; \
-     elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
+     elif cmp -s $$ALIASES/uart1 $$ALIASES/serial1; then \
              echo 1; \
      else \
              exit 1; \




Re: Yocto Zeus : facing error regarding hostapd #zeus

Zoran
 

From the log log.do_rootfs.31340 file, there are the following:

[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.

HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from:
https://en.wikipedia.org/wiki/Hostapd

It is kind of a hot spot, as my best understanding is.

[2] Details of the failure are in
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.

So, my best guess, looking into log.do_rootfs will tell us much more.

Please, attach this one for our review as well.

Thank you,
Zoran
_______

On Wed, May 12, 2021 at 5:29 PM rohit jadhav <rohitbjadhav1@gmail.com> wrote:

Hi Zoran ,
I have attached the log file for your reference.
Thank You
Regards
Rohit

On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

Log file in:
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
log.do_rootfs.31340

Could you, please, attach a log file?

Thank you,
Zoran
_______


On Wed, May 12, 2021 at 2:01 PM rohit jadhav <rohitbjadhav1@gmail.com> wrote:

Facing following issue :
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: Logfile of failure stored in: /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
ERROR: Task (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'

Please guide me if anyone have any idea to resolve.

Thanks in advance.


Re: [meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type

Khem Raj
 

On 5/12/21 8:42 PM, Changqing Li wrote:
From: Changqing Li <changqing.li@windriver.com>
fix below error:
/etc/udev/rules.d/99-com.rules:10 Invalid value "/bin/sh -c
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0
$ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0
$ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58:
invalid substitution type)
Can you create a pull request on github for this please.

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
recipes-core/udev/udev-rules-rpi/99-com.rules | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/recipes-core/udev/udev-rules-rpi/99-com.rules b/recipes-core/udev/udev-rules-rpi/99-com.rules
index 6bf019b..ddd1e17 100644
--- a/recipes-core/udev/udev-rules-rpi/99-com.rules
+++ b/recipes-core/udev/udev-rules-rpi/99-com.rules
@@ -1,8 +1,8 @@
KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
- if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
+ if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
echo 0;\
- elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
+ elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \
@@ -11,9 +11,9 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
- if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
+ if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \
echo 0; \
- elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
+ elif cmp -s $$ALIASES/uart1 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \


[meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type

Changqing Li
 

From: Changqing Li <changqing.li@windriver.com>

fix below error:
/etc/udev/rules.d/99-com.rules:10 Invalid value "/bin/sh -c
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0
$ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0
$ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58:
invalid substitution type)

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
recipes-core/udev/udev-rules-rpi/99-com.rules | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-core/udev/udev-rules-rpi/99-com.rules b/recipes-core/udev/udev-rules-rpi/99-com.rules
index 6bf019b..ddd1e17 100644
--- a/recipes-core/udev/udev-rules-rpi/99-com.rules
+++ b/recipes-core/udev/udev-rules-rpi/99-com.rules
@@ -1,8 +1,8 @@
KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
- if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
+ if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
echo 0;\
- elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
+ elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \
@@ -11,9 +11,9 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
- if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
+ if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \
echo 0; \
- elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
+ elif cmp -s $$ALIASES/uart1 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \
--
2.17.1


[meta-security][PATCH 6/6] packagegroup-core-security: add aide and ossec

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 54b8297..0bddf64 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -70,6 +70,8 @@ SUMMARY_packagegroup-security-ids = "Security Intrusion Detection systems"
RDEPENDS_packagegroup-security-ids = " \
samhain-standalone \
${@bb.utils.contains_any("TUNE_FEATURES", "ppc7400 riscv32 riscv64", "", " suricata",d)} \
+ ossec-hids \
+ aide \
"

SUMMARY_packagegroup-security-mac = "Security Mandatory Access Control systems"
--
2.25.1


[meta-security][PATCH 5/6] aide: Add another ids

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-ids/aide/aide/aide.conf | 94 +++++++++++++++++++++++++++++++++
recipes-ids/aide/aide_0.17.3.bb | 41 ++++++++++++++
2 files changed, 135 insertions(+)
create mode 100644 recipes-ids/aide/aide/aide.conf
create mode 100644 recipes-ids/aide/aide_0.17.3.bb

diff --git a/recipes-ids/aide/aide/aide.conf b/recipes-ids/aide/aide/aide.conf
new file mode 100644
index 0000000..2c99e07
--- /dev/null
+++ b/recipes-ids/aide/aide/aide.conf
@@ -0,0 +1,94 @@
+# Example configuration file for AIDE.
+
+@@define DBDIR /usr/lib/aide
+@@define LOGDIR /usr/lib/aide/logs
+
+# The location of the database to be read.
+database_in=file:@@{DBDIR}/aide.db.gz
+
+# The location of the database to be written.
+#database_out=sql:host:port:database:login_name:passwd:table
+#database_out=file:aide.db.new
+database_out=file:@@{DBDIR}/aide.db.gz
+
+# Whether to gzip the output to database
+gzip_dbout=yes
+
+# Default.
+log_level=warning
+
+report_url=file:@@{LOGDIR}/aide.log
+report_url=stdout
+#report_url=stderr
+#NOT IMPLEMENTED report_url=mailto:root@foo.com
+#NOT IMPLEMENTED report_url=syslog:LOG_AUTH
+
+# These are the default rules.
+#
+#p: permissions
+#i: inode:
+#n: number of links
+#u: user
+#g: group
+#s: size
+#b: block count
+#m: mtime
+#a: atime
+#c: ctime
+#S: check for growing size
+#acl: Access Control Lists
+#selinux SELinux security context
+#xattrs: Extended file attributes
+#md5: md5 checksum
+#sha1: sha1 checksum
+#sha256: sha256 checksum
+#sha512: sha512 checksum
+#rmd160: rmd160 checksum
+#tiger: tiger checksum
+
+#haval: haval checksum (MHASH only)
+#gost: gost checksum (MHASH only)
+#crc32: crc32 checksum (MHASH only)
+#whirlpool: whirlpool checksum (MHASH only)
+
+FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
+
+#R: p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5
+#L: p+i+n+u+g+acl+selinux+xattrs
+#E: Empty group
+#>: Growing logfile p+u+g+i+n+S+acl+selinux+xattrs
+
+# You can create custom rules like this.
+# With MHASH...
+# ALLXTRAHASHES = sha1+rmd160+sha256+sha512+whirlpool+tiger+haval+gost+crc32
+ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger
+# Everything but access time (Ie. all changes)
+EVERYTHING = R+ALLXTRAHASHES
+
+# Sane, with multiple hashes
+# NORMAL = R+rmd160+sha256+whirlpool
+NORMAL = FIPSR+sha512
+
+# For directories, don't bother doing hashes
+DIR = p+i+n+u+g+acl+selinux+xattrs
+
+# Access control only
+PERMS = p+i+u+g+acl+selinux
+
+# Logfile are special, in that they often change
+LOG = >
+
+# Just do sha256 and sha512 hashes
+LSPP = FIPSR+sha512
+
+# Some files get updated automatically, so the inode/ctime/mtime change
+# but we want to know when the data inside them changes
+DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha256
+
+# Next decide what directories/files you want in the database.
+
+# Check only permissions, inode, user and group for /etc, but
+# cover some important files closely.
+/bin NORMAL
+/sbin NORMAL
+/lib NORMAL
diff --git a/recipes-ids/aide/aide_0.17.3.bb b/recipes-ids/aide/aide_0.17.3.bb
new file mode 100644
index 0000000..522cd85
--- /dev/null
+++ b/recipes-ids/aide/aide_0.17.3.bb
@@ -0,0 +1,41 @@
+SUMMARY = "Advanced Intrusion Detection Environment"
+HOMEPAGE = "https://aide.github.io"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+LICENSE = "GPL-2.0"
+
+DEPENDS = "bison-native libpcre"
+
+SRC_URI = "https://github.com/aide/aide/releases/download/v${PV}/${BPN}-${PV}.tar.gz \
+ file://aide.conf"
+
+SRC_URI[sha256sum] = "a2eb1883cafaad056fbe43ee1e8ae09fd36caa30a0bc8edfea5d47bd67c464f8"
+
+inherit autotools pkgconfig
+
+PACKAGECONFIG ??=" mhash zlib e2fsattrs \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux audit', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'xattr', '', d)} \
+ "
+PACKAGECONFIG[selinux] = "--with-selinux, --without-selinux, libselinux, libselinux"
+PACKAGECONFIG[zlib] = "--with-zlib, --without-zlib, zlib, zlib "
+PACKAGECONFIG[xattr] = "--with-xattr, --without-xattr, attr, attr"
+PACKAGECONFIG[curl] = "--with-curl, --without-curl, curl, libcurl"
+PACKAGECONFIG[audit] = "--with-audit, --without-audit,"
+PACKAGECONFIG[gcrypt] = "--with-gcrypt, --without-gcrypt, libgcrypt, libgcrypt"
+PACKAGECONFIG[mhash] = "--with-mhash, --without-mhash, libmhash, libmhash"
+PACKAGECONFIG[e2fsattrs] = "--with-e2fsattrs, --without-e2fsattrs, e2fsprogs, e2fsprogs"
+
+do_install_append () {
+ install -d ${D}${libdir}/${PN}/logs
+ install -d ${D}${sysconfdir}
+ install ${WORKDIR}/aide.conf ${D}${sysconfdir}/
+}
+
+CONF_FILE = "${sysconfdir}/aide.conf"
+
+FILES_${PN} += "${libdir}/${PN} ${sysconfdir}/aide.conf"
+
+pkg_postinst_ontarget_${PN} () {
+ /usr/bin/aide -i
+}
+RDPENDS_${PN} = "bison, libpcre"
--
2.25.1


[meta-security][PATCH 4/6] Apparmor: fix multi config build issue.

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_3.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_3.0.bb b/recipes-mac/AppArmor/apparmor_3.0.bb
index 015205d..d9c3e4d 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.bb
@@ -177,8 +177,9 @@ SYSTEMD_AUTO_ENABLE ?= "enable"

PACKAGES += "mod-${PN}"

-FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}"
+FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor ${nonarch_libdir}/${PYTHON_DIR}/site-packages"
FILES_mod-${PN} = "${libdir}/apache2/modules/*"
+FILES_${PN}-dbg += "/lib/security/"

DEPENDS_append_libc-musl = " fts "
RDEPENDS_${PN}_libc-musl += "musl-utils"
--
2.25.1


[meta-security][PATCH 3/6] packagegroup-core-security: fix typo for mips

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 6d2dd7c..54b8297 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -79,8 +79,7 @@ RDEPENDS_packagegroup-security-mac = " \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \
"

-RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor"
-RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor"
+RDEPENDS_packagegroup-security-mac_remove_mipsarch = "apparmor"

RDEPENDS_packagegroup-meta-security-ptest-packages = "\
ptest-runner \
--
2.25.1

3601 - 3620 of 57077