Date   

AUh: upgrading recipes bbppend files only #yocto

ksmanjunath681@...
 

HI ,
I am currently working upgrading  recipes using AUH(Auto Upgrade Helper ) tool where in i am able to upgrade recipes,
custom settings such as SRCBRANCH , SRCREV and SRC_URI in a recipe file of interest.
I am able to upgrade recipes in their recipe(.bb)files only i.e., after completion of upgrade process it is able 
to update SRCREV commit hash to latest in the repo.
If i set the above mentioned variables in extended recipe files(.bbappend)  by removing in main recipe instead,
main recipe file still gets modified/added with variables SRCBRANCH and SRCREV(latest hash) after upgrade process
is completed, leaving behind same variables with previous data which was set, how to make the tool to update extended recipes only.


Thanks & Regards,
Manjunath


#yocto #zeus Best practices for packaging third party recipe tool output in another recipe on the building host #yocto #zeus

VINCI Maxime
 

Hi, I am quite new to Yocto/BitBake and I have a bit of a headache trying to figure out the best way to make use of a native tool in the following context:

I have one recipe that fetch and build third party libs and binaries, let's call it X.
I have another recipe that also fetch and build third party libs and binaries, those depending on X's libs, let's call it Y.
Y needs to run post installation scripts to generate some config files.
Those scripts are calling some of X's binaries to generate those files, therefore I added a dependency on X-native to be able to run those scripts on the building machine.
At the moment, I include those scripts in do_install[postfuncs] of Y-native recipe while adding it as dependency in Y recipe, as I wish those to files to be part of Y package.

Assuming what I am doing until there is alright (correct me if not), here comes my issue:
The way X is configured/compiled involves specifying the path where it will write any file it generates/manage (currently based on the 'datadir' prefix).
This implies that building X-native will also prefix this path with STAGING_DIR_NATIVE in X recipe context.
So, after using X-native binaries from within Y-native recipe I end up generating files in the wrong STAGING_DIR_NATIVE (ie. X recipe context), being unable to easily retrieve those as it's outside of Y recipe context.

Am I missing something here ?
I read about pkg_postinst and deferring them after sysroot creation, but this is not what I need if I wish to package to config files, right ?
If there are no other solution, I may resort not to package them and use this to generate them at image/sdk creation, but this does not seems clean to me.

Also, I wish not to patch X sources to enable some sort of runtime output path configuration.


[meta-zephyr][PATCH] zephyr-image: unify the image generation for tests and samples

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bartosz.golaszewski@...>

Reuse the same code that generates zephyr samples for building tests.
This allows us to generate .bin files in all cases.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
---
.../recipes-kernel/zephyr-kernel/zephyr-image.inc | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc
index c77692d..2d4c6ff 100644
--- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc
+++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc
@@ -1,17 +1,10 @@
-require zephyr-kernel-src.inc
-require zephyr-kernel-common.inc
-
+require zephyr-sample.inc
inherit testimage
-inherit deploy

QEMU_BIN_PATH = "${STAGING_BINDIR_NATIVE}"

ZEPHYR_BASE = "${S}"
OECMAKE_SOURCEPATH = "${S}/${ZEPHYR_SRC_DIR}"

-do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
-}
-
addtask deploy after do_compile
do_install[noexec] = "1"
--
2.30.1


Maintaining ABI Compatibility for LTS branch

Richard Purdie
 

Forwarding to the correct list address and cc the LTS maintainer.

Cheers,

Richard


Can't Locate Module in @INC - you may need to install the Module issue...

bgctkd@...
 

Hello All,

I'm getting an error trying create/use a recipe i created for Pearl Module Const::Fast
It has a Build.PL file as follows:
use 5.0.0.8
use Module::Build::Tiny 0.21;
Build_PL();
 
