|
yocto support
Senthamilarasi mathiyan
Dear All Good Morning! In my project, I am trying to create one custom image recipe in my yocto build system.
The reason of creating custom image is -> having few specific configurations for kernel and some specific driver Makefile changes to enable coverage.
I cannot go with .bbappend file, because we are maintaining a recipes-append folder in our meta-layer which is common for all the production build image recipes.
My change is very specific it should not come as part of normal build images because it will affect the production build.
My use case: 1. I have one .cfg file for kernel - which has kernel specific configurations. 2. I have Makefile changes for driver file.
I should bring the above changes to kernel and driver Makefile during build time without using .bbappend file.
I want to create a custom image recipe with the specific changes.
For example : custom_image.bb =( This recipes should have core_image_minimal.bb + my specific changes)
When i build bitbake custom_image.bb, it should build with core_image_minimal.bb + my specific changes . Other images recipes also should not affect by this changes. My humble request. Can anyone please support how to proceed? Kindly share your suggestions. Regards Senthamilarasi. M |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Regression in rust-cross-canadian-aarch64
Richard Purdie
On Tue, 2022-06-28 at 11:00 +0200, Peter Bergin wrote:
When building rust-cross-canadian-aarch64 the fileI've spent an age staring at this code this morning. I don't think cross-canadian has ever worked properly. It might happen that some combinations build but there are also some that don't and clearly never have. SDKMACHINE = "aarch64", MACHINE = "qemuarm64" certainly doesn't work. It appears to be missing a ninja-native dependency and when that is added, it can't find rust-llvm. Looking at the do_configure from rust.inc, it considers BUILD triplets and TARGET triplets but not HOST ones, which probably dooms cross- canadian to failure since there, BUILD != HOST != TARGET. Someone is going to have to step up and sort out the canadian cross rust pieces properly. Whilst my patch probably did regress one config, I think there are much deeper issues in there. Cheers, Richard |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Regression in rust-cross-canadian-aarch64
Peter Bergin
On 2022-06-28 12:09, Richard Purdie wrote:
On Tue, 2022-06-28 at 11:00 +0200, Peter Bergin wrote:Thanks for suggestion! Yes, that will solve the problem for my setup. I was just wondering if you had any purpose with this if-else clause that should be kept or fixed?On 2022-06-19 22:47, Peter Bergin wrote:I'm wondering if we need something like: I can send a patch for this to oe-core if nothing more is needed to be fixed. Thanks, /Peter |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Regression in rust-cross-canadian-aarch64
Richard Purdie
On Tue, 2022-06-28 at 11:00 +0200, Peter Bergin wrote:
On 2022-06-19 22:47, Peter Bergin wrote:I'm wondering if we need something like: diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-devtools/rust/rust-common.inc index 621cd4ad576..ef70c48d0f4 100644 --- a/meta/recipes-devtools/rust/rust-common.inc +++ b/meta/recipes-devtools/rust/rust-common.inc @@ -309,10 +309,7 @@ def rust_gen_target(d, thing, wd, features, cpu, arch, abi=""): # build tspec tspec = {} - if bb.data.inherits_class('cross-canadian', d): - tspec['llvm-target'] = d.getVar('RUST_HOST_SYS', arch_abi) - else: - tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi) + tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi) tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi) tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi)) tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi) ? Cheers, Richard |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Regression in rust-cross-canadian-aarch64
Peter Bergin
Hi again,
some progress on this issue. On 2022-06-19 22:47, Peter Bergin wrote: Hi,The reason for this issue seems to be this commit: commit 781eaa955dce5deab47371c25dae72b36c011900 Author: Richard Purdie <richard.purdie@...> Date: Sat May 21 14:02:47 2022 +0100 rust-common: Drop LLVM_TARGET and simplify This all seems over complicated for something which is basically always one of two values. This might even help cross-canadian work on something which isn't x86-64. (From OE-Core rev: bd36593ba3db758b3eacc974e48468a665967961) Signed-off-by: Richard Purdie <richard.purdie@...> When building rust-cross-canadian-aarch64 the file 'tmp/work/x86_64-nativesdk-pokysdk-linux/rust-cross-canadian-aarch64/1.60.0-r0/targets/aarch64-poky-linux.json' will be populated with the information '"llvm-target": "x86_64-unknown-linux-gnu"'. This will lead to object files in wrong format during 'Building stage2 std artifacts (x86_64-unknown-linux-gnu -> aarch64-poky-linux)' in the do_compile step. In 'meta/recipes-devtools/rust/rust-common.inc': # build tspec tspec = {} if bb.data.inherits_class('cross-canadian', d): tspec['llvm-target'] = d.getVar('RUST_HOST_SYS', arch_abi) else: tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi) So for some reason it seems intentional to set 'llvm-target' to HOST_SYS when 'cross-canadian'. The behavior has changed with this patch. Before 'llvm-target' was set to RUST_TARGET_SYS for all target archs other than x86_64 where it was set to RUST_HOST_SYS. I guess this change has to do with the commit message 'This might even help cross-canadian work on something which isn't x86-64.'? But unfortunately it seems to break the case building on x86_64 for aarch64. It would be good to get some help here to sort this out. Thanks, /Peter |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW26
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW26!
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 4.1
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 418 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, “4.1”, “4.2”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.
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@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH yocto-autobuilder-helper] scripts/archive_buildstats.py: archive buildstats to tar.zst
Aryaman Gupta <aryaman.gupta@...>
Convert each time-stamped buildstats directory to a compressed tarball
using the hostname as a prefix (to the file name only) so that one can identify the source machine. Move these tarballs to the directory: testresults/<build_name>/buildstats/ The archiving is performed during the "collect results" step. Signed-off-by: Aryaman Gupta <aryaman.gupta@...> Signed-off-by: Randy MacLeod <Randy.MacLeod@...> --- scripts/archive_buildstats.py | 32 ++++++++++++++++++++++++++++++++ scripts/run-config | 1 + 2 files changed, 33 insertions(+) create mode 100755 scripts/archive_buildstats.py diff --git a/scripts/archive_buildstats.py b/scripts/archive_buildstats.py new file mode 100755 index 0000000..30ea289 --- /dev/null +++ b/scripts/archive_buildstats.py @@ -0,0 +1,32 @@ +#!/usr/bin/env python3 +# +# SPDX-License-Identifier: GPL-2.0-only +# +import os, subprocess, socket, sys + +def usagedir(): + print("Usage: " + sys.argv[0] + " <src> <dest> <target>") + +def main(): + if len(sys.argv) != 4: + usage() + sys.exit() + + builddir = sys.argv[1] + dest = sys.argv[2] + target = sys.argv[3] + dest_bsdir = os.path.join(dest, target, "buildstats") + subprocess.run(["mkdir", "-p", dest_bsdir]) + + build_bsdir = os.path.join(builddir, "tmp/buildstats") + hostname = socket.gethostname() + os.chdir(build_bsdir) + for timestamp in os.listdir(build_bsdir): + if hostname: + output = hostname + "-" + timestamp + ".tar.zst" + else: + output = "nohostname-"+ timestamp + ".tar.zst" + subprocess.check_call("tar -I zstd -cf "+output+" "+timestamp+"/*", shell=True) + subprocess.run(["mv", output, dest_bsdir]) + +main() diff --git a/scripts/run-config b/scripts/run-config index 838847a..953977e 100755 --- a/scripts/run-config +++ b/scripts/run-config @@ -334,6 +334,7 @@ elif args.phase == "finish" and args.stepname == "collect-results": hp.printheader("Running results collection") runcmd([scriptsdir + "/collect-results", args.builddir, args.results_dir, args.target]) runcmd([scriptsdir + "/summarize_top_output.py", args.results_dir, args.target]) + runcmd([scriptsdir + "/archive_buildstats.py", args.builddir, args.results_dir, args.target]) sys.exit(0) if jcfg: -- 2.35.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH v2] meta-integrity: kernel-modsign: prevents splitting out debug symbols
Jose Quaresma
Starting with [1] kernel modules symbols is being slipped in OE-core
and this breaks the kernel modules sign, so disable it. [1] https://git.openembedded.org/openembedded-core/commit/?id=e09a8fa931fe617afc05bd5e00dca5dd3fe386e8 Signed-off-by: Jose Quaresma <jose.quaresma@...> --- meta-integrity/classes/kernel-modsign.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-integrity/classes/kernel-modsign.bbclass b/meta-integrity/classes/kernel-modsign.bbclass index 093c358..d3aa7fb 100644 --- a/meta-integrity/classes/kernel-modsign.bbclass +++ b/meta-integrity/classes/kernel-modsign.bbclass @@ -13,7 +13,9 @@ MODSIGN_PRIVKEY ?= "${MODSIGN_KEY_DIR}/privkey_modsign.pem" MODSIGN_X509 ?= "${MODSIGN_KEY_DIR}/x509_modsign.crt" # If this class is enabled, disable stripping signatures from modules +# as well disable the debug symbols split INHIBIT_PACKAGE_STRIP = "1" +INHIBIT_PACKAGE_DEBUG_SPLIT = "1" kernel_do_configure:prepend() { if [ -f "${MODSIGN_PRIVKEY}" -a -f "${MODSIGN_X509}" ]; then -- 2.36.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH] meta-integrity: kernel-modsign: prevents splitting out debug
Jose Quaresma
Starting with [1] kernel modulus symbols is being slipped in OE-core
and this breaks the kernel module sign, so disable it. [1] https://git.openembedded.org/openembedded-core/commit/?id=e09a8fa931fe617afc05bd5e00dca5dd3fe386e8 Signed-off-by: Jose Quaresma <jose.quaresma@...> --- meta-integrity/classes/kernel-modsign.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-integrity/classes/kernel-modsign.bbclass b/meta-integrity/classes/kernel-modsign.bbclass index 093c358..d3aa7fb 100644 --- a/meta-integrity/classes/kernel-modsign.bbclass +++ b/meta-integrity/classes/kernel-modsign.bbclass @@ -13,7 +13,9 @@ MODSIGN_PRIVKEY ?= "${MODSIGN_KEY_DIR}/privkey_modsign.pem" MODSIGN_X509 ?= "${MODSIGN_KEY_DIR}/x509_modsign.crt" # If this class is enabled, disable stripping signatures from modules +# as well disable the debug symbols split INHIBIT_PACKAGE_STRIP = "1" +INHIBIT_PACKAGE_DEBUG_SPLIT = "1" kernel_do_configure:prepend() { if [ -f "${MODSIGN_PRIVKEY}" -a -f "${MODSIGN_X509}" ]; then -- 2.36.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: how to setup host environment for yocto
tomzy
Hi,Hi
I recommend taking a look at the kas project.[1] It allows you to manage Yocto layers in your project in a very easy
Regards |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[yocto-autobuilder-helper] [PATCH] config.json: Enable memres bitbake
Richard Purdie
We could do with wider exposure of testing of this so enable on the
autobuilder by default. Signed-off-by: Richard Purdie <richard.purdie@...> --- config.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/config.json b/config.json index d01319f..de32fb1 100644 --- a/config.json +++ b/config.json @@ -66,7 +66,8 @@ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'", "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh -c 100 -t 15'", "BB_LOG_HOST_STAT_ON_FAILURE = '1'", - "BB_LOG_HOST_STAT_CMDS_FAILURE = 'oe-time-dd-test.sh -l'" + "BB_LOG_HOST_STAT_CMDS_FAILURE = 'oe-time-dd-test.sh -l'", + "BB_SERVER_TIMEOUT = '60'" ] }, "templates" : { -- 2.34.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
how to setup host environment for yocto
黃玉珍
Hi,
I'm new to yocto, I wonder the recommended way to setup an environment for yocto using vagrant or docker to isolate from the host, since I've encounter many different error about python version or something like that. Some layers providede by vendor uses a tool called repo for version control, I always cannot install on my machine, following the steps form that page doesn't help either. Thanks, CD |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: source-less python
On 23 Jun 2022, at 23:40, Aurum Nitrogen via lists.yoctoproject.org <aurumnitrogen=gmail.com@...> wrote:
There’s an open issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434 The easiest implementation would be a rootfs-time postprocessing step where you compile every .py file, and then delete the .py. Is this what buildroot does? This does break feeds, but the alternative (of changing how packaging is done) would be a lot more invasive. Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Minutes: Yocto Project Weekly Triage Meeting 6/23/2022
sakib.sajal@...
Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage Attendees: Stephen Jolley, Steve Sakoman, Saul Wold,
Luca Ceresoli, Michael Opdenacker, Pavel Zhukov, Richard Purdie,
Aryaman Gupta, Randy Macleod, Ross Burton, Tim Orling ARs: Notes:
N/A
Medium+ 4.1 Unassigned Enhancements/Bugs: 74 (Last week
75) AB Bugs: 47
(Last week 49)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: source-less python
Alexander Kanavin
I don't remember any such discussion. If you want this to happen, you
toggle quoted message
Show quoted text
are welcome to develop the feature. Alex On Thu, 23 Jun 2022 at 16:39, Aurum Nitrogen <aurumnitrogen@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
source-less python
Aurum Nitrogen
Hi, I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature. I know that in buildroot it is supported. Was this discussed and decided against? Is this an open issue? Thanks, John |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
USB Installer for initial deployment
Matthias Schoepfer
Hi there,
I am looking for some kind of package or software, that creates an (USB thumb drive) installer for initial installation and deployment of a yocto image. So you can flash the image onto an USB thumb drive and boot from it (arch is x86-64 so this should be easy), and after asking if that is really what you want, will erase the local storage and partition the drive (root A/B, data, swap) and copies over the image from the yocto build. I know that there is some thing into this direction in the meta-intel layer, but that is not quite well documented nor do I think it will suit our needs (regarding partitioning for example). So, before I write terrible bash scripts into an initramfs init (because this is my best idea so far), if someone could give me a hint were to look would be great. Thanks and regards, Matthias |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|