|
#sdk -Standard SDK build with cmake and meta-clang gives error when I attempt topull in compiler-rt
#sdk
Monsees, Steven C (US)
I am having trouble configuring my SDK to use the meta-clang compiler-rt component properly.
How do I configure my build so meta-clang brings in compiler-rt and generates the libclang_rt.binutils-x86_64.a library I require?
When I attempt to build in “compiler-rt” component I get the CMAKE Error shown below.
No matter how I try, for example:
TOOLCHAIN_TARGET_TASK_append = "compiler-rt-static-dev compiler-rt-dev"
Or:
SDK_EXTRA_TOOLS = " \ nativesdk-cmake \ nativesdk-clang \ nativesdk-compiler-rt \ " I get the "cmake" error described below.
(1) What Is this the correct method to add this components to my SDK ? (2) I do not understand how to resolve this , all are yocto based components, the only llvm components are pulled in by meta-clang, what am I expected to edit to resolve ?, and how ? Can someone explain to me what this error is attempting to convey, and what I am doing wrong ? (3) Is it correct to expect the cmake and clang components to work together under yocto? (4) I do not want the tools built into my kernel just the SDK for development, Is there better way to do what I want to do here ?
Note: My target and host systems are both x86-64…
And, yes, the "-rtlib-libgcc" works for my basic test code and bypasses requiring compiler-rt, but I would like to understand what is going on below and be able to build correctly...
Synopsis of issue: -----------------------
When I build my SDK, I setup the following:
SDKMACHINE = "x86_64" SDKIMAGE_FEATURES_append = " staticdev-pkgs" TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}" SDK_EXTRA_TOOLS = " \ nativesdk-cmake \ nativesdk-clang \ " require conf/distro/include/yocto-uninative.inc INHERIT += "uninative"
My SDK builds and installs without issue…
Running a very basic example produces the following issue:
09:22 smonsees@yix490016 ~/yocto/test>make hello x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -ansi -c hello.c x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -ansi hello.o -o hello clang-5.0: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument] /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: cannot find /disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/clang/5.0.1/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [hello] Error 1 09:22 smonsees@yix490016 ~/yocto/test>
The file in question does not exist on my system.
If I add "nativesdk-compiler-rt" like so:
SDK_EXTRA_TOOLS = " \ nativesdk-cmake \ nativesdk-clang \ nativesdk-compiler-rt \ "
I get the following error:
Log data follows: | DEBUG: Executing shell function do_configure | -- The C compiler identification is GNU 7.3.0 | -- The CXX compiler identification is GNU 7.3.0 | -- The ASM compiler identification is GNU | -- Found assembler: | /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s | bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler | -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6 | 4-pokysdk-linux/x86_64-pokysdk-linux-gcc | -- Check for working C compiler: | /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s | bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler | -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6 | 4-pokysdk-linux/x86_64-pokysdk-linux-gcc | -- Check for working C compiler: | /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s | bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler | -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6 | 4-pokysdk-linux/x86_64-pokysdk-linux-gcc -- works | -- Detecting C compiler ABI info | -- Detecting C compiler ABI info - done | -- Detecting C compile features | -- Detecting C compile features - done | -- Check for working CXX compiler: | /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s | bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler | -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6 | 4-pokysdk-linux/x86_64-pokysdk-linux-g++ | -- Check for working CXX compiler: | /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s | bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler | -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6 | 4-pokysdk-linux/x86_64-pokysdk-linux-g++ -- works | -- Detecting CXX compiler ABI info | -- Detecting CXX compiler ABI info - done | -- Detecting CXX compile features | -- Detecting CXX compile features - done | -- Looking for unwind.h | -- Looking for unwind.h - found | CMake Error at CMakeLists.txt:38 (find_package): | By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has | asked CMake to find a package configuration file provided by "LLVM", but | CMake did not find one. | | Could not find a package configuration file provided by "LLVM" with any of | the following names: | | LLVMConfig.cmake | llvm-config.cmake | | Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set | "LLVM_DIR" to a directory containing one of the above files. If "LLVM" | provides a separate development package or SDK, be sure it has been | installed. | | | -- Configuring incomplete, errors occurred! | See also "/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/build/CMakeFiles/CMakeOutput.log". | WARNING: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/run.do_configure.25988:1 exit 1 from 'cmake $oecmake_sitefile /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/git -DCMAKE_INSTALL_PREFIX:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=bin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DCOMPILER_RT_STANDALONE_BUILD=ON -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=x86_64-pokysdk-linux -DCOMPILER_RT_BUILD_XRAY=OFF -G Ninja ${PACKAGECONFIG_CONFARGS} -DLLVM_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/llvm-tblgen -DCLANG_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/clang-tblgen -Wno-dev' | ERROR: Function failed: do_configure (log file is located at | /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s | bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler | -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.25988) ERROR: Task (virtual:nativesdk:/disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 5382 tasks of which 5341 didn't need to be rerun and 1 failed.
Thanks, Steve
|
|
|
|
[meta-security][dunfel][PATCH] trousers: Several Security fixes
From: Armin Kuster <akuster@...>
Source: meta-security MR: 105088 Type: Security Fix Disposition: Backport from http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=787ba6faeaa8823a4d87e5edd15581cb4e12fa70 ChangeID: b55bccb002b9eb2c49dfe380406e2597bb1ade90 Description: Fixes: CVE-2020-24332 CVE-2020-24330 CVE-2020-24331 Signed-off-by: Armin Kuster <akuster@...> Signed-off-by: Armin Kuster <akuster808@...> (cherry picked from commit 787ba6faeaa8823a4d87e5edd15581cb4e12fa70) Signed-off-by: Armin Kuster <akuster@...> --- ...-security-issues-that-are-present-if.patch | 94 +++++++++++++++++++ meta-tpm/recipes-tpm/trousers/trousers_git.bb | 1 + 2 files changed, 95 insertions(+) create mode 100644 meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch diff --git a/meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch b/meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch new file mode 100644 index 0000000..72c81d1 --- /dev/null +++ b/meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch @@ -0,0 +1,94 @@ +From e74dd1d96753b0538192143adf58d04fcd3b242b Mon Sep 17 00:00:00 2001 +From: Matthias Gerstner <mgerstner@...> +Date: Fri, 14 Aug 2020 22:14:36 -0700 +Subject: [PATCH] Correct multiple security issues that are present if the tcsd + is started by root instead of the tss user. + +Patch fixes the following 3 CVEs: + +CVE-2020-24332 +If the tcsd daemon is started with root privileges, +the creation of the system.data file is prone to symlink attacks + +CVE-2020-24330 +If the tcsd daemon is started with root privileges, +it fails to drop the root gid after it is no longer needed + +CVE-2020-24331 +If the tcsd daemon is started with root privileges, +the tss user has read and write access to the /etc/tcsd.conf file + +Authored-by: Matthias Gerstner <mgerstner@...> +Signed-off-by: Debora Velarde Babb <debora@...> + +Upstream-Status: Backport +CVE: CVE-2020-24332 +CVE: CVE-2020-24330 +CVE: CVE-2020-24331 + +Signed-off-by: Armin Kuster <akuster@...> + +--- + src/tcs/ps/tcsps.c | 2 +- + src/tcsd/svrside.c | 1 + + src/tcsd/tcsd_conf.c | 10 +++++----- + 3 files changed, 7 insertions(+), 6 deletions(-) + +Index: git/src/tcs/ps/tcsps.c +=================================================================== +--- git.orig/src/tcs/ps/tcsps.c ++++ git/src/tcs/ps/tcsps.c +@@ -72,7 +72,7 @@ get_file() + } + + /* open and lock the file */ +- system_ps_fd = open(tcsd_options.system_ps_file, O_CREAT|O_RDWR, 0600); ++ system_ps_fd = open(tcsd_options.system_ps_file, O_CREAT|O_RDWR|O_NOFOLLOW, 0600); + if (system_ps_fd < 0) { + LogError("system PS: open() of %s failed: %s", + tcsd_options.system_ps_file, strerror(errno)); +Index: git/src/tcsd/svrside.c +=================================================================== +--- git.orig/src/tcsd/svrside.c ++++ git/src/tcsd/svrside.c +@@ -473,6 +473,7 @@ main(int argc, char **argv) + } + return TCSERR(TSS_E_INTERNAL_ERROR); + } ++ setgid(pwd->pw_gid); + setuid(pwd->pw_uid); + #endif + #endif +Index: git/src/tcsd/tcsd_conf.c +=================================================================== +--- git.orig/src/tcsd/tcsd_conf.c ++++ git/src/tcsd/tcsd_conf.c +@@ -743,7 +743,7 @@ conf_file_init(struct tcsd_config *conf) + #ifndef SOLARIS + struct group *grp; + struct passwd *pw; +- mode_t mode = (S_IRUSR|S_IWUSR); ++ mode_t mode = (S_IRUSR|S_IWUSR|S_IRGRP); + #endif /* SOLARIS */ + TSS_RESULT result; + +@@ -798,15 +798,15 @@ conf_file_init(struct tcsd_config *conf) + } + + /* make sure user/group TSS owns the conf file */ +- if (pw->pw_uid != stat_buf.st_uid || grp->gr_gid != stat_buf.st_gid) { ++ if (stat_buf.st_uid != 0 || grp->gr_gid != stat_buf.st_gid) { + LogError("TCSD config file (%s) must be user/group %s/%s", tcsd_config_file, +- TSS_USER_NAME, TSS_GROUP_NAME); ++ "root", TSS_GROUP_NAME); + return TCSERR(TSS_E_INTERNAL_ERROR); + } + +- /* make sure only the tss user can manipulate the config file */ ++ /* make sure only the tss user can read (but not manipulate) the config file */ + if (((stat_buf.st_mode & 0777) ^ mode) != 0) { +- LogError("TCSD config file (%s) must be mode 0600", tcsd_config_file); ++ LogError("TCSD config file (%s) must be mode 0640", tcsd_config_file); + return TCSERR(TSS_E_INTERNAL_ERROR); + } + #endif /* SOLARIS */ diff --git a/meta-tpm/recipes-tpm/trousers/trousers_git.bb b/meta-tpm/recipes-tpm/trousers/trousers_git.bb index fe8f557..95e821b 100644 --- a/meta-tpm/recipes-tpm/trousers/trousers_git.bb +++ b/meta-tpm/recipes-tpm/trousers/trousers_git.bb @@ -16,6 +16,7 @@ SRC_URI = " \ file://tcsd.service \ file://get-user-ps-path-use-POSIX-getpwent-instead-of-getpwe.patch \ file://0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch \ + file://0001-Correct-multiple-security-issues-that-are-present-if.patch \ " S = "${WORKDIR}/git" -- 2.17.1 |
|
|
|
Re: Additional log handler
Konrad Weihmann <kweihmann@...>
Thanks to both of you - seems like I missed out on BB_LOGCONFIG, but it's exactly what I was looking for.
toggle quoted message
Show quoted text
Regards Konrad On 24.08.20 15:59, Joshua Watt wrote:
On 8/24/20 8:26 AM, Richard Purdie wrote:On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:Ah, right; you jogged my memory :) Structured logging still co-exists with the debug_domains, so it's not the *only* way the core speicfies logging messages. The main reason for this is that we still need to pass the set of active logging domains to the bitbake workers that they only send back requested logging levels over IPC instead of all log levels (per some code I believe you wrote Richard). It should the theoretically possible to send over the entire structured log config (which isn't very large) to the worker and add in worker side handlers to send back logs over IPC instead of the simplified list of logging domains (as a bonus, this should allow you to log anything on the worker, not just things in the "BitBake" domain). IIRC I tried to get this working in the original change, but it ended up being more complicated and not strictly necessary for the feature at hand (extra logging hashequiv on the AB) so I left in the debug_domain method of filtering in the workers. Since I had to leave that in, I also left in the UI code to directly deal with the debug domains. The log handling itself still all goes through Python logging, and it correctly merges the structured logging and user domains so that the actual logging domain level filter level passed to the workers is the lower of the user specified logging domain and whatever is specified for that domain in the structured config. The UI code could fairly easily be converted to instead map the command line arguments to structured logging configuration, which would remove any knowledge of them on the UI side.The newer log handling uses Python's structure logging configurationOn a slightly different but related note, could we remove the |
|
|
|
Re: Yocto standard SDK/cmake/ and meta-clang build issue
Mikko Rapeli <mikko.rapeli@...>
Hi,
On Mon, Aug 24, 2020 at 02:38:54PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote: I was wondering on same thing few days ago. nativesdk-clang and clang-cross-canadian-aarch64 if your target arch is aarch64 bring a working clang compiler to the SDK. I was also missing the clang-cross bit for a long time and scratching my head. Hope this helps, -Mikko |
|
|
|
Yocto standard SDK/cmake/ and meta-clang build issue
Monsees, Steven C (US)
I am having trouble with configuring my SDK for meta-clang…
When I build my SDK, I setup the following:
SDKMACHINE = "x86_64" SDKIMAGE_FEATURES_append = " staticdev-pkgs" TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}" SDK_EXTRA_TOOLS = " \ nativesdk-cmake \ nativesdk-clang \ " require conf/distro/include/yocto-uninative.inc INHERIT += "uninative"
(1) Is this the correct method to add these components to my SDK ?
My SDK builds and installs without issue…
Running a very basic example produces the following issue:
09:22 smonsees@yix490016 ~/yocto/test>make hello x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -ansi -c hello.c x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -ansi hello.o -o hello clang-5.0: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument] /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: cannot find /disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/clang/5.0.1/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [hello] Error 1 09:22 smonsees@yix490016 ~/yocto/test>
The file in question does not exist on my system.
If I add "nativesdk-compiler-rt" like so:
SDK_EXTRA_TOOLS = " \ nativesdk-cmake \ nativesdk-clang \ nativesdk-compiler-rt \ "
I get the following error:
Log data follows: | DEBUG: Executing shell function do_configure | -- The C compiler identification is GNU 7.3.0 | -- The CXX compiler identification is GNU 7.3.0 | -- The ASM compiler identification is GNU | -- Found assembler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-gcc | -- Check for working C compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-gcc | -- Check for working C compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-gcc -- works | -- Detecting C compiler ABI info | -- Detecting C compiler ABI info - done | -- Detecting C compile features | -- Detecting C compile features - done | -- Check for working CXX compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-g++ | -- Check for working CXX compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-g++ -- works | -- Detecting CXX compiler ABI info | -- Detecting CXX compiler ABI info - done | -- Detecting CXX compile features | -- Detecting CXX compile features - done | -- Looking for unwind.h | -- Looking for unwind.h - found | CMake Error at CMakeLists.txt:38 (find_package): | By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has | asked CMake to find a package configuration file provided by "LLVM", but | CMake did not find one. | | Could not find a package configuration file provided by "LLVM" with any of | the following names: | | LLVMConfig.cmake | llvm-config.cmake | | Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set | "LLVM_DIR" to a directory containing one of the above files. If "LLVM" | provides a separate development package or SDK, be sure it has been | installed. | | | -- Configuring incomplete, errors occurred! | See also "/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/build/CMakeFiles/CMakeOutput.log". | WARNING: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/run.do_configure.25988:1 exit 1 from 'cmake $oecmake_sitefile /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/git -DCMAKE_INSTALL_PREFIX:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=bin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DCOMPILER_RT_STANDALONE_BUILD=ON -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=x86_64-pokysdk-linux -DCOMPILER_RT_BUILD_XRAY=OFF -G Ninja ${PACKAGECONFIG_CONFARGS} -DLLVM_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/llvm-tblgen -DCLANG_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/clang-tblgen -Wno-dev' | ERROR: Function failed: do_configure (log file is located at /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.25988) ERROR: Task (virtual:nativesdk:/disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 5382 tasks of which 5341 didn't need to be rerun and 1 failed.
(2) I do not understand how to resolve this , all are yocto based components, the only llvm components are pulled in by meta-clang, what am I expected to edit to resolve ?, and how ? Can someone explain to me what this error is attempting to convey, and what I am doing wrong ? (3) Is it correct to expect the cmake and clang components to work together under yocto? (4) I do not want the tools built into my kernel just the SDK for development, Is there better way to do what I want to do here ?
Thanks, Steve
|
|
|
|
Re: ABI Version for MIPS platform changed from 0 to 5
Your solution worked great! Thank you for that as I don't think I would have tracked that down soon. I now have a follow on problem that I have not been able to solve yet - mostly because my knowledge of the GNU toolchain is not very deep. This problem only shows up in my Dunfell MIPS build - I also maintain x86_64, AARCH64, and ARM platforms. I use the SDK to build some proprietary apps. I have a library libcommon.so that contains many functions used by the proprietary apps. I have an app that uses only a few of the functions in libcomon.so and none of those functions have any further dependencies. When I try to link the app using the Dunfell MIPS SDK, it looks like the linker is including every function in libcommon.so into my app. Many of the unused functions have further dependencies on other libraries which I do not link in because this app isn't using any of those functions. I've tried everything I can think of to fix this link failure, but no luck. I assume I'm missing some linker flag now required in Dunfell, but I don't know which one. Any thoughts on how to fix my linker failure? Thanks, Mike On Thu, Aug 20, 2020 at 8:04 PM Khem Raj <raj.khem@...> wrote: On Wed, Aug 19, 2020 at 3:08 AM MikeB <mabnhdev@...> wrote: |
|
|
|
Re: Additional log handler
Joshua Watt
On 8/24/20 8:26 AM, Richard Purdie wrote:
On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:Ah, right; you jogged my memory :) Structured logging still co-exists with the debug_domains, so it's not the *only* way the core speicfies logging messages. The main reason for this is that we still need to pass the set of active logging domains to the bitbake workers that they only send back requested logging levels over IPC instead of all log levels (per some code I believe you wrote Richard). It should the theoretically possible to send over the entire structured log config (which isn't very large) to the worker and add in worker side handlers to send back logs over IPC instead of the simplified list of logging domains (as a bonus, this should allow you to log anything on the worker, not just things in the "BitBake" domain). IIRC I tried to get this working in the original change, but it ended up being more complicated and not strictly necessary for the feature at hand (extra logging hashequiv on the AB) so I left in the debug_domain method of filtering in the workers. Since I had to leave that in, I also left in the UI code to directly deal with the debug domains. The log handling itself still all goes through Python logging, and it correctly merges the structured logging and user domains so that the actual logging domain level filter level passed to the workers is the lower of the user specified logging domain and whatever is specified for that domain in the structured config. The UI code could fairly easily be converted to instead map the command line arguments to structured logging configuration, which would remove any knowledge of them on the UI side.The newer log handling uses Python's structure logging configurationOn a slightly different but related note, could we remove the TL;DR No, we can't remove it yet, but we could with some work.
|
|
|
|
meta-security
Massimo Anghilieri
Hello, I'm working with Yocto Sumo, I've successfully built and included in my image the sssd from meta-secutrity layer.
Now I need also SELimux in my image, but when including SELIinux I get the a do_configure failure for the SSSD package. I've atttached the log file form bitbake. Can you pleass help me solving the problem? Thank you very much Massimo |
|
|
|
Re: Additional log handler
Richard Purdie
On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:
The newer log handling uses Python's structure logging configurationOn a slightly different but related note, could we remove the debug_domains code now? I assume that can all be handled by BB_LOGCONFIG? Cheers, Richard |
|
|
|
Re: Additional log handler
Joshua Watt
On 8/24/20 3:53 AM, Richard Purdie
wrote:
On Sun, 2020-08-23 at 17:01 +0200, Konrad Weihmann wrote:Hi all, when running bitbake in CI I would like to add an additional log handler to used python logging to catch *ALL* (task warnings, dangling append, qa issues, a.s.o.), instead of manually grepping through the console log. The information coming from this should be ideally be written to a file, file, which can then serve as some sort of report. Is there a way to do that? In theory it should be possible to hook to an (obviously non- existing) event and handle it from there, right? Or am I thinking in the wrong direction? Any pointers are appreciated from my side...On the autobuilder the code simple watches the console log, filtering on WARNING: and produces a separate warning stream. A non empty file triggers the build to show a having warnings. At the bitbake level it would also definitely be possible, the log messages are seen in the UI code as events and it can do whatever it wants with them. There was a also much more advanced log handling added recently through the BB_LOGCONFIG variable. I'm not sure if that can define a completely separate stream or not, I've not tried that. The newer log handling uses Python's structure logging configuration [1], so you should be able to use whatever capabilities it has (including logging different domains/levels to a separate file). In fact, this is the only way logging is handled by core bitbake now; all of the other logging mechanisms used by the UI are additional configuration specified on top of the user's BB_LOGCONFIG file. If you are interested, you can see this in bitbake/lib/bb/ui/knotty.py. In that file is an additional tool that might be helpful. Around line 553, there are two commented lines of code: #import logging_tree uncommenting them and installing the logging_tree python package
will make bitbake dump the entire structured logging configuration
to stdout on startup so you can look at it.
[1]: https://docs.python.org/3/library/logging.config.html Cheers, Richard |
|
|
|
Re: [PATCH 0/3] yocto-bsp/poky: kernel updates and default
Bruce Ashfield
On Sun, Aug 23, 2020 at 11:23 PM Mittal, Anuj <anuj.mittal@...> wrote: Hi Bruce, Yup. I take it that no one has been building that lately, since 5.0 zero has been gone for a while. I'll take the action to check that out and make the changes. I'll do it along with some -rt preferred versions. Bruce Thanks, - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II |
|
|
|
Re: Yocto uses older PV instead of newest - how to figure out why?
Quentin Schulz
Hi Oliver,
On August 24, 2020 2:02:26 PM GMT+02:00, Oliver Westermann <oliver.westermann@...> wrote: Hey,Everything I wanted to say is in this stack overflow answer: https://stackoverflow.com/a/37180291 If what Robert just answered isn't helping, this will (worth a read at least 😉). If all have been checked but you still couldn't figure it out, at least we got the obvious out of the way 🙂 BR, Quentin -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
|
|
Re: Yocto uses older PV instead of newest - how to figure out why?
Robert P. J. Day
Quoting Oliver Westermann <oliver.westermann@...>:
Hey,Could it have something to do with layer priorities? Use the "bitbake-layers" utility to display where recipes are being pulled from. rday |
|
|
|
Yocto uses older PV instead of newest - how to figure out why?
Oliver Westermann
Hey, I assumed yocto would use the newer version, but it uses 0.2 for some reason and I can't figure out why: I 'grep'ed' everything and could not find any reference to this package which has some version requirements. |
|
|
|
Re: Additional log handler
Richard Purdie
On Sun, 2020-08-23 at 17:01 +0200, Konrad Weihmann wrote:
Hi all,On the autobuilder the code simple watches the console log, filtering on WARNING: and produces a separate warning stream. A non empty file triggers the build to show a having warnings. At the bitbake level it would also definitely be possible, the log messages are seen in the UI code as events and it can do whatever it wants with them. There was a also much more advanced log handling added recently through the BB_LOGCONFIG variable. I'm not sure if that can define a completely separate stream or not, I've not tried that. Cheers, Richard |
|
|
|
Re: Additional log handler
Cardenas Jose Antonio (JCARDENA)
Hi Konrad,
toggle quoted message
Show quoted text
Every task has a log file in their correspondent recipe workdir that normally it is indicated by yocto when a recipe fails in the error message. Anyway you always can redirect the bitbake output to file with linux pipes. By this way: bitbake <recipe> > file.txt You can find more information. https://www.howtogeek.com/299219/how-to-save-the-output-of-a-command-to-a-file-in-bash-aka-the-linux-and-macos-terminal/ I hope it helps. Regards. Jose. -----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Konrad Weihmann via lists.yoctoproject.org Sent: domingo, 23 de agosto de 2020 17:02 To: yocto@... Subject: [yocto] Additional log handler CAUTION: This email originated from outside the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi all, when running bitbake in CI I would like to add an additional log handler to used python logging to catch *ALL* (task warnings, dangling append, qa issues, a.s.o.), instead of manually grepping through the console log. The information coming from this should be ideally be written to a file, which can then serve as some sort of report. Is there a way to do that? In theory it should be possible to hook to an (obviously non-existing) event and handle it from there, right? Or am I thinking in the wrong direction? Any pointers are appreciated from my side... Regards Konrad |
|
|
|
Re: [PATCH 0/3] yocto-bsp/poky: kernel updates and default
Anuj Mittal
Hi Bruce,
On Fri, 2020-08-21 at 15:07 -0400, Bruce Ashfield wrote: From: Bruce Ashfield <bruce.ashfield@...>Should we also update PREFERRED_VERSION for linux-yocto-tiny for poky- tiny DISTRO? It is currently pointing to 5.0 ... Thanks, Anuj Cheers, |
|
|
|
Cannot boot with systemd : Must be superuser to use mount
aiman.najjar@...
Hello all - I'm a beginner Ycoto user and I'm trying to build raspberrypi4-64 image for my project. I've been able to build an image and boot it successfully initially, but when I switched from sysvinit to systemd, and enable U-Boot, I'm not longer able to boot. During boot process, I noticed all systemd services that try to mount partitions are failing, including the following: Copy
When I use the emergency shell to check the logs of those systemd services, I am seeing this error:
I even tried to manually mount partitions in the emergency shell using the mount command, and I got the same error, when I run Furthermore, when I list the files in the rootfs, everything is owned by uid 1000, including I would really appreciate any help, I cannot find anything online regarding this issue. Please see below my conf/local.conf: DISTRO_FEATURES += " ${DISTRO_FEATURES_LIBC} wifi ipv4 virtualization systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
MACHINE_FEATURES_remove = "apm"
IMAGE_FSTYPES = "rpi-sdimg"
MACHINE = "raspberrypi4-64"
DISABLE_SPLASH = "1"
ENABLE_UART = "1"
RPI_USE_U_BOOT = "1"
PREFERRED_VERSION_linux-raspberrypi = "5.4.%"
DISTRO = "poky"
PACKAGE_CLASSES = "package_ipk"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
IMAGE_INSTALL_append = " wpa-supplicant docker-ce python3-docker-compose openssh avahi-daemon kernel-image kernel-devicetree"
|
|
|
|
Additional log handler
Konrad Weihmann <kweihmann@...>
Hi all,
when running bitbake in CI I would like to add an additional log handler to used python logging to catch *ALL* (task warnings, dangling append, qa issues, a.s.o.), instead of manually grepping through the console log. The information coming from this should be ideally be written to a file, which can then serve as some sort of report. Is there a way to do that? In theory it should be possible to hook to an (obviously non-existing) event and handle it from there, right? Or am I thinking in the wrong direction? Any pointers are appreciated from my side... Regards Konrad |
|
|
|
[ANNOUNCEMENT] Yocto Project 3.0.4 (zeus 22.0.4) Released
Vineela
Hello,
We are pleased to announce the Yocto Project 3.0.4 (zeus-22.0.4) Release is now available for download. http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/poky-zeus-22.0.4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.0.4/poky-zeus-22.0.4.tar.bz2 A gpg signed version of these release notes is available at: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/RELEASENOTES Full Test Report: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/testreport.txt Thank you for everyone's contributions to this release. Sincerely, Vineela Tummalapalli Yocto Project Build and Release vineela.tummalapalli@... -------------------------- yocto-3.0.4 Release Notes -------------------------- -------------------------- Repositories/Downloads -------------------------- Repository Name: poky Repository Location: https://git.yoctoproject.org/git/poky Branch: zeus Tag: yocto-3.0.4 Git Revision: f2eb22a8783f1eecf99bd4042695bab920eed00e Release Artefact: poky-zeus-22.0.4 sha: da85224a290d484eeadb05ed69c64e3b9e0c873cf91c2e84e96dd54c4fd2752c Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/poky-zeus-22.0.4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.0.4/poky-zeus-22.0.4.tar.bz2 Repository Name: openembedded-core Repository Location: https://git.openembedded.org/openembedded-core Branch: zeus Tag: 2019-10.4-zeus Git Revision: 9cad716656b427e625a470a820b8b29b1ec9f976 Release Artefact: oecore-zeus-22.0.4 sha: 03e21646b2240382feb755ceaecc2474dca72a59ad796af1b2e993d253e2a242 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/oecore-zeus-22.0.4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.0.4/oecore-zeus-22.0.4.tar.bz2 Repository Name: meta-mingw Repository Location: https://git.yoctoproject.org/git/meta-mingw Branch: zeus Tag: yocto-3.0.4 Git Revision: 756963cc28ebc163df7d7f4b4ee004c18d3d3260 Release Artefact: meta-mingw-zeus-22.0.4 sha: 434d33b2ea01134b1deb07ce67a83402239b707c8ef54287dcda83ee2f0a3346 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/meta-mingw-zeus-22.0.4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.0.4/meta-mingw-zeus-22.0.4.tar.bz2 Repository Name: meta-gplv2 Repository Location: https://git.yoctoproject.org/git/meta-gplv2 Branch: zeus Tag: yocto-3.0.4 Git Revision: 0f4eecc000f66d114ad258fa31aed66afa292166 Release Artefact: meta-gplv2-zeus-22.0.4 sha: 55008a3633729a17c33426b3f81792f204d3c4473beb148e5f9b46ab345850b8 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/meta-gplv2-zeus-22.0.4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.0.4/meta-gplv2-zeus-22.0.4.tar.bz2 Repository Name: bitbake Repository Location: https://git.openembedded.org/bitbake Branch: zeus Tag: 2019-10.4-zeus Git Revision: fd279f857c98d492f43cc62d9ebae18ce6412b6e Release Artefact: bitbake-zeus-22.0.4 sha: 1b3d68805fd9015a40bc52886618c513de7cc3817db8adbeb5daaa65e3c078eb Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.4/bitbake-zeus-22.0.4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.0.4/bitbake-zeus-22.0.4.tar.bz2 --------------- Contributors --------------- Adrian Bunk Ahmad Fatoum akuster Alexander Kanavin Anuj Mittal Armin Kuster Bruce Ashfield Charles-Antoine Couret haiqing He Zhe Hongxu Jia Jain Sangeeta Jan-Simon Moeller jason.lau Joe Slater Kai Kang Khem Raj Konrad Weihmann Lee Chee Yang Lili Li Li Zhou Michael Halstead Nicolas Dechesne Otavio Salvador Ovidiu Panait Paul Barker Peter Kjellerstedt Pierre-Jean Texier Rahul Taya Ralph Siemsen Richard Leitner Richard Purdie Sakib Sajal Stephen Jolley Tim Orling Trevor Gamblin Vineela Tummalapalli wenlin.kang@... Yann Dirson Yi Zhao Zhixiong Chi --------------- Known Issues --------------- * vulkan-tools doesn't build on hosts where python3 is version 3.8. For such hosts this can be worked around with a buildtools tarball. --------------- Security Fixes --------------- libpcre: Add fix for CVE-2020-14155 go: Security Advisory - go - CVE-2020-15586 glibc: CVE-2020-6096 nss: Fix CVE-2020-12399 sqlite: backport CVE fix python3: fix CVE-2020-14422 systemd: fix CVE-2020-13776 wpa-supplicant: Security fix CVE-2020-12695 perl: fix CVE-2020-10543 & CVE-2020-10878 dbus: fix CVE-2020-12049 libexif: fix CVE-2020-13114 gnutls: fixed CVE-2020-13777 qemu: fix CVE-2020-10702 & CVE-2020-13765 libjpeg-turbo: Fix CVE-2020-13790 nfs-utils: fix CVE-2019-3689 bind: fix CVE-2020-8616/7 glibc: CVE-2020-1752 ghostscript : fix CVE-2019-10216 qemu: fix CVE-2020-11869 python3: fix CVE-2020-8492 --------------- Fixes --------------- Documentation: Prepared for 3.0.4 release build-appliance-image: Update to zeus head revision poky.conf: Bump version for 3.0.4 zeus release pypi.bbclass: use new pypi UPSTREAM_CHECK_URI pypi.bbclass: mind package suffix on version check gstreamer1.0: fix builds with make 4.3 core: glib-2.0: fix requested libmount/mkostemp/selinux not being linked in cve-update: handle baseMetricV2 as optional python3-numpy: Stop shipping manual config files selftest/context: Avoid tracebacks from tests using multiprocessing perf: Correct the substitution of python shebangs perf: fix build for v5.5+ utils: fix gcc 10 version detection iso-codes: switch upstream branch master -> main perl: Fix host specific modules problems bind: update to 9.11.19 bind: update 9.11.5-P4 -> 9.11.13 mtd-utils: Fix return value of ubiformat encodings: clear postinst script wpa-supplicant: remove service templates from SYSTEMD_SERVICE vim: _FORTIFY_SOURCE=2 be gone patchelf: Add patch to address corrupt shared library issue cve-check: include epoch in product version output cve-check: Run it after do_fetch file: add bzip2-replacement-native to DEPENDS to fix sstate issue gcr: depends on gnupg-native timezone: upgrade 2019c -> 2020a python3: Upgrade 3.7.7 -> 3.7.8 libpam: Remove option 'obscure' from common-password relocatable.bbclass: Avoid an exception if an empty pkgconfig dir exist kernel.bbclass: Fix Module.symvers support kernel-fitimage: introduce FIT_SIGN_ALG python3: un-break disabling the readline PACKAGECONFIG python3: make gdbm optional bitbake: tests/fetch: Switch from git.infradead.org to a YP mirror mesa: fix meson configure fix when 'dri' is excluded from PACKAGECONFIG avahi: Don't advertise example services by default strace: fix failing ptests icu: update SRC_URI gst-validate: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-vaapi: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-rtsp-server: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-python: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-omx: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-libav: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-plugins-ugly: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-plugins-bad: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-plugins-good: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-plugins-base: upgrade 1.16.1 -> 1.16.2 gstreamer1.0: upgrade 1.16.1 -> 1.16.2 gstreamer1.0-python: add a patch to fix python 3.8 builds wireless-regdb: Upgrade 2019.06.03 -> 2020.04.29 sstatesig: Optimise get_taskhash for hashequiv targetcontrol: Fix leaking log handler oeqa/qemurunner: Clean up failure handling Documentation: Prepared for 3.0.3 release resulttool/resultutils: Fix unicode error handling |
|
|