Date   

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@... 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@...>
---
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@...>
---
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@...>
---
.../{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@...>
---
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@... wrote:
From: Kai Kang <kai.kang@...>

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

Signed-off-by: Kai Kang <kai.kang@...>
---
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@...>
---
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




the downside of parallelism

Robert P. J. Day
 

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


Re: Appending an existing machine .conf file

Mike Frampton
 

Hi Frédéric,

Thanks for your suggestion,

you can customize QB_OPT_APPEND by removing options you don't want, e.g.

QB_OPT_APPEND_remove = "-device usb-tablet"

and add your own after.
I suppose this would be a bit less maintainable, as it's effectively
duplicating the entry in the base config... but I think it will work
for me for now. Thank you.

Regards,
--Mike


Re: Appending an existing machine .conf file

Frederic Martinsons <frederic.martinsons@...>
 

Hello, 

 you can customize QB_OPT_APPEND by removing options you don't want, e.g.

QB_OPT_APPEND_remove = "-device usb-tablet"

and add your own after.

But maybe a lazy operator in the original conf file would be more suitable.

On Sat, 19 Jun 2021 at 06:41, Mike Frampton <mikeframpo@...> wrote:
Greetings Yocto,

I'm interested in assigning custom config settings for machine type qemuarm.

I tried a method suggested in this thread
https://lists.yoctoproject.org/g/yocto/message/38359 by Ayoub Zaki, he
suggested defining the following in local.conf

> include conf/machine/${MACHINE}-extra.conf

However, this doesn't work for me because quemuarm.conf in poky/meta
**assigns** its variables, e.g.,

> QB_OPT_APPEND = "-device VGA,edid=on"
> QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"

So that if I define a value for this, it will be overwritten.

Is there another method for achieving this? If not I could submit a
patch to change poky's definitions to "??" assignments.

Cheers,
--Mike




Appending an existing machine .conf file

Mike Frampton
 

Greetings Yocto,

I'm interested in assigning custom config settings for machine type qemuarm.

I tried a method suggested in this thread
https://lists.yoctoproject.org/g/yocto/message/38359 by Ayoub Zaki, he
suggested defining the following in local.conf

include conf/machine/${MACHINE}-extra.conf
However, this doesn't work for me because quemuarm.conf in poky/meta
**assigns** its variables, e.g.,

QB_OPT_APPEND = "-device VGA,edid=on"
QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
So that if I define a value for this, it will be overwritten.

Is there another method for achieving this? If not I could submit a
patch to change poky's definitions to "??" assignments.

Cheers,
--Mike


[PATCH][meta-rockchip] rock-pi-e: use common rk3328.inc

Trevor Woerner
 

Now that there is a second rk3328-based MACHINE (rock64) switch rock-pi-e to
use the common rk3328 include.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/rock-pi-e.conf | 21 +++------------------
1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf
index 035a950..38362a0 100644
--- a/conf/machine/rock-pi-e.conf
+++ b/conf/machine/rock-pi-e.conf
@@ -3,29 +3,16 @@
#@DESCRIPTION: ROCK Pi E is a Rockchip RK3328-based SBC by Radxa. E is for Ethernets.
#https://wiki.radxa.com/RockpiE

-MACHINEOVERRIDES =. "rock-pi-e:"
-SOC_FAMILY = "rk3328"
-DEFAULTTUNE = "cortexa53-crypto"
+require conf/machine/include/rk3328.inc

-require conf/machine/include/soc-family.inc
-require conf/machine/include/tune-cortexa53.inc
-require conf/machine/include/rockchip-defaults.inc
+MACHINEOVERRIDES =. "rock-pi-e:"

PREFERRED_PROVIDER_virtual/kernel = "linux-stable-bleeding"
KERNEL_DEVICETREE = "rockchip/rk3328-rock-pi-e.dtb"
-KBUILD_DEFCONFIG = "defconfig"
-KERNEL_CLASSES = "kernel-fitimage"
-KERNEL_IMAGETYPE = "fitImage"
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"

-TFA_PLATFORM = "rk3328"
-TFA_BUILD_TARGET = "bl31"
-
-UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"
-UBOOT_SUFFIX = "itb"
-UBOOT_ENTRYPOINT = "0x06000000"
PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
-SPL_BINARY = "idbloader.img"
+UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"

WKS_FILE = "rock-pi-e.wks"
IMAGE_FSTYPES += "wic.xz wic.bmap"
@@ -38,5 +25,3 @@ WKS_FILE_DEPENDS = " \
IMAGE_BOOT_FILES ?= " \
${KERNEL_IMAGETYPE} \
"
-
-SERIAL_CONSOLES = "1500000;ttyS2"
--
2.30.0.rc0


Re: [meta-rockchip][PATCH v3] Rock64: add machine

Trevor Woerner
 

Applied to meta-rockchip master. Thanks! :-)


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

Armin Kuster
 

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.
Thanks. So this is for meta-security layer based on version.

- armin

Signed-off-by: Sekine Shigeki <sekine.shigeki@...>
---
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


3481 - 3500 of 57376