I have built ModuleBuild::Tiny as well. (meta-cpan has a recipe for Build::Tiny)  And (think I) am placing it as a dependency for Const::Fast. however... 
My issue (or my first Issue)  I guess is how to populate Module Build::Tiny into recipe-sysroot-native.
 
When I attempt to build my recipe I get an error as follows:
 Can't locate Module/Build/Tiny.pm in @INC (you may need to install the Module::Build::Tiny module) (@INC contains: < list of paths it is looking for>)
 
Paths @INC (in build/tmp/work) is using to fine Module/Build/Tiny.pm are along these lines:
/all-poky-linux/const-fast-perl/0.014-r0/recipe-sysroot-native/<paths below>
/usr/lib/perl5/site_perl/5.34.0/x86_64-linux 
/usr/lib/perl5/site_perl/5.34.0 
/usr/lib/perl5/vendor_perl/5.34.0 
/usr/lib/perl5/5.34.0/x86_64-linux 
/usr/lib/perl5/5.34.0 
 
/x86_64-linux/perl-native/5.34.0-r0/recipe-sysroot-native/usr/lib/perl5/<paths below>
/site_perl/5.34.0/x86_64-linux 
/site_perl/5.34.0 
/vendor_perl/5.34.0/x86_64-linux
/vendor_perl/5.34.0
/5.34.0/x86_64-linux
/5.34.0) at Build.PL line 2.
#| BEGIN failed--compilation aborted at Build.PL line 2.
 
Paths the module is found are along these lines (found via manual search):
#./all-poky-linux/module-build-tiny-perl/0.021-r0/sysroot-destdir/usr/lib/perl5/vendor_perl/5.34.0/Module/Build/Tiny.pm
./all-poky-linux/module-build-tiny-perl/0.021-r0/package/usr/lib/perl5/vendor_perl/5.34.0/Module/Build/Tiny.pm
 
 
 
My const-fast Recipe is as follows  const-fast-perl_014.bb:
 
DESCRIPTION = "This module provides Const::Fast Functionality"
SECTION = "libs"
LICENSE = "Artisticv1 | GPLv1+"
PR = "r0"
MAINTAINER= "Poky <poky@...>"
HOMEPAGE= "https://metacpan.org/release/Const-Fast"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Artistic-1.0;md5=cda03bbdc3c1951996392b872397b798 \
file://${COMMON_LICENSE_DIR}/GPL-1.0-or-later;md5=30c0b8a5048cc2f4be5ff15ef0d8cf61"
SRC_URI = "https://cpan.metacpan.org/authors/id/L/LE/LEONT/Const-Fast-0.014.tar.gz"
SRC_URI[sha256sum] = "f805953a08c57846a16a4d85d7b766398afaf7c36c1465fcb1dea09e5fa394db"
S = "${WORKDIR}/Const-Fast-${PV}"
inherit cpan_build allarch
RDEPENDS_${PN} += "extutils-config-perl"
RDEPENDS_${PN} += "extutils-helpers-perl"
RDEPENDS_${PN} += "extutils-installpaths-perl"
DEPENDS += "extutils-config-perl-native"
DEPENDS += "extutils-helpers-perl-native"
DEPENDS += "extutils-installpaths-perl-native"
DEPENDS += "libmodule-build-perl module-build-tiny-perl"
BBCLASSEXTEND = "native"
 
My module-build-tiny-perl_0.021.bb is as follows:
 
