Date   

QA notification for completed autobuilder build (yocto-3.1.9.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-3.1.9.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.9.rc1


Build hash information:

bitbake: 0e0af15b84e07e6763300dcd092b980086b9b9c4
meta-arm: 59974ccd5f1368b2a1c621ba3efd6d2c44c126dd
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: d8bf86ae6288ae520b8ddd7209a0b448b9693f48
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4
poky: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org


Yocto Project Status WW25`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.4 M1 has been through QA pending release approval with two QA issues highlighted.
  • YP 3.1.9 is being built ready for QA.
  • Big thanks to Paul Gortmaker for tracking down the cause of an LTP null pointer dereference (and other errors) within the cgroups mount code which was responsible for several of our LTP hangs. The issue was introduced in new code between 5.0 and 5.1 in the kernel and had been present for a while. The fix is now making its way through various kernel trees upstream.
  • Sadly, the above fix did not resolve the “rcu” autobuilder VM hangs we are seeing occasionally. These are odd in that they affect kvm and non-kvm builds (x86 and arm seen on x86-64 hosts), they pin the VM at 300-400% CPU usage and the VM will respond to pings but no ssh or console output. The rcu dumps from the kernel are likely a symptom that something is wrong rather than the cause and often look incomplete. It is as if some instantaneous host load breaks timers in a way the guest cannot recover or continue execution from. We’re continuing to try and narrow this down but it is proving elusive and progress is slow, any insight anyone may have would be welcome.
  • There are new manual sections that have recently been added on Reproducible Builds and Yocto Project Compatible.
  • We continue to deal with an issue with centos8 kernels having what looks like bad bounds checking on the utimensat_time64 32 bit syscalls where the syscall was backported into a kernel point release. We’re working on reporting it upstream.
  • We have a 10th anniversary T-shirt and some other Yocto Project items (hoody, stickers, mugs etc.) now available at https://yoctoproject.org/shop (EU and Americas sources)
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • Intermittent autobuilder issues continue to occur and continue to be at record high levels. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 is in review by the TSC
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.9 is being built
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Update APTCONF_TARGET manually

Mauro Ziliani
 

Hi all
I move all TMPDIR in another folder
The EXTRA_DISTRO_FETAURES += "package_managent"
PACKAGE_CLASS := " package_deb "

When I build the image the package_manager try to find the debs in the older folder.

I see that this problem is in apt/apt.conf of image working dir.

How can I change manually the value of APTCONF_TARGET?

Where the APTCONF_TARGET value is stored?

Best regards,
  MZ

Sent from Mailspring, the best free email app for work


Re: Empty source package when using devtool

Frederic Martinsons
 

Hello, I dug further into yocto classes and I think I found what is going on. 

All seems to come from the fact that gcc debug-prefix-map and macro-prefix-map options are statically defined in bitbake.conf to

DEBUG_PREFIX_MAP ?= "-fmacro-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
                     -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
                     -fdebug-prefix-map=${STAGING_DIR_HOST}= \
                     -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
"

I'll took an example to try to be clearer. Let's say that I devtool modify the glib-2.0 package. Without any configuration, sources will be extracted in ${BDIR}/workspace/sources/glib-2.0.
Build directory is set by externalsrc.bbclass to ${BDIR}/tmp/work/${arch}-${distro}/glib-2.0/${PN}/${EXTENDPE}${PV}-${PR}/${BPN}/${BPN}-${PV} (the real path doesn't matter, what is matter is that B is not under devtool spaces).

This lead to have pretty long relative path in gcc compilation line (sotheming like  -c ../../../../../../../../worspace/sources/glib-2.0/glib/gmain.c for example). Hence the debug-prefix-map could not be appplied.
After the compilation stage, package.bbclass (via splitdebuginfo), there is an extraction of sources path via dwarf format parsing. We ended up parsing something like

- /workspace/sources/glib-2.0/glib/gmain.c

instead of

- /usr/src/debug/glib-2.0/1_2.58.3-r0.2/glib-2.58.3/glib/gmain.c

I patch externalsrc.bbclass to dynamically caculate correct debug-prefix-map and prepend to DEBUG_PREFIX_MAP variable, I also patch the package.bbclass to add a condition when EXTERNALSRC is defined to change the way the sources are found and copied to packages-split/${pkg}-src.

I would greatly appreciate if there is a yocto guru around there to tell me what he thinks about all of this (bug or wrong configuration ?) and if my assumptions are correct (I assume this was a compiling/packaging problem instead of a pure devtool one) 


M+ & H bugs with Milestone Movements WW25

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW25 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11385

poky-container: clarify that meta-data should be checked out using native tools that run the host and not with tools in container

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13123

package.PackageTests.test_gdb_hardlink_debug failed

randy.macleod@...

randy.macleod@...

3.4 M1

3.4 M2

 

13411

ptest-perl.bbclass run-ptest is too greedy for SKIP

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13690

runqemu with slirp, forwarded host ports are not available on host

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13938

devtool modify virtual/kernel fails when EXTRAVERSION field is empty in Makefile

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13975

cve-checker: save to alternate file format like JSON

timothy.t.orling@...

chee.yang.lee@...

3.4 M1

3.4 M2

 

14127

cve-check falsely indicates a vulnerabily to be patched

timothy.t.orling@...

chee.yang.lee@...

3.4 M1

3.4 M2

 

14342

Setscene tasks in both covered and notcovered errors at the end of build

richard.purdie@...

richard.purdie@...

3.4 M1

3.4 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW25!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

2

ross@...

1

mhalstead@...

1

richard.purdie@...

1

Grand Total

5

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW25 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 91 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

richard.purdie@...

33

ross@...

31

michael.opdenacker@...

26

david.reyna@...

22

bruce.ashfield@...

21

JPEWhacker@...

12

bluelightning@...

12

akuster808@...

12

timothy.t.orling@...

11

trevor.gamblin@...

11

randy.macleod@...

10

sakib.sajal@...

10

kai.kang@...

9

tony.tascioglu@...

8

Qi.Chen@...

6

hongxu.jia@...

6

mingli.yu@...

6

yi.zhao@...

5

chee.yang.lee@...

5

raj.khem@...

5

alexandre.belloni@...

4

mostthingsweb@...

3

pokylinux@...

2

mshah@...

2

ydirson@...

2

jaewon@...

2

yf3yu@...

2

kexin.hao@...

2

alejandro@...

2

yoctoproject@...

1

mark.hatle@...

1

liezhi.yang@...

1

nicolas.dechesne@...

1

stacygaikovaia@...

1

dl9pf@...

1

douglas.royds@...

1

open.source@...

1

naveen.kumar.saini@...

1

Martin.Jansa@...

1

shachar@...

1

jon.mason@...

1

mister_rs@...

1

kergoth@...

1

john.kaldas.enpj@...

1

jeanmarie.lemetayer@...

1

devendra.tewari@...

1

aehs29@...

1

diego.sueiro@...

1

matthewzmd@...

1

thomas.perrot@...

1

saul.wold@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


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  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

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 342 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: the downside of parallelism

Robert P. J. Day
 

On Sun, 20 Jun 2021, Robert Berger@yocto.user wrote:

Hi,

On 20/06/2021 12:55, Robert P. J. Day wrote:

refactoring existing (legacy) code base into more bite-sized
bitbake recipes to speed up build by taking advantage of 6-core
(12-thread) dell laptop ... end result is that i get so much
parallelism that laptop shuts down from overheating.
Sorry for my stupid question;)

If you have 12 threads, it's 12 threads and not more.

I guess there needs to be some kind of dependency between your new recipes.

make -j can use as many cores as you like even with a single recipe.

How would it speed up builds if you break up a recipe into multiple recipes?

What is your refactoring approach?
the (legacy) code base i was handed involves several sizable
makefiles that were not designed to take advantage of parallelism --
apparently, they come from an environment (QNX?) where "make" does not
do parallelism. so rather than design makefiles with parallelism in
mind, many of the makefiles correspond to some large subsystem where
the top-level target has a rule that simply descends into the numerous
sub-component directories one at a time:

fubar:
$(MAKE) -C fubar1
$(MAKE) -C fubar2
...
$(MAKE) -C fubar42

and last i heard, the commands in any rule are definitely processed
serially. so when the local folks started transmogrifying the code
base to use YP, they just used SRC_URI to point at the existing
makefiles (which *must* stay where they are for the purpose of legacy
compatibility). so as a start, there is a recipe "fubar.bb" which just
runs that top-level Makefile, but given its structure, once it starts,
all you see is "fubar compiling" as it serially processes all of its
subcomponents.

now, most of the major components have sub-directories with, say,
the shared libs, the test suite, and so on, and a lot of other
components that allegedly DEPENDS on "fubar" obviously don't need
*all* of fubar to finish compiling, just normally the library
sub-component, but as it is, they have to wait for all of it, so you
normally see "fubar compiling", and nothing else, for several minutes,
and as soon as that finishes, a bunch of deps that have been patiently
waiting finally kick off.

as i refactor the above into smaller recipes, then the dependencies
build much faster and as soon as the shared lib recipe finishes, all
those other recipes can start, so i'm definitely getting way more
parallelism but, as i mentioned, that comes with a price.

now, given my unlimited cleverness into refactoring recipes, most of
my 6 cores (12 threads) are busy, which is driving up the load average
over the course of the build (easily over an hour for the whole
thing), and sometimes the load average peaks at over 130, and the air
vent on this laptop is blowing air so hot, it can actually burn you if
you leave your hand there too long, and every so often, it just locks
up and shuts down.

what irony -- i redesign the recipes to boost parallelism, only to
fall victim to hardware limitations.

rday


Re: TLV320AIC3104: tlv320aic3104 #kernel #yocto

Alexandre Belloni
 

Hello,

On 20/06/2021 22:01:48-0700, Amrun Nisha.R wrote:
Hi,

I am using tlv320aic3104 in one of my project, The hardware is wired
in such a way that the I2C lines from tlv320aic3104 is connected to a
separate microprocessor which performs the init.

The SAI lines of tlv320aic3104 are connected to IMX8M SAI lines, I am
running linux in IMX8M. ALSA says no sound cards found.

I would like to know whether this kind of setup where the i2c is used
by a separate processor and using the SAI lines in  a different device
that runs linux will work. Kindly advice
To support that, you will have to write your own card driver or at least
write a device tree sound node with a dummy codec as Linux will not be
configuring it.

See https://bootlin.com/pub/conferences/2020/lee/belloni-alsa-asoc/belloni-alsa-asoc.pdf

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


TLV320AIC3104: tlv320aic3104 #kernel #yocto

Amrun Nisha.R
 

Hi,

I am using tlv320aic3104 in one of my project, The hardware is wired in such a way that the I2C lines from tlv320aic3104 is connected to a separate microprocessor which performs the init.

The SAI lines of tlv320aic3104 are connected to IMX8M SAI lines, I am running linux in IMX8M. ALSA says no sound cards found.

I would like to know whether this kind of setup where the i2c is used by a separate processor and using the SAI lines in  a different device that runs linux will work. Kindly advice


[meta-zephyr][PATCH 2/2] zephyr-coap-client: Add recipe for CoAP client

Amit Kucheria
 

This sample application provides an example coap-client using the the MBEDTLS library.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-coap-client.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-coap-client.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-coap-client.bb b/recipes-kernel/zephyr-kernel/zephyr-coap-client.bb
new file mode 100644
index 000000000000..4140c0f89eae
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-coap-client.bb
@@ -0,0 +1,5 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/net/sockets/coap_client"
+
+ZEPHYR_MODULES_append = "\;${S}/modules/lib/mbedtls"
--
2.25.1


[meta-zephyr][PATCH 1/2] zephyr-coap-server: Add recipe for CoAP server

Amit Kucheria
 

This sample application provides an example coap-server using the the MBEDTLS library.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-coap-server.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-coap-server.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-coap-server.bb b/recipes-kernel/zephyr-kernel/zephyr-coap-server.bb
new file mode 100644
index 000000000000..f7d75c04efd4
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-coap-server.bb
@@ -0,0 +1,5 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/net/sockets/coap_server"
+
+ZEPHYR_MODULES_append = "\;${S}/modules/lib/mbedtls"
--
2.25.1


Re: [meta-security][PATCH] aircrack-ng: update to 1.6

Armin Kuster
 

merged,

thanks

On 6/15/21 9:32 PM, Federico Pellegrin wrote:
Signed-off-by: Federico Pellegrin <fede@evolware.org>
---
.../{aircrack-ng_1.3.bb => aircrack-ng_1.6.bb} | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
rename recipes-security/aircrack-ng/{aircrack-ng_1.3.bb => aircrack-ng_1.6.bb} (82%)

diff --git a/recipes-security/aircrack-ng/aircrack-ng_1.3.bb b/recipes-security/aircrack-ng/aircrack-ng_1.6.bb
similarity index 82%
rename from recipes-security/aircrack-ng/aircrack-ng_1.3.bb
rename to recipes-security/aircrack-ng/aircrack-ng_1.6.bb
index d739227..8d3b531 100644
--- a/recipes-security/aircrack-ng/aircrack-ng_1.3.bb
+++ b/recipes-security/aircrack-ng/aircrack-ng_1.6.bb
@@ -9,8 +9,8 @@ DEPENDS = "libnl openssl sqlite3 libpcre libpcap"

SRC_URI = "http://download.aircrack-ng.org/${BP}.tar.gz"

-SRC_URI[md5sum] = "c7c5b076dee0c25ee580b0f56f455623"
-SRC_URI[sha256sum] = "8ae08a7c28741f6ace2769267112053366550e7f746477081188ad38410383ca"
+SRC_URI[md5sum] = "22ddc85549b51ed0da0931d01ef215e5"
+SRC_URI[sha256sum] = "4f0bfd486efc6ea7229f7fbc54340ff8b2094a0d73e9f617e0a39f878999a247"

inherit autotools-brokensep pkgconfig

@@ -29,6 +29,8 @@ do_install () {
make DESTDIR=${D} ${OEMAKE_EXTRA} ext_scripts=true install
}

-FILES_${PN} += "/usr/local/"
+FILES_${PN} += "${libdir}/*.so"
+FILES_SOLIBSDEV = ""
+INSANE_SKIP_${PN} += "dev-so"

RDEPENDS_${PN} = "libpcap"


[meta-security][PATCH] initramfs-framework: fix typo in conditional

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/initrdscripts/initramfs-framework_1.0.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
index dc74e01..f5d476e 100644
--- a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
+++ b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
@@ -1 +1 @@
-require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity', 'initramfs-framework.inc', '', d)}
+require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity-img', 'initramfs-framework.inc', '', d)}
--
2.17.1


Re: [meta-security][PATCH] sssd: set pid path with /run

Armin Kuster
 

series merged.

thanks

On 6/15/21 1:50 AM, kai.kang@windriver.com wrote:
From: Kai Kang <kai.kang@windriver.com>

/var/run is deprecated and set pid path with /run to store pid files for
the SSSD.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
recipes-security/sssd/sssd_2.5.0.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/recipes-security/sssd/sssd_2.5.0.bb b/recipes-security/sssd/sssd_2.5.0.bb
index 4c92519..c699527 100644
--- a/recipes-security/sssd/sssd_2.5.0.bb
+++ b/recipes-security/sssd/sssd_2.5.0.bb
@@ -63,6 +63,7 @@ EXTRA_OECONF += " \
--without-python2-bindings \
--without-secrets \
--with-xml-catalog-path=${STAGING_ETCDIR_NATIVE}/xml/catalog \
+ --with-pid-path=/run \
"

do_configure_prepend() {
@@ -88,8 +89,8 @@ do_install () {
echo "d /var/log/sssd 0750 - - - -" > ${D}${sysconfdir}/tmpfiles.d/sss.conf
fi

- # Remove /var/run as it is created on startup
- rm -rf ${D}${localstatedir}/run
+ # Remove /run as it is created on startup
+ rm -rf ${D}/run

rm -f ${D}${systemd_system_unitdir}/sssd-secrets.*
}


Re: [PATCH] smack: add 3 cves to allowlist

Armin Kuster
 

merged.

On 6/18/21 5:16 AM, Sekine Shigeki wrote:
CVE-2014-0363, CVE-2014-0364, CVE-2016-10027 are not for smack of smack-team(https://github.com/smack-team/smack) but other project.

Signed-off-by: Sekine Shigeki <sekine.shigeki@fujitsu.com>
---
recipes-mac/smack/smack_1.3.1.bb | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-mac/smack/smack_1.3.1.bb b/recipes-mac/smack/smack_1.3.1.bb
index b1ea4e9..6ae715e 100644
--- a/recipes-mac/smack/smack_1.3.1.bb
+++ b/recipes-mac/smack/smack_1.3.1.bb
@@ -13,6 +13,11 @@ SRC_URI = " \

PV = "1.3.1"

+# CVE-2014-0363, CVE-2014-0364, CVE-2016-10027 is valnerble for other product.
+CVE_CHECK_WHITELIST += "CVE-2014-0363"
+CVE_CHECK_WHITELIST += "CVE-2014-0364"
+CVE_CHECK_WHITELIST += "CVE-2016-10027"
+
inherit autotools update-rc.d pkgconfig ptest
inherit ${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}
inherit features_check



Re: the downside of parallelism

Robert Berger
 

Hi,

On 20/06/2021 12:55, Robert P. J. Day wrote:
refactoring existing (legacy) code base into more bite-sized
bitbake recipes to speed up build by taking advantage of 6-core
(12-thread) dell laptop ... end result is that i get so much
parallelism that laptop shuts down from overheating.
Sorry for my stupid question;)

If you have 12 threads, it's 12 threads and not more.

I guess there needs to be some kind of dependency between your new recipes.

make -j can use as many cores as you like even with a single recipe.

How would it speed up builds if you break up a recipe into multiple recipes?

What is your refactoring approach?

le *sigh* ...
rday
Regards,

Robert


Re: the downside of parallelism

Robert P. J. Day
 

On Sun, 20 Jun 2021, Alexander Kanavin wrote:

This is hardly Yocto's fault: putting a 6 core CPU into a laptop
should be validated by saturating all cores for several hours and
ensuring the cooling and frequency throttling can handle it. Laptop
OEM is trying to be cheap I'd say.

Alex
i wasn't blaming yocto ... that was an attempt at wry humour. or
possibly irony.

rday


Re: the downside of parallelism

Alexander Kanavin
 

This is hardly Yocto's fault: putting a 6 core CPU into a laptop should be validated by saturating all cores for several hours and ensuring the cooling and frequency throttling can handle it. Laptop OEM is trying to be cheap I'd say.

Alex


On Sun, 20 Jun 2021 at 11:55, Robert P. J. Day <rpjday@...> wrote:

  refactoring existing (legacy) code base into more bite-sized
bitbake recipes to speed up build by taking advantage of 6-core
(12-thread) dell laptop ... end result is that i get so much
parallelism that laptop shuts down from overheating.

  le *sigh* ...

rday



1241 - 1260 of 55143