[yocto] tzdata overwrites existing localtime/zoneinfo?
Hi, It seems to me that the tzdata package will overwrite whatever the current time zone is with its default. This is not great if you’re upgrading the package on an existing system. Should the creation of the file and link be removed from the do_install and only be done in the pkg_postinst? Regards, Anders Montonen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using dpkg-buildpackage within Yocto image
Hello, I would like to be able to build debian packages on yocto itself. This means I would call something like this: dpkg-buildpackage -us -uc -rfakeroot This already does not work, since fakeroot does not exist in the image. It seems there was an older recipe for this but I can't find it in newer releases (sumo). If I build without -rfakeroot as root user I get a step further but then I get: dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper (>= 9) dh-systemd I unfortunately could not find the right recipes which would provide those files. Am I missing something? Thanks in advance, Fabian -- von unterwegs-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] build core-image-minimal with no bootloader
Hello! How do I build a core-image-minimal without any bootloader ? I tried adding the following lines in conf/local.conf, but without any effect IMAGE_BOOTLOADER = "" PREFERRED_PROVIDER_u-boot = "" PREFERRED_PROVIDER_virtual/bootloader = "" Thank you, Cristian Bercaru -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Working on Dependent Recipes in eSDK
> ChenQi wrote on 10/22/2018 07:04:32 PM: > > Hi Aaron, > > The main pain for now is that `devtool sdk-install ' does > not work as expected, right? > I just checked the codes of sdk-install, and found that it does not fit > the current RSS design. > I'd like to check with you if this is the major concern from your team? > Do you have some other concerns? > I'll open enhancements/bugs on bugzilla and hopefully will work on them > in the 2.7 development cycle. > > Best Regards, > Chen Qi > > ... snip ... Well, I'm not quite sure how "devtool sdk-install " relates after "devtool modify " has been called. My developers use devtool to install dependent recipes into the eSDK when they start working on something. Often they find that they need to make a change in the library code that a dependent recipe provides. In effect, they are developing a patch for the dependent recipe. So they use devtool to say they're going to modify that dependent recipe, and they go and make the changes they want. Then what? How do they get those changes, that patch, available to the eSDK? Any changes made to the library code provided by the dependent recipe are not available to the eSDK, except through devtool commands. In effect there are two different worlds at play, the eSDK sysroots versus the recipe sysroots. The devtool commands seem to make use of the recipe sysroots, but in my mind that defeats the purpose of an eSDK. So I made a plug-in for devtool were I can force the eSDK sysroots to be updated. I'm not sure how that works, but it seems to propagate the workspace (recipe sysroot land) to the eSDK, so changes that developers make are now available for use. I want my developers to use the toolchain (cmake, make, gcc, etc) provided by the eSDK and by things installed into it (devtool sdk-install), rather than having to use devtool as their iterative build command. Ultimately, I would like to be able to skip my devtool plug-in, as it requires the use of "devtool build " and "devtool sdk-sysroot" each time a dependent recipe is modified. But I am not sure how that would work, other than the devtool build command should be updating the eSDK sysroots itself. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need Help To Solve Errors while build of Yocto Project
Hi, I am not a developer but according to that manual, one of the requirements is Python 3.4 or greater. I see Python2 stuff in the attached screen shots. Someone else could probably be more definitive. That might not be the reason but you could try with Python 3. https://www.yoctoproject.org/docs/2.5.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#brief-compatible-distro Scott On Thu, Oct 25, 2018 at 8:13 AM Bhavin Dharmendrabhai Maru < bhavin.m...@vvdntech.in> wrote: > Hi Support Team, > > I am new to yocto project and start to build yocto project by the steps > provided in below link: > > https://www.yoctoproject.org/docs/2.5.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html > > I am getting errors when i give *$ bitbake core-image-sato *command. > details screenshot of errors are attached with this email for your > reference. > > Kindly help me to solve these errors. Any help in this will be appreciated. > > Thanks and Regards, > Bhavin Maru > -- > ___ > 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] [SDK] including kernel devsrc to the SDK failes
Hi, I am trying to add the kernel devsrc to the SDK but I am getting the following error Problem: conflicting requests - nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk I have applied the following patch to try and fix this problem. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2 I have verified that it was applied and run kernel-devsrc works. The error is from do_populate_sdk and I am suspecting that the problem is related to me using rpm. I believe rpm might be to smart in this case detecting the dependency and resulting dnf from failing when running the task do_populate_sdk. Any suggestion on how to get forward on this error. I would like to run dnf manually to check any dependency of the kernel-devsrc rpm package but cannot figure out how. BR Måns Zigher -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH] netfilter: Fix kmemleak false positive reports
On 2018/10/25 18:29, Bruce Ashfield wrote: > On 10/23/18 6:33 AM, zhe...@windriver.com wrote: >> From: He Zhe >> >> unreferenced object 0x9643edb89900 (size 256): >> comm "sd-resolve", pid 220, jiffies 4295016710 (age 208.256s) >> hex dump (first 32 bytes): >> 01 00 00 00 00 00 00 00 03 00 74 f3 ba b1 b6 b5 ..t. >> 65 3e 00 00 00 00 00 00 90 f9 a0 ed 43 96 ff ff e>..C... >> backtrace: >> [<70d5b185>] kmem_cache_alloc+0x146/0x200 >> [<07a27faa>] __nf_conntrack_alloc.isra.13+0x4d/0x170 >> [nf_conntrack] >> [] init_conntrack+0x6a/0x2f0 [nf_conntrack] >> [<3d38809f>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack] >> [<1fe154e3>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4] >> [<27adadb2>] nf_hook_slow+0x48/0xd0 >> [<9893511f>] __ip_local_out+0xbd/0xf0 >> [ ] ip_local_out+0x1c/0x50 >> [<995e2f37>] ip_send_skb+0x19/0x40 >> [<3d95f220>] udp_send_skb.isra.5+0x157/0x360 >> [ ] udp_sendmsg+0x9d8/0xc10 >> [<3bef56ec>] inet_sendmsg+0x3e/0xf0 >> [<8d23e405>] sock_sendmsg+0x1d/0x30 >> [<8c297097>] ___sys_sendmsg+0x108/0x2b0 >> [ ] __sys_sendmmsg+0xba/0x1c0 >> [ ] __x64_sys_sendmmsg+0x24/0x30 >> >> In __nf_conntrack_confirm, object ct can be referenced to by the stack >> variable >> ct and the members of ct->tuplehash. kmemleak needs at least one of them to >> find >> the ct object during scan. >> >> When the ct object is moved from the unconfirmed hlist to the confirmed >> hlist. >> kmemleak cannot see ct object if things happen in the following order and >> thus >> give the above false positive report. >> 1) ct object is removed from unconfirmed hlist. >> 2) kmemleak scans data/bss sections. >> 3) ct object is added to confirmed hlist and ct is destroyed as the function >> returns. >> 4) kmemleak scans task stacks. >> >> This patch marks the ct object as not a leak. > > Has this also been submitted upstream ? > > Due to travel, I haven't gotten to it yet. But if it has been submitted > upstream, I can get it merged by Monday This has been submitted to lkml but has not got any attention. Mark and I still are working on it to pinpoint the bad code. Zhe > > Bruce > >> >> Signed-off-by: He Zhe >> --- >> This is only for v4.18 >> >> net/netfilter/nf_conntrack_core.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/net/netfilter/nf_conntrack_core.c >> b/net/netfilter/nf_conntrack_core.c >> index 3d52804..9b554c7 100644 >> --- a/net/netfilter/nf_conntrack_core.c >> +++ b/net/netfilter/nf_conntrack_core.c >> @@ -35,6 +35,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> @@ -1138,6 +1139,8 @@ __nf_conntrack_alloc(struct net *net, >> if (ct == NULL) >> goto out; >> + kmemleak_not_leak(ct); >> + >> spin_lock_init(>lock); >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig; >> ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = NULL; >> > > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [yocto-docs][PATCH v2] kernel-dev: note about the change detection of kernel feature files
On 10/22/18 5:07 AM, Urs Fässler wrote: It is not the expected behavior that changes on the .cfg files only referenced from .scc files are not detected. This looks good to me. Also note that I have an outstanding bugzilla to see if I can invalidate stamps, etc, when these elements change .. so at that point, I'd be able to fixup this documentation section. Bruce Signed-off-by: Urs Fässler Signed-off-by: Pascal Bach --- documentation/kernel-dev/kernel-dev-common.xml | 4 1 file changed, 4 insertions(+) diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml index 83b02b1c1..2e421e7ba 100644 --- a/documentation/kernel-dev/kernel-dev-common.xml +++ b/documentation/kernel-dev/kernel-dev-common.xml @@ -2623,6 +2623,10 @@ .scc file in the SRC_URI statement to reference multiple kernel features. + +Bitbake only detects changes on files listed in +SRC_URI. + -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH] ipv4: net namespace does not inherit network configurations
On 10/24/18 2:27 AM, zhe...@windriver.com wrote:
From: He Zhe
patch from https://lkml.org/lkml/2014/7/29/119
Did this never make the mainline kernel ?
We either need an upstream git commit hash, or an explanation of
why it didn't make mainline. I haven't read the link you provided,
but I shouldn't have to click on anything in a commit message :D
Bruce
Ipv4 net namespace requires a similar logic change as commit a79ca223e029
[ipv6: fix bad free of addrconf_init_net] introduces for newer kernels.
Since a net namespace is independent to another. That is, there
is no any relationship between the net namespaces. So a new net
namespace should not inherit network configurations from another
net namespace including the host.
CC: Hong Zhiguo
CC: David S. Miller
Signed-off-by: Zhu Yanjun
Signed-off-by: yzhu1
Signed-off-by: He Zhe
---
This is for linux-yocto-dev, linux-yocto master and 4.18 branches.
net/ipv4/devinet.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ea4bd8a..f69b2dd 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2412,28 +2412,23 @@ static __net_init int devinet_init_net(struct net *net)
#endif
err = -ENOMEM;
- all = _devconf;
- dflt = _devconf_dflt;
+ all = kmemdup(_devconf, sizeof(ipv4_devconf), GFP_KERNEL);
+ if (all == NULL)
+ goto err_alloc_all;
- if (!net_eq(net, _net)) {
- all = kmemdup(all, sizeof(ipv4_devconf), GFP_KERNEL);
- if (!all)
- goto err_alloc_all;
-
- dflt = kmemdup(dflt, sizeof(ipv4_devconf_dflt), GFP_KERNEL);
- if (!dflt)
- goto err_alloc_dflt;
+ dflt = kmemdup(_devconf_dflt, sizeof(ipv4_devconf_dflt),
GFP_KERNEL);
+ if (dflt == NULL)
+ goto err_alloc_dflt;
#ifdef CONFIG_SYSCTL
- tbl = kmemdup(tbl, sizeof(ctl_forward_entry), GFP_KERNEL);
- if (!tbl)
- goto err_alloc_ctl;
+ tbl = kmemdup(tbl, sizeof(ctl_forward_entry), GFP_KERNEL);
+ if (tbl == NULL)
+ goto err_alloc_ctl;
- tbl[0].data = >data[IPV4_DEVCONF_FORWARDING - 1];
- tbl[0].extra1 = all;
- tbl[0].extra2 = net;
+ tbl[0].data = >data[IPV4_DEVCONF_FORWARDING - 1];
+ tbl[0].extra1 = all;
+ tbl[0].extra2 = net;
#endif
- }
#ifdef CONFIG_SYSCTL
err = __devinet_sysctl_register(net, "all", NETCONFA_IFINDEX_ALL, all);
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [yocto-4.14][PATCH] sound.cfg: enable SND_SOC_INTEL_SKYLAKE explicitly
On 10/23/18 2:28 AM, Anuj Mittal wrote: This helps kernels that might have the sound/soc kconfig changes backported to 4.14 [1]. Looks good. As I mentioned in other email, Due to travel, I haven't gotten to it yet. But it will be merged by Monday. Bruce This is selected by default by SND_SOC_INTEL_SKL_* configs in 4.14 that are enabled to be built already in sound.cfg, so this will not result in any change in behaviour. [1] https://github.com/torvalds/linux/commit/f6a118a800e35af2c63f90cbcc23093f4b53b3a2 Signed-off-by: Anuj Mittal --- cfg/sound.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/cfg/sound.cfg b/cfg/sound.cfg index e8b2a921..51568d4d 100644 --- a/cfg/sound.cfg +++ b/cfg/sound.cfg @@ -59,6 +59,7 @@ CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH=m CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH=m CONFIG_SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH=m CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH=m +CONFIG_SND_SOC_INTEL_SKYLAKE=m CONFIG_SND_SOC_AC97_CODEC=m CONFIG_SND_SOC_AK4104=m CONFIG_SND_SOC_AK4554=m -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] netfilter: Fix kmemleak false positive reports
On 10/23/18 6:33 AM, zhe...@windriver.com wrote: From: He Zhe unreferenced object 0x9643edb89900 (size 256): comm "sd-resolve", pid 220, jiffies 4295016710 (age 208.256s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 03 00 74 f3 ba b1 b6 b5 ..t. 65 3e 00 00 00 00 00 00 90 f9 a0 ed 43 96 ff ff e>..C... backtrace: [<70d5b185>] kmem_cache_alloc+0x146/0x200 [<07a27faa>] __nf_conntrack_alloc.isra.13+0x4d/0x170 [nf_conntrack] [] init_conntrack+0x6a/0x2f0 [nf_conntrack] [<3d38809f>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack] [<1fe154e3>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4] [<27adadb2>] nf_hook_slow+0x48/0xd0 [<9893511f>] __ip_local_out+0xbd/0xf0 [ ] ip_local_out+0x1c/0x50 [<995e2f37>] ip_send_skb+0x19/0x40 [<3d95f220>] udp_send_skb.isra.5+0x157/0x360 [ ] udp_sendmsg+0x9d8/0xc10 [<3bef56ec>] inet_sendmsg+0x3e/0xf0 [<8d23e405>] sock_sendmsg+0x1d/0x30 [<8c297097>] ___sys_sendmsg+0x108/0x2b0 [ ] __sys_sendmmsg+0xba/0x1c0 [ ] __x64_sys_sendmmsg+0x24/0x30 In __nf_conntrack_confirm, object ct can be referenced to by the stack variable ct and the members of ct->tuplehash. kmemleak needs at least one of them to find the ct object during scan. When the ct object is moved from the unconfirmed hlist to the confirmed hlist. kmemleak cannot see ct object if things happen in the following order and thus give the above false positive report. 1) ct object is removed from unconfirmed hlist. 2) kmemleak scans data/bss sections. 3) ct object is added to confirmed hlist and ct is destroyed as the function returns. 4) kmemleak scans task stacks. This patch marks the ct object as not a leak. Has this also been submitted upstream ? Due to travel, I haven't gotten to it yet. But if it has been submitted upstream, I can get it merged by Monday Bruce Signed-off-by: He Zhe --- This is only for v4.18 net/netfilter/nf_conntrack_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 3d52804..9b554c7 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -1138,6 +1139,8 @@ __nf_conntrack_alloc(struct net *net, if (ct == NULL) goto out; + kmemleak_not_leak(ct); + spin_lock_init(>lock); ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig; ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = NULL; -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/1] config cleanup
On 10/22/18 11:28 PM, Anuj Mittal wrote: Hi Bruce, Can you please merge this in 4.18, 4.19 and master? Thanks! The patch looks fine. Due to travel, I haven't gotten to it yet. But it will be merged by Monday. Bruce Anuj Mittal (1): sound.cfg: enable SND_SOC_INTEL_SKYLAKE cfg/sound.cfg | 1 + 1 file changed, 1 insertion(+) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] [meta-security][PATCH] os-release: remove OS_RELEASE_FEILD extending
depends on the OS_RELEASRE_FEILD os-release changes in core otherwise yocto-check-layer will fail Signed-off-by: Armin Kuster --- meta-security-compliance/recipes-core/os-release/os-release.bbappend | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta-security-compliance/recipes-core/os-release/os-release.bbappend b/meta-security-compliance/recipes-core/os-release/os-release.bbappend index e9fd44a..604bacb 100644 --- a/meta-security-compliance/recipes-core/os-release/os-release.bbappend +++ b/meta-security-compliance/recipes-core/os-release/os-release.bbappend @@ -1,4 +1 @@ -OS_RELEASE_FIELDS += "CPE_NAME" - CPE_NAME="cpe:/o:openembedded:nodistro:0" - -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [qemu] How to use qemu in your testing cycle
Hi, I am trying to wrap my head around how to incorporate qemu in our test/development cycle. I am currently building machine genericx86-64 machine producing a SDK and a number of files. One of them are the qemuboot.conf file but it have some path that is a relative path to the work directory. I would like to be able to supply our application developer a way to start a qemu instance and test out our application without having them using bitbake. I assume this should be possible but not sure exactly how to accomplish this? Any input would be appreciated so I can get started. BR Måns Zigher -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 3/3] layer.con: add TESTSUITE define
Signed-off-by: Armin Kuster
---
conf/layer.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/conf/layer.conf b/conf/layer.conf
index 675a149..76f5bd6 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -12,3 +12,5 @@ BBFILE_PRIORITY_security = "8"
LAYERSERIES_COMPAT_security = "thud"
LAYERDEPENDS_security = "core openembedded-layer perl-layer networking-layer
meta-python"
+
+DEFAULT_TEST_SUITES_pn-security-build-image = " ${MINTESTSUITE} ssh scp ptest"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 2/3] packagegroup-core-security: add ptest capable packages
and favor python-scapy
Signed-off-by: Armin Kuster
---
.../packagegroup/packagegroup-core-security.bb | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/recipes-security/packagegroup/packagegroup-core-security.bb
b/recipes-security/packagegroup/packagegroup-core-security.bb
index 718ea5a..653d87b 100644
--- a/recipes-security/packagegroup/packagegroup-core-security.bb
+++ b/recipes-security/packagegroup/packagegroup-core-security.bb
@@ -12,6 +12,7 @@ PACKAGES = "\
packagegroup-security-ids \
packagegroup-security-mac \
${@bb.utils.contains("MACHINE_FEATURES", "tpm",
"packagegroup-security-tpm", "",d)} \
+${@bb.utils.contains("DISTRO_FEATURES", "ptest",
"packagegroup-security-ptest", "", d)} \
"
RDEPENDS_packagegroup-core-security = "\
@@ -20,6 +21,7 @@ RDEPENDS_packagegroup-core-security = "\
packagegroup-security-ids \
packagegroup-security-mac \
${@bb.utils.contains("MACHINE_FEATURES", "tpm",
"packagegroup-security-tpm", "",d)} \
+${@bb.utils.contains("DISTRO_FEATURES", "ptest",
"packagegroup-security-ptest", "", d)} \
"
SUMMARY_packagegroup-security-utils = "Security utilities"
@@ -27,7 +29,7 @@ RDEPENDS_packagegroup-security-utils = "\
checksec \
nmap \
pinentry \
-python3-scapy \
+python-scapy \
ding-libs \
xmlsec1 \
keyutils \
@@ -66,3 +68,13 @@ RDEPENDS_packagegroup-security-mac = " \
${@bb.utils.contains("DISTRO_FEATURES", "apparmor", "", "",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \
"
+
+SUMMARY_packagegroup-security-ptest = "Security packages with ptests"
+RDEPENDS_packagegroup-security-ptest = " \
+samhain-standalone-ptest \
+xmlsec1-ptest \
+keyutils-ptest \
+libseccomp-ptest \
+python-scapy-ptest \
+ptest-runner \
+"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 1/3] packagegroups: add more packages
Signed-off-by: Armin Kuster
---
recipes-security/packagegroup/packagegroup-core-security.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/recipes-security/packagegroup/packagegroup-core-security.bb
b/recipes-security/packagegroup/packagegroup-core-security.bb
index 5317aee..718ea5a 100644
--- a/recipes-security/packagegroup/packagegroup-core-security.bb
+++ b/recipes-security/packagegroup/packagegroup-core-security.bb
@@ -28,6 +28,10 @@ RDEPENDS_packagegroup-security-utils = "\
nmap \
pinentry \
python3-scapy \
+ding-libs \
+xmlsec1 \
+keyutils \
+libseccomp \
${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils", "",d)} \
"
@@ -52,7 +56,7 @@ RDEPENDS_packagegroup-security-hardening = " \
SUMMARY_packagegroup-security-ids = "Security Intrusion Detection systems"
RDEPENDS_packagegroup-security-ids = " \
tripwire \
-samhain-client \
+samhain-standalone \
suricata \
"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