DESCRIPTION = "Many Perl distributions use a Build.PL file instead of a Makefile.PL file \
to drive distribution configuration, build, test and installation. \
Traditionally, Build.PL uses Module::Build as the underlying build system. \
This module provides a simple, lightweight, drop-in replacement."
SECTION = "libs"
LICENSE = "Artisticv1 | GPLv1+"
PR = "r0"
MAINTAINER= "Poky <poky@...>"
HOMEPAGE= "https://metacpan.org/release/Module-Build-Tiny"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Artistic-1.0;md5=cda03bbdc3c1951996392b872397b798 \
file://${COMMON_LICENSE_DIR}/GPL-1.0-or-later;md5=30c0b8a5048cc2f4be5ff15ef0d8cf61"
SRC_URI = "https://cpan.metacpan.org/authors/id/L/LE/LEONT/Module-Build-Tiny-0.021.tar.gz"
SRC_URI[sha256sum] = "65e516c2e99d63100fdf4dbfa35489d0562718a0e8d2b885e9daaa7bc174b43e"
RDEPENDS_${PN} += "extutils-config-perl"
RDEPENDS_${PN} += "extutils-helpers-perl"
RDEPENDS_${PN} += "extutils-installpaths-perl"
DEPENDS += "extutils-config-perl-native"
DEPENDS += "extutils-helpers-perl-native"
DEPENDS += "extutils-installpaths-perl-native"
S = "${WORKDIR}/Module-Build-Tiny-${PV}"
inherit cpan_build allarch
BBCLASSEXTEND = "native"

Regards,

Bruce


Re: Zeek recipe

Gary Huband
 

I could never get a Zeek recipe to work.  I resorted to building it on the target, saving the binaries in a repo, then creating a recipe to install the binaries.

Gary


From: yocto@... <yocto@...> on behalf of Paul van Berlo via lists.yoctoproject.org <pvanberlo=gmail.com@...>
Sent: Tuesday, February 8, 2022 11:08 AM
To: yocto@... <yocto@...>
Subject: [yocto] Zeek recipe
 
Hi,

