[yocto] [meta-security][PATCH] complicance/isafw: remove oeqa addpylib
From: Chen Qi
These two layers do not have oeqa lib modules. Remove these two
lines. Otherwise, `bitbake-layers add-layer ' would fail
if either of these two layers are in BBLAYERS.
Signed-off-by: Chen Qi
---
meta-security-compliance/conf/layer.conf | 2 --
meta-security-isafw/conf/layer.conf | 2 --
2 files changed, 4 deletions(-)
diff --git a/meta-security-compliance/conf/layer.conf
b/meta-security-compliance/conf/layer.conf
index cb33c2c..82409a6 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -13,5 +13,3 @@ LAYERSERIES_COMPAT_scanners-layer = "mickledore"
LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"
BBLAYERS_LAYERINDEX_NAME_scanners-layer = "meta-security-compliance"
-
-addpylib ${LAYERDIR}/lib oeqa
diff --git a/meta-security-isafw/conf/layer.conf
b/meta-security-isafw/conf/layer.conf
index fca5868..550cced 100644
--- a/meta-security-isafw/conf/layer.conf
+++ b/meta-security-isafw/conf/layer.conf
@@ -15,5 +15,3 @@ LAYERVERSION_security-isafw = "1"
LAYERDEPENDS_security-isafw = "core"
LAYERSERIES_COMPAT_security-isafw = "mickledore"
-
-addpylib ${LAYERDIR}/lib oeqa
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60246): https://lists.yoctoproject.org/g/yocto/message/60246
Mute This Topic: https://lists.yoctoproject.org/mt/99477706/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work
SSTATE_DIR and DL_DIR are writable. Sharing them among different builds owned/controlled by the same user is OK, but sharing these writable directories among different users does not seem to be a good idea. You could consider using the PREMIRRORS and SSTATE_MIRRORS. Regards, Qi On 9/11/23 09:49, Li Chen via lists.yoctoproject.org wrote: Hi Yocto experts, I'm a Yocto newbiee and I have a concern regarding the slowness of Yocto for our team(around 100 people). There are two main reasons for this: 1. Yocto itself is slower compared to other build systems. 2. Each user in our team has their own private SSTATE_DIR and DL_DIR, which means the artifacts cannot be shared. This leads to unnecessary disk and CPU usage. 3. Every user works on SATA devices, so the IOPS and throughput are both low. Since it's hard for us to invest in expensive enterprise NVMe for all build servers, I have an idea to address this issue. My suggestion is to use Lustre/NFS/Glustrefs along with small NVMe to share everyone's SSTATE/DL_DIR. I prefer Lustre over NFS because Lustre offers superior IO performance scalability, making it suitable for data-intensive tasks. It splits the data, allowing it to be requested from one server but sent from one or more other servers. For the storage of SSTATE/DL_DIR only, the size requirement would not be high, so a small NVMe should be sufficient. NVMe can provide much higher throughput and IOPS compared to our current slow SATA, so I guess it can meet our needs. If necessary, we can easily add another NVMe to another server since Lustre is a distributed file system. The overall cost would not be significant. My questions are: 1. Are there any errors in my understanding? 2. Is this solution feasible? If not, why? If yes, can it be further improved? I look forward to hearing from you! Regards, Li -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60964): https://lists.yoctoproject.org/g/yocto/message/60964 Mute This Topic: https://lists.yoctoproject.org/mt/101284965/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work
On 9/11/23 15:36, Alexander Kanavin wrote: On Mon, 11 Sept 2023 at 06:22, Chen Qi via lists.yoctoproject.org wrote: SSTATE_DIR and DL_DIR are writable. Sharing them among different builds owned/controlled by the same user is OK, but sharing these writable directories among different users does not seem to be a good idea. You could consider using the PREMIRRORS and SSTATE_MIRRORS. This is not accurate. SSTATE_DIR is designed to be shared in a read-write fashion via NFS or other over the network filesystem (between users on the same machine is also ok), and is heavily used that way in Yocto CI. This is the case I referred to as 'different builds owned/controlled by the same user'. Say, you share the SSTATE_DIR used by Yocto CI to many people via NFS. Then, a 'rm -rf' might be typed by someone by accident, maybe just because of lack of coffee. Regards, Qi Sharing DL_DIR is less important as it is not that large, and downloading does not slow down the builds that much compared to the the actual build (and only needs to happen once). Li, your understanding is more or less completely correct. The difficulties are mostly in scaling up, where you might hit the limits of how many users can be served at the same time. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60969): https://lists.yoctoproject.org/g/yocto/message/60969 Mute This Topic: https://lists.yoctoproject.org/mt/101284965/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how to intelligently avoid OOM build errors with BB_PRESSURE_MAX_MEMORY?
From systemd's source codes (src/oom/oomd-manager.h):
/* Take action if 10s of memory pressure > 60 for more than 30s. We use
the "full" value from PSI so this is the
* percentage of time all tasks were delayed (i.e. unproductive).
* Generally 60 or higher might be acceptable for something like
system.slice with no memory.high set; processes in
* system.slice are assumed to be less latency sensitive. */
#define DEFAULT_MEM_PRESSURE_DURATION_USEC (30 * USEC_PER_SEC)
#define DEFAULT_MEM_PRESSURE_LIMIT_PERCENT 60
#define DEFAULT_SWAP_USED_LIMIT_PERCENT 90
So I guess using something lower than 60% * 1,000,000 would be OK (e.g.,
200,000).
Regards,
Qi
On 11/29/23 17:21, Robert P. J. Day wrote:
a colleague is using Wind River Linux and is getting occasional OOM
errors when taking advantage of maximum parallelism, so he took the
quick way out and dialed things back using BB_NUMBER_THREADS and
PARALLEL_MAKE.
however, i am aware of the bitbake variables
BB_PRESSURE_MAX_{IO,CPU,MEMORY} and was wondering if there is a decent
writeup on how to use, perhaps, BB_PRESSURE_MAX_MEMORY, to dynamically
detect imminent OOM and adjust things. that is, how to calculate a
sane value for that as i haven't yet dug into the values under
/proc/pressure and how to interpret them?
i've seen mentions of combining the above with the "memstat"
command, and other approaches. thoughts?
rday
p.s. is there a docs page that expands on this stuff?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61772): https://lists.yoctoproject.org/g/yocto/message/61772
Mute This Topic: https://lists.yoctoproject.org/mt/102868689/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to generate a random number for all recipes?
How about using ':='?
e.g.,
HELLO := "${@random_number_function}"
Regards,
Qi
On 12/29/23 13:49, Jiliang Cai wrote:
I define a global variable in config like this:
HELLO=${@random_number_function}
Then I print HELLO's value in two bbfiles. I found that the value of
HELLO is different because the random_number_function was called in
every bbfile. How to fix it?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62047): https://lists.yoctoproject.org/g/yocto/message/62047
Mute This Topic: https://lists.yoctoproject.org/mt/103413529/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to generate a random number for all recipes?
On 12/29/23 15:38, Gileon Chai wrote:
Thank you for your reply.
HELLO's value in two bbfiles is same when using ':=', but it brought new errors:
ERROR: When reparsing a.bb and b.bb: the basehash value changed from
to . The metadata is not deterministic and this needs to be
fixed.
This problem could be solved by using something like below:
do_mytask[vardepsexclude] += "HELLO"
You may also consider using 'nostamp' flag for these tasks, depending on
your final goal.
What could be the reason? My guess is that, during reparses, bitbake
also calls the random_number_function multiple times, causing
different random numbers to be generated each time and thus resulting
in different hash values.
I am a beginner, and this issue is a bit complex for me. So, I took
the following approach: I wrote the random number to a file using a
recipe, and other bbfiles use it by reading the random number file.
Is there a good idea? Thanks again!
I think anything that achieves your final goal is good.
Regards
Qi
ChenQi 于2023年12月29日周五 14:12写道：
How about using ':='?
e.g.,
HELLO := "${@random_number_function}"
Regards,
Qi
On 12/29/23 13:49, Jiliang Cai wrote:
I define a global variable in config like this:
HELLO=${@random_number_function}
Then I print HELLO's value in two bbfiles. I found that the value of
HELLO is different because the random_number_function was called in
every bbfile. How to fix it?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62050): https://lists.yoctoproject.org/g/yocto/message/62050
Mute This Topic: https://lists.yoctoproject.org/mt/103413529/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper][PATCH] config.json: use INIT_MANAGER
From: Chen Qi
The default INIT_MANAGER is 'sysvinit', to use systemd as the init
manager, we use INIT_MANAGER = 'systemd' because we can make use
of the settings in conf/distro/include/init-manager-systemd.inc.
Signed-off-by: Chen Qi
---
config.json | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/config.json b/config.json
index d504d07..6024161 100644
--- a/config.json
+++ b/config.json
@@ -1107,9 +1107,8 @@
"shortname" : "Systemd weston",
"extravars" : [
"TEST_SUITES:append = ' systemd'",
- "DISTRO_FEATURES:append = ' pam systemd usrmerge'",
- "VIRTUAL-RUNTIME_init_manager = 'systemd'",
- "DISTRO_FEATURES_BACKFILL_CONSIDERED = 'sysvinit'"
+ "INIT_MANAGER = 'systemd'",
+ "DISTRO_FEATURES:append = ' pam'",
]
}
},
@@ -1422,8 +1421,8 @@
"BBTARGETS" : "core-image-sato",
"SANITYTARGETS" : "core-image-sato:do_testimage",
"extravars" : [
-"DISTRO_FEATURES:append = ' systemd usrmerge'",
-"VIRTUAL-RUNTIME_init_manager = 'systemd'",
+"INIT_MANAGER = 'systemd'",
+"DISTRO_FEATURES_BACKFILL_CONSIDERED:remove = 'sysvinit'",
"TEST_SUITES:append = ' systemd'"
]
},
@@ -1442,9 +1441,7 @@
"SANITYTARGETS" : "core-image-sato:do_testimage",
"extravars" : [
"TEST_SUITES:append = ' systemd'",
-"DISTRO_FEATURES:append = ' systemd usrmerge'",
-"VIRTUAL-RUNTIME_init_manager = 'systemd'",
-"DISTRO_FEATURES_BACKFILL_CONSIDERED = 'sysvinit'"
+"INIT_MANAGER = 'systemd'",
]
},
"step7" : {
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62061): https://lists.yoctoproject.org/g/yocto/message/62061
Mute This Topic: https://lists.yoctoproject.org/mt/103475364/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper][PATCH] config.json: set ROOT_HOME to /root for sysvinit with systemd
From: Chen Qi For sysvinit with systemd, the systemd package will still be build. This gives us a warning like below: WARNING: systemd-1_255.1-r0 do_install: Using /home/root as root user's home directory is not fully supported by systemd Set ROOT_HOME to "/root" to avoid such warning. Note that when using sysvinit as the init manager, /home/root is totally valid, it's just that 'systemd' being in DISTRO_FEATURES causes systemd to be built. So the only purpose of this patch's is to avoid warnings on autobuilders. Signed-off-by: Chen Qi --- config.json | 1 + 1 file changed, 1 insertion(+) diff --git a/config.json b/config.json index 4686068..ad18226 100644 --- a/config.json +++ b/config.json @@ -1432,6 +1432,7 @@ "SANITYTARGETS" : "core-image-sato:do_testimage", "extravars" : [ "DISTRO_FEATURES:append = ' systemd usrmerge'", +"ROOT_HOME = '/root'", "VIRTUAL-RUNTIME_init_manager = 'sysvinit'" ] }, -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62113): https://lists.yoctoproject.org/g/yocto/message/62113 Mute This Topic: https://lists.yoctoproject.org/mt/103616458/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Cannot ssh into qemu guest
I'd suggest that in the serial console you get: 1) check the ip address of the booted target 2) Run 'ssh root@localhost' on that target to check if login onto itself is OK 3) If you can ssh locally and the ip is 192.168.7.2, and you still have problem with 'ssh root@192.168.7.2', maybe you need to check the iptables rules of your host. Is it reachable? 'ping 192.168.7.2'? Regards, Qi On 3/9/24 06:58, Xylopyrographer wrote: I've built a QEMU quemuarm64 core-image-full-cmdline machine. Runs fine. I'm launching it with: *runqemu qemuarm64 nographic* Now trying to figure out how to ssh into it. The book I'm following simply states: "You can SSH into this VM with *ssh root@192.168.7.2*" A bit later, going through the exercise of using devtool to add a new recipe, the command line is: *devtool deploy-target bubblewrap root@192.168.7.2* However, both *ssh root@192.168.7.2* and the *deploy-target* commands time out on attempting the ssh connection. * Host is Debian 12 Bookworm * Yocto version is nanbield * Using GNOME Terminal * Launching qemu in one Terminal window, running everything else in a second Terminal window. Any pointers on the magic incantation to get this running? Many thanks. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62722): https://lists.yoctoproject.org/g/yocto/message/62722 Mute This Topic: https://lists.yoctoproject.org/mt/104819558/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to use a single directory in multiple layers.
I haven't tested, but you can try:
In meta-x's layer.conf:
THIS_SPECIFIC_DIR = "${LAYERDIR}"
Then use the variable THIS_SPECIFIC_DIR in other places including meta-y.
Regards,
Qi
On 3/13/24 18:38, Saswati Nayak wrote:
Hello All,
I require guidance on utilizing a file directory present in
the 'meta-x' layer while also needing access to the same directory
within the 'meta-y' layer.
How can I achieve this while keeping the directory centralized in one
layer?
Thanks & Regards
Saswati
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62749): https://lists.yoctoproject.org/g/yocto/message/62749
Mute This Topic: https://lists.yoctoproject.org/mt/104902553/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] requires libsqlite3.so()(64bit), but no providers found in RDEPENDS:xxx? [file-rdeps] #kirkstone #yocto
How about using the following setting?
RDEPENDS:${PN} += “sqlite3”
Regards,
Qi
From: yocto@lists.yoctoproject.org On Behalf Of
Alexander Kanavin
Sent: Tuesday, May 14, 2024 4:34 PM
To: salahaldeen.alt...@leica-camera.com; yocto@lists.yoctoproject.org
Subject: Re: [yocto] requires libsqlite3.so()(64bit), but no providers found in
RDEPENDS:xxx? [file-rdeps] #kirkstone #yocto
Can you show the complete recipe?
Alex
On Tue 14. May 2024 at 9.56, Altous, Salahaldeen via
lists.yoctoproject.org
mailto:leica-camera@lists.yoctoproject.org>>
wrote:
Hi All,
I have one yocto recipe which is using libsqlite3, the compile task is OK but I
got this error with do_package_qa
/usr/lib/libexample.so.0.2.3 contained in package example requires
libsqlite3.so()(64bit), but no providers found in RDEPENDS:example.?
[file-rdeps]
I have added this to the example recipe RDEPENDS but still the problem is not
solved, any idea?
DEPENDS += " sqlite3"
RDEPENDS_${PN} += " libsqlite3.so()(64bit)"
Regards,
Salahaldeen
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63085): https://lists.yoctoproject.org/g/yocto/message/63085
Mute This Topic: https://lists.yoctoproject.org/mt/106090753/21656
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Disable bitbake command ANSI color output
On 5/29/24 05:31, bibibob...@gmail.com wrote:
Greetings everyone,
Dummy question, is there a quick way to disable bitbake output color?
When we do container build, there is a lot of ANSI color code.
[36m[39m NOTE: recipe python3-gcovr-native-5.1-r0: task
do_autorev_check: Succeeded[0m[0m
...
I was wondering if there is some quick TERM= setting or NO_COLOR env
var that can suppress these things.
Just checked the codes:
if color == 'always' or (color == 'auto' and output.isatty() and
os.environ.get('NO_COLOR', '') == ''):
format.enable_color()
I think you set NO_COLOR in env and the color should not be enabled.
e.g.,
NO_COLOR=1 bitbake xxx
Regards,
Qi
Thanks,
m.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63221): https://lists.yoctoproject.org/g/yocto/message/63221
Mute This Topic: https://lists.yoctoproject.org/mt/106358067/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-security] [PATCH] recipes: Start WORKDIR -> UNPACKDIR transition
I think this is a wrong fix. Most settings are just fine.
Please double check.
Regards,
Qi
On 6/3/24 17:03, wangmy via lists.yoctoproject.org wrote:
Replace references of WORKDIR with UNPACKDIR where it makes sense to do so in
preparation for changing the default value of UNPACKDIR.
Signed-off-by: Wang Mingyu
---
.../recipes-scanners/checksecurity/checksecurity_2.0.16.bb| 2 +-
.../meta-perl/recipes-security/bastille/bastille_3.2.1.bb | 2 +-
.../meta-perl/recipes-security/nikto/nikto_2.1.6.bb | 2 +-
.../recipes-security/fail2ban/python3-fail2ban_1.0.2.bb | 2 +-
meta-tpm/recipes-tpm/libtpm/libtpm_0.9.6.bb | 2 +-
meta-tpm/recipes-tpm/swtpm/swtpm_0.8.1.bb | 2 +-
meta-tpm/recipes-tpm1/hoth/libhoth_git.bb | 2 +-
.../openssl-tpm-engine/openssl-tpm-engine_0.5.0.bb| 2 +-
meta-tpm/recipes-tpm1/pcr-extend/pcr-extend_git.bb| 2 +-
.../recipes-tpm1/tpm-quote-tools/tpm-quote-tools_1.0.4.bb | 2 +-
meta-tpm/recipes-tpm1/tpm-tools/tpm-tools_1.3.9.2.bb | 2 +-
meta-tpm/recipes-tpm1/trousers/trousers_git.bb| 2 +-
meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_183-2024-03-27.bb | 2 +-
meta-tpm/recipes-tpm2/ibmtpm2tss/ibmtpm2tss_2.2.0.bb | 2 +-
meta-tpm/recipes-tpm2/tpm2-tcti-uefi/tpm2-tcti-uefi_0.9.9.bb | 2 +-
meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.3.0.bb| 2 +-
recipes-compliance/lynis/lynis_3.1.1.bb | 2 +-
recipes-compliance/openscap/openscap_1.3.9.bb | 2 +-
.../scap-security-guide/scap-security-guide_0.1.71.bb | 2 +-
recipes-ids/crowdsec/crowdsec_1.1.1.bb| 2 +-
recipes-ids/ossec/ossec-hids_3.7.0.bb | 2 +-
recipes-ids/samhain/samhain.inc | 2 +-
recipes-ids/suricata/libhtp_0.5.45.bb | 4 ++--
recipes-ids/tripwire/tripwire_2.4.3.7.bb | 2 +-
recipes-kernel/lkrg/lkrg-module_0.9.7.bb | 2 +-
recipes-mac/AppArmor/apparmor_3.1.3.bb| 2 +-
recipes-mac/ccs-tools/ccs-tools_1.8.9.bb | 2 +-
recipes-mac/smack/mmap-smack-test_1.0.bb | 2 +-
recipes-mac/smack/smack-test_1.0.bb | 2 +-
recipes-mac/smack/smack_1.3.1.bb | 2 +-
recipes-mac/smack/tcp-smack-test_1.0.bb | 2 +-
recipes-mac/smack/udp-smack-test_1.0.bb | 2 +-
recipes-perl/perl/lib-perl_0.63.bb| 2 +-
recipes-perl/perl/libwhisker2-perl_2.5.bb | 2 +-
recipes-scanners/buck-security/buck-security_0.7.bb | 2 +-
recipes-scanners/checksec/checksec_2.6.0.bb | 2 +-
recipes-scanners/clamav/clamav_0.104.4.bb | 2 +-
recipes-security/Firejail/firejail_0.9.72.bb | 2 +-
recipes-security/chipsec/chipsec_1.9.1.bb | 2 +-
recipes-security/fscrypt/fscrypt_1.1.0.bb | 2 +-
recipes-security/fscryptctl/fscryptctl_1.1.0.bb | 2 +-
recipes-security/glome/glome_git.bb | 2 +-
.../google-authenticator-libpam_1.09.bb | 2 +-
recipes-security/krill/krill_0.12.3.bb| 2 +-
recipes-security/libest/libest_3.2.0.bb | 2 +-
recipes-security/libmhash/libmhash_0.9.9.9.bb | 2 +-
recipes-security/libmspack/libmspack_1.11.bb | 2 +-
recipes-security/ncrack/ncrack_0.7.bb | 2 +-
recipes-security/redhat-security/redhat-security_1.0.bb | 2 +-
49 files changed, 50 insertions(+), 50 deletions(-)
diff --git
a/dynamic-layers/meta-perl/recipes-scanners/checksecurity/checksecurity_2.0.16.bb
b/dynamic-layers/meta-perl/recipes-scanners/checksecurity/checksecurity_2.0.16.bb
index 8006c9f..7bd796f 100644
---
a/dynamic-layers/meta-perl/recipes-scanners/checksecurity/checksecurity_2.0.16.bb
+++
b/dynamic-layers/meta-perl/recipes-scanners/checksecurity/checksecurity_2.0.16.bb
@@ -10,7 +10,7 @@ SRC_URI =
"http://ftp.de.debian.org/debian/pool/main/c/checksecurity/checksecuri
SRC_URI[sha256sum] = "9803b3760e9ec48e06ebaf48cec081db48c6fe72254a476224e4c5c55ed97fb0"
-S = "${WORKDIR}/checksecurity-${PV}+nmu1"
+S = "${UNPACKDIR}/checksecurity-${PV}+nmu1"
# allow for anylocal, no need to patch
diff --git
a/dynamic-layers/meta-perl/recipes-security/bastille/bastille_3.2.1.bb
b/dynamic-layers/meta-perl/recipes-security/bastille/bastille_3.2.1.bb
index f2ef335..1c3610c 100644
--- a/dynamic-layers/meta-perl/recipes-security/bastille/bastille_3.2.1.bb
+++ b/dynamic-layers/meta-perl/recipes-security/bastille/bastille_3.2.1.bb
@@ -35,7 +35,7 @@ SRC_URI =
"http://sourceforge.net/projects/bastille-linux/files/bastille
