|
[meta-security][PATCH] packagegroup-core-security: exclude apparmor in mips64
Signed-off-by: Armin Kuster <akuster808@...>
--- recipes-core/packagegroup/packagegroup-core-security.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb index 9ac0d2c..a6142a8 100644 --- a/recipes-core/packagegroup/packagegroup-core-security.bb +++ b/recipes-core/packagegroup/packagegroup-core-security.bb @@ -80,6 +80,9 @@ RDEPENDS_packagegroup-security-mac = " \ ${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \ " +RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor" +RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor" + RDEPENDS_packagegroup-meta-security-ptest-packages = "\ ptest-runner \ samhain-standalone-ptest \ -- 2.17.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: #yocto llvm support
#yocto
Monsees, Steven C (US)
So, does anyone know proper usage here?
Is this a fully functional llvm drop under ../poky/meta/recipes-devtools ? Is it compatible with meta-clang?, and can they be used together to build 3rd party extensions for my platform ?
Is it better to add supported components this way rather than building them in directly to EXT SDK ?
Also, any known issues with meta-clang under zeus 3.0.4 ?
Thanks, Steve
From: Monsees, Steven C (US)
I noticed similar behavior…
I am running zeus 3.0.4, “devtool sdk-install llvm” will get llvm 8.0.1…
When I build meta-clang, and I set TOOLCHAIN?=”clang” in local.conf it appears to grab llvm-project-source-9.0.1-9.0.1…
From:
yocto@... <yocto@...>
On Behalf Of Anton Antonov
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: #yocto llvm support
#yocto
Monsees, Steven C (US)
I noticed similar behavior…
I am running zeus 3.0.4, “devtool sdk-install llvm” will get llvm 8.0.1…
When I build meta-clang, and I set TOOLCHAIN?=”clang” in local.conf it appears to grab llvm-project-source-9.0.1-9.0.1…
From: yocto@... <yocto@...>
On Behalf Of Anton Antonov
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: #yocto llvm support
#yocto
Anton Antonov
Hi Steven,
I used meta-clang in my recipes and I noticed that: 1. The current release of poky uses LLVM v11.1.0 by default (poky/meta/recipes-devtools/llvm/llvm_git.bb) 2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines LLVMVERSION = "12.0.0") As a result just including meta-clang into bblayers.conf will require bitbake to build a new version of LLVM and rebuild everything which uses it Anton
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Monsees, Steven C (US)
Any one seen this before… ?
SDK appears to be working okay without the inclusion of native python3 components, not sure how the inclusion breaks devtool…
From: Monsees, Steven C (US)
Working with zeus 3.0.4, extended SDK…
Could someone explain what I overlooked, or why this issue pops up with python-native support inclusion ?
Thanks…
When I add in native-python3 support
# # Additional SDK Setup variables #
SDKIMAGE_FEATURES_append = " staticdev-pkgs"
SDK_EXTRA_TOOLS = " \ nativesdk-python3-pprint \ nativesdk-python3-pickle \ nativesdk-python3-shell \ nativesdk-python3-modules \ nativesdk-python3-distutils \ nativesdk-python3-xml \ nativesdk-python3-compile \ nativesdk-python3-six \ nativesdk-cmake \ "
TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"
I see the following error with devtool:
13:07 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH 13:08 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux SDK environment now set up; additionally you may now run devtool to perform development tasks. Run devtool --help for further details. 13:08 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: /opt/limws/3.0.4/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: line 5: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: Success
If I remove the “native-python” components, the issue goes away:
SDK_EXTRA_TOOLS = " \ nativesdk-cmake \ "
14:09 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH 14:11 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux SDK environment now set up; additionally you may now run devtool to perform development tasks. Run devtool --help for further details. 14:11 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help NOTE: Starting bitbake server... usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] <subcommand> ...
OpenEmbedded development tool
options: --basepath BASEPATH Base directory of SDK / build directory --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it from the metadata -d, --debug Enable debug output -q, --quiet Print only errors --color COLOR Colorize output (where COLOR is auto, always, never) -h, --help show this help message and exit
subcommands: Beginning work on a recipe: add Add a new recipe modify Modify the source for an existing recipe upgrade Upgrade an existing recipe Getting information: status Show workspace status search Search available recipes latest-version Report the latest version of an existing recipe check-upgrade-status Report upgradability for multiple (or all) recipes Working on a recipe in the workspace: build Build a recipe rename Rename a recipe file in the workspace edit-recipe Edit a recipe file find-recipe Find a recipe file configure-help Get help on configure script options update-recipe Apply changes from external source tree to recipe reset Remove a recipe from your workspace finish Finish working on a recipe in your workspace Testing changes on target: deploy-target Deploy recipe output files to live target machine undeploy-target Undeploy recipe output files in live target machine package Build packages for a recipe build-image Build image including workspace recipe packages runqemu Run QEMU on the specified image Advanced: build-sdk Build a derivative SDK of this one extract Extract the source for an existing recipe sync Synchronize the source tree for an existing recipe export Export workspace into a tar archive import Import exported tar archive into workspace menuconfig Alter build-time configuration for a recipe SDK maintenance: sdk-update Update SDK components sdk-install Install additional SDK components Use devtool <subcommand> --help to get help on a specific command 14:11 smonsees@yix490016 /disk0/scratch/smonsees>
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [PATCH] linux-yocto/5.4: fix arm defconfig warnings
Bruce Ashfield
Obviously this is to the wrong list!
toggle quoted messageShow quoted text
It escaped before I could stop it :D I've already resent to oe-core. Bruce On Tue, Apr 20, 2021 at 8:31 AM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:
--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
#yocto llvm support
#yocto
Monsees, Steven C (US)
Under ../poky/meta/recipes-devtools the is “llvm”…
Devtool search <component> Devtool sdk-install <component>
Will add this component to my EXT SDK…
Is this a fully functional llvm drop ?, (i.e. is it compatible with meta-clang?, and can I use them together to build 3rd party extensions for my platform ?)
Is it better to add supported components this way rather than building them in directly to EXT SDK ?
Thanks, Steve
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: what to include in a "hardware bringup image"?
Yoann Congal
Hello, It might be a bit heavy but I usually install a text editor and python-periphery (https://github.com/vsergeev/python-periphery) (It did not know c-periphery but this is the same author) Before having full fledged linux drivers, it allows to check devices IDs, make simple requests like get a sensor value or enable a PMIC regulator. I'm interested in the list of packages you'll end up with... Will you share it here ? Regards, Yoann Congal Smile ECS - Expert technique
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH] linux-yocto/5.4: fix arm defconfig warnings
Bruce Ashfield
From: Bruce Ashfield <bruce.ashfield@...>
A recent fix to the kern-tools promoted some previously unseen issues to warnings. This commit fixes them by tagging some BT options as non-hardware so they won't generate warnings if they don't appear in the final .config. These are sub BT options and shouldn't warn when/if their controlling option is disabled by a fragment. d7fd0213b75 base: exclude some BT options as non-hardware Signed-off-by: Bruce Ashfield <bruce.ashfield@...> --- meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb index e52c9ebe0e..a802a570a1 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb @@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "324e77d816cf6434507ab29140beb24044009efa" -SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255" +SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}" diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb index f07375c761..1edc632de7 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb @@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine_qemuarm ?= "8463db325b93f0669446f68c19334cfe11ffb9c2" SRCREV_machine ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a" -SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255" +SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.4.bb b/meta/recipes-kernel/linux/linux-yocto_5.4.bb index 4f056d6d82..3a9463af6a 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.4.bb @@ -23,7 +23,7 @@ SRCREV_machine_qemux86 ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a" SRCREV_machine_qemux86-64 ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a" SRCREV_machine_qemumips64 ?= "996fe040c8d8d01a9af6be42dae3844d127471bf" SRCREV_machine ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a" -SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255" +SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642" # remap qemuarm to qemuarma15 for the 5.4 kernel # KMACHINE_qemuarm ?= "qemuarma15" -- 2.19.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: what to include in a "hardware bringup image"?
Mike Looijmans
I tend to use a reasonably standard image, usually the one that will evolve into the product, and once the network (usb, ethernet or wifi) is up, use "opkg install" to grab whatever else I need from my build machine on demand.
toggle quoted messageShow quoted text
Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijmans@... W: www.topic.nl Please consider the environment before printing this e-mail
On 15-04-2021 10:24, Robert P. J. Day via lists.yoctoproject.org wrote:
for a current project (and subsequent projects), i want to define a --
Mike Looijmans
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.7.rc1)
Sangeeta Jain
Hi All,
toggle quoted messageShow quoted text
This is the full report for yocto-3.1.7.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high milestone defects. no new issue found Thanks, Sangeeta
-----Original Message-----
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Yocto Dunfell: u-boot-fw-utils ERROR
#imx6
#yocto
#dunfell
#swupdtae
#libubootenv
Mikko Rapeli <mikko.rapeli@...>
Hi,
On Tue, Apr 20, 2021 at 03:24:25AM -0700, anthony.marchand@... wrote: Hello,Multiple ways to fix this. One is to switch to using dunfell branches for the BSP SW stack, if they are available. Alternatively you can use the old zeus based BSP SW stack but for that you need to copy the files which BSP SW stack depends on poky side from zeus branch to the BSP SW meta layer. Then things will work out with minor bug fixes or API changes. For IMX*, I copied the old u-boot recipe files from poky zeus branch over to the BSP so that meta-freescale* and meta-imx find them and prefer over the newer u-boot version from poky dunfell branch. Hope this helps, -Mikko Thanks by advance, best reguards.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Dunfell: u-boot-fw-utils ERROR
#imx6
#yocto
#dunfell
#swupdtae
#libubootenv
anthony.marchand@...
Hello,
I'm actually migrating a yocto project zeus version to dunfell LTS to build my imx6 Linux system on this LTS release. Almost all works fine except the following message I try to understand when I try to compile the image: --------------------------------------------------------------------------------------------------------------------------------------------------------- ERROR: Multiple .bb files are due to be built which each provide u-boot-fw-utils: | ETA: 0:00:01
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb
A list of tasks depending on these providers is shown and may help explain where the dependency comes from.
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique dependees:
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique dependees:
Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_build
Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_package
Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_prepare_recipe_sysroot
It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique provides:
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique rprovides:
u-boot-fw-utils-dev
u-boot-fw-utils-locale
u-boot-fw-utils-dbg
u-boot-fw-utils-staticdev
u-boot-fw-utils-doc
^u-boot-fw-utils-locale-.*
u-boot-fw-utils-src
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique provides:
libubootenv
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique rprovides:
libubootenv
libubootenv-src
libubootenv-bin
libubootenv-dbg
libubootenv-doc
^libubootenv-locale-.*
libubootenv-locale
libubootenv-dev
libubootenv-staticdev
--------------------------------------------------------------------------------------------------------------------------------------------------------- Does someone already meet this problem? Do you know what I should look in for to solve it? Thanks by advance, best reguards.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH] [yocto-autobuilder-helper 2/2] scripts/utils.py: Add reporting for yocto-check-layer
Yi Fan Yu
The default behavior is to look for a bitbake command,
which fails and produces a confusing output of [-1:]. [YOCTO #14208] Signed-off-by: Yi Fan Yu <yifan.yu@...> --- scripts/utils.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/utils.py b/scripts/utils.py index bf1d989..4c73f81 100644 --- a/scripts/utils.py +++ b/scripts/utils.py @@ -330,6 +330,9 @@ class ErrorReport(object): elif 'oe-selftest' in command: report['error_type'] = 'oe-selftest' failure['task'] = command[command.find('oe-selftest'):] + elif 'yocto-check-layer' in command: + report['error_type'] = 'check-layer' + failure['task'] = command[command.find('yocto-check-layer'):] else: report['error_type'] = 'core' failure['task'] = command[command.find('bitbake'):] -- 2.29.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH] [yocto-autobuilder-helper 1/2] config.json: Add default MACHINE qemux86-64
Yi Fan Yu
This is the default oe-core MACHINE value.
Prevent error-reporting tool to report simply False. It was seen in check-layer where the MACHINE wasn't specified. [YOCTO #14208] Signed-off-by: Yi Fan Yu <yifan.yu@...> --- config.json | 1 + 1 file changed, 1 insertion(+) diff --git a/config.json b/config.json index 962d8ae..2d1a698 100644 --- a/config.json +++ b/config.json @@ -26,6 +26,7 @@ "defaults" : { "NEEDREPOS" : ["poky"], "DISTRO" : "poky", + "MACHINE" : "qemux86-64", "SDKMACHINE" : "i686", "PACKAGE_CLASSES" : "package_rpm package_deb package_ipk", "DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'", -- 2.29.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW16
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW16!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 3.4
Stephen Jolley
All,
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 357 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-gplv2] [PATCH] conf/distro: Add removal of btrfs-tools from util-linux ptest depends
Robert Joslyn
Just to clarify, btrfs-tools has always had an LGPL-3.0 library (libbtrfsutil), the recipe just never declared it before. Upstream is relicensing that library to LGPL-2.1+, which should be done for the next release.
toggle quoted messageShow quoted text
Sorry about this, I sent the update and didn’t realize it broke the non-gplv3 builds. I’ll keep an eye out for the next upstream release which should allow this patch to be reverted. Thanks, Robert
On Apr 19, 2021, at 2:29 PM, Ross Burton <ross@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|