does anyone happen to have a working Zeek recipe? Whatever I do, I cannot get it to compile properly :( 

Regards,

Paul van Berlo

Gary Huband
Sr. Software and Systems Engineer

Office: 434.284.8071 x720
Direct: 434.260.4995
Gary@...

Follow Us!
LinkedIn  |  Blog  |  Website

: : : : : : : : : : : : : : : : : : : : : : : : : : :

MSi

This email and any files transmitted with it are confidential and proprietary and intended solely for the use of the individual or entity to whom they are addressed. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If you received this in error, please contact the sender and delete the material from any computer.


Re: run.do_compile error on poky-dunfell release

Sourabh Hegde
 

Hello Chuck,

Thanks for the hint.

@Khem, when I checked the "sources/poky/meta/recipes-core/kbd", above patch is already available and included in "kbd_2.2.0.bb" recipe. And same patch is also present in "build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0" But still I am getting above error.

I have no idea what this error means and why am I getting this all of a sudden.


Re: run.do_compile error on poky-dunfell release

Chuck Wolber
 

Just replace the word "commit" in the URL with the word patch, like so:


..Ch:W..


On Tue, Feb 8, 2022 at 9:46 AM Sourabh Hegde <hrsourabh011@...> wrote:
Hello Khem,

Thanks for quick response.

Can you please let me know where to include this patch file?

Thanks in advance.




--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: run.do_compile error on poky-dunfell release

Sourabh Hegde
 

Hello Khem,

Thanks for quick response.

Can you please let me know where to include this patch file?

Thanks in advance.


Re: run.do_compile error on poky-dunfell release

Khem Raj
 

On Tue, Feb 8, 2022 at 7:43 AM Sourabh Hegde <hrsourabh011@...> wrote:

Hello All,

When I am bitbaking my custom image for STM32MP1 based Avenger96 board I am facing some errors related to "analyze.l:466:19: error: format not a string literal and no format arguments [-Werror=format-security]". I don't understand why I am getting this error as this is the first I am facing it. Please find the below complete log:

DEBUG: Executing python function autotools_aclocals
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Python function autotools_aclocals finished
DEBUG: Executing shell function do_compile
NOTE: make -j 8
make all-recursive
make[1]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build'
Making all in src
make[2]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src'
Making all in libcommon
make[3]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libcommon'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libcommon'
Making all in libkbdfile
make[3]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkbdfile'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkbdfile'
Making all in libkeymap
make[3]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
make all-am
make[4]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
../../arm-poky-linux-gnueabi-libtool --tag=CC --mode=compile arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../../../kbd-2.2.0/src/libkeymap -I../.. -I../../../kbd-2.2.0/src/libkeymap -I. -I../../../kbd-2.2.0/src/libkeymap/.. -I./.. -I../../../kbd-2.2.0/src/libkeymap/../libcommon -I./../libcommon -I../../../kbd-2.2.0/src/libkeymap/../libkbdfile -I./../libkbdfile -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" -U_GNU_SOURCE -funit-at-a-time -g -O2 -D_FORTIFY_SOURCE=2 -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0 -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0 -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot= -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot-native= -Waggregate-return -Wall -Wcast-align -Wconversion -Wdisabled-optimization -Wextra -Wmissing-declarations -Wmissing-format-attribute -Wmissing-noreturn -Wmissing-prototypes -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -c -o analyze.lo ../../../kbd-2.2.0/src/libkeymap/analyze.c
arm-poky-linux-gnueabi-libtool: compile: arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../../../kbd-2.2.0/src/libkeymap -I../.. -I../../../kbd-2.2.0/src/libkeymap -I. -I../../../kbd-2.2.0/src/libkeymap/.. -I./.. -I../../../kbd-2.2.0/src/libkeymap/../libcommon -I./../libcommon -I../../../kbd-2.2.0/src/libkeymap/../libkbdfile -I./../libkbdfile -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" -U_GNU_SOURCE -funit-at-a-time -g -O2 -D_FORTIFY_SOURCE=2 -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0 -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0 -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot= -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot-native= -Waggregate-return -Wall -Wcast-align -Wconversion -Wdisabled-optimization -Wextra -Wmissing-declarations -Wmissing-format-attribute -Wmissing-noreturn -Wmissing-prototypes -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -c ../../../kbd-2.2.0/src/libkeymap/analyze.c -fPIC -DPIC -o .libs/analyze.o
analyze.l: In function 'find_incl_file_near_fn':
analyze.l:141:24: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char **'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~
analyze.l:141:42: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~~
analyze.l: In function 'find_standard_incl_file':
analyze.l:168:22: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~
analyze.l:168:40: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~~
analyze.l:197:24: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~
analyze.l:197:42: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~~
analyze.l: In function 'find_incl_file':
analyze.l:210:27: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~
analyze.l:210:45: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~~
analyze.l:225:26: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char **'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~
analyze.l:225:36: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
| ~~~~~~~^~~~~~~~
In file included from analyze.l:10:
analyze.l: In function 'yylex':
analyze.l:466:19: error: format not a string literal and no format arguments [-Werror=format-security]
../../../kbd-2.2.0/src/libkeymap/contextP.h:79:55: note: in definition of macro 'lk_log_cond'
79 | lk_log(ctx, level, __FILE__, __LINE__, __func__, ##arg); \
| ^~~
analyze.l:466:6: note: in expansion of macro 'ERR'
cc1: some warnings being treated as errors
make[4]: *** [Makefile:604: analyze.lo] Error 1
make[4]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
make[3]: *** [Makefile:476: all] Error 2
make[3]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
make[2]: *** [Makefile:1083: all-recursive] Error 1
make[2]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src'
make[1]: *** [Makefile:471: all-recursive] Error 1
make[1]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build'
ERROR: oe_runmake failed
make: *** [Makefile:402: all] Error 2
WARNING: exit code 1 from a shell command.
ERROR: Execution of '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/temp/run.do_compile.380' failed with exit code 1

Can anyone please let me know how to fix this issue?

Your help will be much appreciated.

Thanks in advance.


Re: Zeek recipe

Ross Burton <ross@...>
 

On Tue, 8 Feb 2022 at 16:09, Paul van Berlo <pvanberlo@...> wrote:
does anyone happen to have a working Zeek recipe? Whatever I do, I cannot get it to compile properly :(
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=zeek
says most likely not.

Sharing your recipe and the errors would let others help you.

Ross


Zeek recipe

Paul van Berlo <pvanberlo@...>
 

Hi,

does anyone happen to have a working Zeek recipe? Whatever I do, I cannot get it to compile properly :( 

Regards,

Paul van Berlo


Yocto Project Status WW06`22

Stephen Jolley
 

Current Dev Position: YP 3.5 M3

Next Deadline: 21th Feb. 2022 YP 3.5 M3 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M2 has been released.
  • YP 3.1.14 is undergoing QA aiming for release later this week
  • We plan to remove our centos8 autobuilder workers (using stream) since there are regressions being introduced to the distro which aren’t being actively fixed quickly enough for the needs of the autobuilder (e.g. the ability of normal users to use ping). We can’t really recommend this as a build distro for that reason. The alma8 workers are looking more stable and will remain.
  • We are seeing a potential hang issue with make 4.2.1 where kernel or perl builds hang (seen on stream and opensuse 15.3), help/insight in debugging that would be very welcome.
  • Prelink support was removed from master due to it’s planned removal from glibc 2.36.
  • The glibc 2.35 upgrade is blocked on resolving a couple of issues, one test failing using buildtools and another in multilib builds having overlapping files.
  • A new Patchwork is available at https://patchwork.yoctoproject.org/. This new system is running the up to date mainline code and will receive regular updates. The previous unmaintained fork remains up at https://patchwork.openembedded.org/ to preserve history. We are seeking help updating PatchTest to run with the new version.

Everyone can now sign up for an account on the new system. Patchwork project maintainers please email mhalstead@... to have your access restored.

In particular, we’re struggling to understand the intermittent network issue with external hosts we’re seeing very occasionally.

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M2 was released.
  • YP 3.5 M3 build date 2022/02/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.14 is in QA
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

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@...

 


run.do_compile error on poky-dunfell release

Sourabh Hegde
 

Hello All,

When I am bitbaking my custom image for STM32MP1 based Avenger96 board I am facing some errors related to "analyze.l:466:19: error: format not a string literal and no format arguments [-Werror=format-security]". I don't understand why I am getting this error as this is the first I am facing it. Please find the below complete log:

DEBUG: Executing python function autotools_aclocals
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Python function autotools_aclocals finished
DEBUG: Executing shell function do_compile
NOTE: make -j 8
make  all-recursive
make[1]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build'
Making all in src
make[2]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src'
Making all in libcommon
make[3]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libcommon'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libcommon'
Making all in libkbdfile
make[3]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkbdfile'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkbdfile'
Making all in libkeymap
make[3]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
make  all-am
make[4]: Entering directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
../../arm-poky-linux-gnueabi-libtool  --tag=CC   --mode=compile arm-poky-linux-gnueabi-gcc  -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../../../kbd-2.2.0/src/libkeymap -I../..   -I../../../kbd-2.2.0/src/libkeymap -I. -I../../../kbd-2.2.0/src/libkeymap/.. -I./.. -I../../../kbd-2.2.0/src/libkeymap/../libcommon -I./../libcommon -I../../../kbd-2.2.0/src/libkeymap/../libkbdfile -I./../libkbdfile -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" -U_GNU_SOURCE -funit-at-a-time   -g -O2 -D_FORTIFY_SOURCE=2  -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0                      -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0                      -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot=                      -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot-native=  -Waggregate-return -Wall -Wcast-align -Wconversion -Wdisabled-optimization -Wextra -Wmissing-declarations -Wmissing-format-attribute -Wmissing-noreturn -Wmissing-prototypes -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -c -o analyze.lo ../../../kbd-2.2.0/src/libkeymap/analyze.c
arm-poky-linux-gnueabi-libtool: compile:  arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../../../kbd-2.2.0/src/libkeymap -I../.. -I../../../kbd-2.2.0/src/libkeymap -I. -I../../../kbd-2.2.0/src/libkeymap/.. -I./.. -I../../../kbd-2.2.0/src/libkeymap/../libcommon -I./../libcommon -I../../../kbd-2.2.0/src/libkeymap/../libkbdfile -I./../libkbdfile -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" -U_GNU_SOURCE -funit-at-a-time -g -O2 -D_FORTIFY_SOURCE=2 -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0 -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0=/usr/src/debug/kbd/2.2.0-r0 -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot= -fdebug-prefix-map=/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/recipe-sysroot-native= -Waggregate-return -Wall -Wcast-align -Wconversion -Wdisabled-optimization -Wextra -Wmissing-declarations -Wmissing-format-attribute -Wmissing-noreturn -Wmissing-prototypes -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -c ../../../kbd-2.2.0/src/libkeymap/analyze.c  -fPIC -DPIC -o .libs/analyze.o
analyze.l: In function 'find_incl_file_near_fn':
analyze.l:141:24: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char **'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                              ~~~~~~~^~~~~~~
analyze.l:141:42: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                                              ~~~~~~~^~~~~~~~
analyze.l: In function 'find_standard_incl_file':
analyze.l:168:22: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                              ~~~~~~~^~~~~~~
analyze.l:168:40: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                                              ~~~~~~~^~~~~~~~
analyze.l:197:24: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                              ~~~~~~~^~~~~~~
analyze.l:197:42: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                                              ~~~~~~~^~~~~~~~
analyze.l: In function 'find_incl_file':
analyze.l:210:27: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                              ~~~~~~~^~~~~~~
analyze.l:210:45: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                                              ~~~~~~~^~~~~~~~
analyze.l:225:26: warning: passing argument 2 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:37: note: expected 'char **' but argument is of type 'const char **'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                              ~~~~~~~^~~~~~~
analyze.l:225:36: warning: passing argument 3 of 'kbdfile_find' from incompatible pointer type [-Wincompatible-pointer-types]
In file included from ../../../kbd-2.2.0/src/libkeymap/keymap/kmap.h:36,
                 from ../../../kbd-2.2.0/src/libkeymap/keymap.h:8,
                 from ../../../kbd-2.2.0/src/libkeymap/analyze.c:1:
../../../kbd-2.2.0/src/libkeymap/../libkbdfile/kbdfile.h:40:53: note: expected 'char **' but argument is of type 'const char * const*'
   40 | int kbdfile_find(char *fnam, char **dirpath, char **suffixes, struct kbdfile *fp);
      |                                              ~~~~~~~^~~~~~~~
In file included from analyze.l:10:
analyze.l: In function 'yylex':
analyze.l:466:19: error: format not a string literal and no format arguments [-Werror=format-security]
../../../kbd-2.2.0/src/libkeymap/contextP.h:79:55: note: in definition of macro 'lk_log_cond'
   79 |    lk_log(ctx, level, __FILE__, __LINE__, __func__, ##arg); \
      |                                                       ^~~
analyze.l:466:6: note: in expansion of macro 'ERR'
cc1: some warnings being treated as errors
make[4]: *** [Makefile:604: analyze.lo] Error 1
make[4]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
make[3]: *** [Makefile:476: all] Error 2
make[3]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src/libkeymap'
make[2]: *** [Makefile:1083: all-recursive] Error 1
make[2]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build/src'
make[1]: *** [Makefile:471: all-recursive] Error 1
make[1]: Leaving directory '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/build'
ERROR: oe_runmake failed
make: *** [Makefile:402: all] Error 2
WARNING: exit code 1 from a shell command.
ERROR: Execution of '/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0/temp/run.do_compile.380' failed with exit code 1

Can anyone please let me know how to fix this issue?

Your help will be much appreciated.

Thanks in advance.


Re: [meta-anaconda][PATCH] Update SRC_URI git default branch

kai
 

On 1/21/22 2:10 PM, Changqing Li wrote:
From: Changqing Li <changqing.li@...>

Signed-off-by: Changqing Li <changqing.li@...>

Merged.

Thanks,
Kai

---
 recipes-installer/python3-dasbus/python3-dasbus_1.6.bb         | 2 +-
 recipes-installer/python3-productmd/python3-productmd_1.21.bb  | 2 +-
 recipes-installer/python3-simpleline/python3-simpleline_1.3.bb | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb b/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb
index c42ab52..5b87391 100644
--- a/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb
+++ b/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb
@@ -4,7 +4,7 @@ SECTION = "devel"
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=1803fa9c2c3ce8cb06b4861d75310742"
 
-SRC_URI = "git://github.com/rhinstaller/dasbus.git;protocol=https;"
+SRC_URI = "git://github.com/rhinstaller/dasbus.git;protocol=https;branch=master"
 SRCREV = "63b22fe4a7b2f98739279b2a4c6107eebd8d5a58"
 
 S = "${WORKDIR}/git"
diff --git a/recipes-installer/python3-productmd/python3-productmd_1.21.bb b/recipes-installer/python3-productmd/python3-productmd_1.21.bb
index 98fd0de..8dcd434 100644
--- a/recipes-installer/python3-productmd/python3-productmd_1.21.bb
+++ b/recipes-installer/python3-productmd/python3-productmd_1.21.bb
@@ -6,7 +6,7 @@ SECTION = "devel"
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=768997ba510a952bef1775c50bc22b00"
 
-SRC_URI = "git://github.com/release-engineering/productmd;protocol=https; \
+SRC_URI = "git://github.com/release-engineering/productmd;protocol=https;branch=master \
            file://add-wrlinux-version-pattern.patch \
            "
 SRCREV = "a8268944c8a6064697ccb4d24e52dc666ab03ed4"
diff --git a/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb b/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb
index dcf7e1d..651b9d0 100644
--- a/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb
+++ b/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb
@@ -6,7 +6,7 @@ SECTION = "devel"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=5f4f48e95324081879552f19cd16c54a"
 
-SRC_URI = "git://github.com/rhinstaller/python-simpleline;protocol=https;"
+SRC_URI = "git://github.com/rhinstaller/python-simpleline;protocol=https;branch=master"
 SRCREV = "1c21ffdeda9eed27e5ad8ec16aee467f8daecd50"
 S = "${WORKDIR}/git"
 inherit setuptools3




-- 
Kai Kang
Wind River Linux


M+ & H bugs with Milestone Movements WW06

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5322

Global DNS fallback mechanism not present in poky distro

randy.macleod@...

kai.kang@...

3.5 M2

3.5 M3

 

11704

Add other resource monitoring options to conf/local.conf STOPTASKS/ABORT

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M3

 

12060

It is possible to specify a PACKAGE and a PKG_ rename that conflict

randy.macleod@...

kai.kang@...

3.5 M2

3.5 M3

 

12279

enhance manifest not found warning

randy.macleod@...

kai.kang@...

3.5 M2

3.5 M4

 

13311

xargs: fdleak.c:396: complain_about_leaky_fds: Assertion `no_leaks' failed.

randy.macleod@...

mingli.yu@...

3.5 M2

3.5 M3

 

13520

many valgrind tests fail for arm64

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M3

 

13508

Meson detects googletest installed on system

randy.macleod@...

hongxu.jia@...

3.5 M2

3.5 M4

 

13550

username/password specified to gitsm:// does not get propagated to submodules

randy.macleod@...

unassigned@...

3.5 M2

3.5 M3

 

13766

Using TCLIB=musl results in SDKs producing incompatible binaries

randy.macleod@...

sakib.sajal@...

3.5 M2

3.5 M3

 

14126

resolvconf incompatible with busybox flock

randy.macleod@...

newcomer@...

3.5 M2

3.5 M3

 

14339

bitbake generates zombie Parser processes (hard to reproduce)

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M4

 

14430

valgrind memcheck/tests/linux/stack_changes failure

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M4

 

14443

valgrind none/tests/amd64/fb_test_amd64 ptest intermittent failure

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M4

 

14523

oe-pkgdata-util list-pkg-files doesn't ignore target-sdk-provides-dummy.bb

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M4

 

14538

Recipes shouldn't use "virtual/" in RPROVIDES and RDEPENDS

randy.macleod@...

randy.macleod@...

3.5 M2

3.5 M3

 

14553

insane.bbclass: host-user-contaminated QA doesn't skip the home directory

randy.macleod@...

unassigned@...

3.5 M2

3.5 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW06!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

5

saul.wold@...

1

steve@...

1

richard.purdie@...

1

michael.opdenacker@...

1

alejandro@...

1

ross@...

1

Grand Total

11

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.5

Stephen Jolley
 

All,

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

Who

Count

ross@...

35

michael.opdenacker@...

34

randy.macleod@...

24

david.reyna@...

22

bruce.ashfield@...

17

sakib.sajal@...

13

tim.orling@...

13

trevor.gamblin@...

12

richard.purdie@...

10

mhalstead@...

9

kai.kang@...

7

bluelightning@...

6

saul.wold@...

5

hongxu.jia@...

4

pokylinux@...

4

JPEWhacker@...

4

chee.yang.lee@...

4

jon.mason@...

3

Qi.Chen@...

3

alexandre.belloni@...

2

mshah@...

2

pgowda.cve@...

2

raj.khem@...

2

pavel@...

2

alejandro@...

2

jaskij@...

1

kexin.hao@...

1

mingli.yu@...

1

nicolas.dechesne@...

1

thomas.perrot@...

1

Martin.Jansa@...

1

liezhi.yang@...

1

aehs29@...

1

andrei@...

1

matthewzmd@...

1

yf3yu@...

1

mark.hatle@...

1

jay.shen.teoh@...

1

mostthingsweb@...

1

TicoTimo@...

1

shachar@...

1

yoctoproject@...

1

john.kaldas.enpj@...

1

yi.zhao@...

1

open.source@...

1

akuster808@...

1

Grand Total

262

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 400 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.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

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: patching files under "dynamic-layers"

Monsees, Steven C (US)
 

 

Never mind was able to work this out…

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Monday, February 7, 2022 10:42 AM
To: yocto@...
Subject: [yocto] patching files under "dynamic-layers"

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I am building with zeus 3.0.4, Intel based…

 

I trying to learn how to introduce a patch to files brought in by packages under “dynamic –layers”… my bbappend appears not to be applying my test patch (even though no errors/warnings thrown)…

 

This is the package I am trying to manipulate:

 

/disk0/scratch/smonsees/yocto/workspace_3/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc

It contains:

files  intel-graphics-compiler_1.0.11.bb

 

This is my recipe to apply patch:

 

/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc

It contains:

files  intel-graphics-compiler_1.0.11.bbappend

 

files - contains the file I am attempting to patch (FILE_TO_PATCH.patch)

intel-graphics-compiler_1.0.11.bbappend is setup like so, where

 

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

 

SRC_URI += "\

    file://FILE_TO_PATCH.patch \

"

 

I attempted to male use of BBFILES_DYNAMIC but even though I get no error, patch is not applied.

 

conf/layer.conf:

BBFILES_DYNAMIC += " \

    clang-layer:$(LAYERDIR)/dynamic-layers/clang-layer/recipes-opencl/igc/*.bbappend \

"

 

Can you explain to me the proper way to patch files under these circumstances and where I went wrong ?

 

Thanks,

Steve

 

1721 - 1740 of 57790