|
[PATCH][autobuilder-helper][warrior 05/41] layer-config, shared-repo-unpack: Sub-repos in NEEDREPOS
Richard Purdie
From: Thomas Goodwin <btgoodwin@geontech.com>
The previous fixes requires the user to set "no-layer-add" for a repo and then use ADDLAYER to insert the sub-repos (e.g., meta-openmbedded/meta-oe) as a two-part process. This means that you would also have to specify that flag if a repo that is a layer with dependencies is in the list so that it can be inserted in the correct order later via ADDLAYER to avoid parsing problems. This fix allows for specifying a NEEDREPOS with the subdirectory of the target layer (e.g., meta-openembedded/meta-oe) so that there is no need for the "no-layer-add" followed by ADDLAYER combination. The entire meta-openembedded repo would be moved into place, and the sublayer added to bblayers.conf. Signed-off-by: Thomas Goodwin <btgoodwin@geontech.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- scripts/layer-config | 24 +++++++++++++++--------- scripts/shared-repo-unpack | 4 ++-- 2 files changed, 17 insertions(+), 11 deletions(-) diff --git a/scripts/layer-config b/scripts/layer-config index 286451a..bb1b681 100755 --- a/scripts/layer-config +++ b/scripts/layer-config @@ -33,21 +33,27 @@ callinit = False repos = utils.getconfig("repo-defaults", ourconfig) for repo in needrepos: - checkdir = repo - if repo in repos: - if "call-init" in repos[repo] and repos[repo]["call-init"]: + repo_basename = repo.split('/')[0] + checkdir = repo_basename + if repo_basename in repos: + if "call-init" in repos[repo_basename] and repos[repo_basename]["call-init"]: callinit = True - if "checkout-dirname" in repos[repo]: - checkdir = repos[repo]["checkout-dirname"] - utils.mkdir(args.abworkdir + "/" + checkdir) - for f in os.listdir(args.abworkdir + "/repos/" + repo): - subprocess.check_call(['mv', args.abworkdir + "/repos/" + repo + "/" + f, args.abworkdir + "/" + checkdir + "/"]) + if "checkout-dirname" in repos[repo_basename]: + checkdir = repos[repo_basename]["checkout-dirname"] + + source = args.abworkdir + "/repos/" + repo_basename + destination = args.abworkdir + "/" + checkdir + if not os.path.isdir(destination) or callinit: + utils.mkdir(destination) + for f in os.listdir(source): + subprocess.check_call(['mv', source + "/" + f, destination + "/"]) if callinit: subprocess.check_call(". ./oe-init-build-env", shell=True, cwd=args.abworkdir) for repo in needrepos: - if repo in repos and "no-layer-add" in repos[repo] and repos[repo]["no-layer-add"]: + repo_basename = repo.split('/')[0] + if repo_basename in repos and "no-layer-add" in repos[repo_basename] and repos[repo_basename]["no-layer-add"]: continue try: bitbakecmd(args.abworkdir, "bitbake-layers add-layer %s" % (args.abworkdir + "/" + repo)) diff --git a/scripts/shared-repo-unpack b/scripts/shared-repo-unpack index a281897..92f0ccf 100755 --- a/scripts/shared-repo-unpack +++ b/scripts/shared-repo-unpack @@ -46,9 +46,9 @@ with open(args.repojson) as f: repos = json.load(f) targetsubdir = args.abworkdir + "/repos" - +needrepos_baseddirs = [r.split('/')[0] for r in needrepos] for repo in sorted(repos.keys()): - if repo not in needrepos: + if repo not in needrepos_baseddirs: continue targetrepodir = "%s/%s" % (targetsubdir, repo) if args.cache_dir: -- 2.25.1
|
|
|
|
[PATCH][autobuilder-helper][warrior 04/41] layer-config: fixing silent failures from always exiting '0'
Richard Purdie
From: Thomas Goodwin <btgoodwin@geontech.com>
The return value from bitbakecmd was not being returned when errors occurred which allowed shared-repo-unpack to succeed despite the failure. This fix changes to check_call and a try-catch when attempting to add repos that fail for whatever reason during add-layer, like a missing conf/layer.conf at the top level or a previously-added layer breaks parsing because of missing dependencies. Signed-off-by: Thomas Goodwin <btgoodwin@geontech.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- scripts/layer-config | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/scripts/layer-config b/scripts/layer-config index bfc62da..286451a 100755 --- a/scripts/layer-config +++ b/scripts/layer-config @@ -24,9 +24,7 @@ args = parser.parse_args() ourconfig = utils.loadconfig() def bitbakecmd(targetdir, cmd): - ret = subprocess.call(". ./oe-init-build-env; %s" % cmd, shell=True, cwd=targetdir) - if ret: - utils.printheader("ERROR: Command %s failed with exit code %d, see errors above." % (cmd, ret)) + subprocess.check_call(". ./oe-init-build-env; %s" % cmd, shell=True, cwd=targetdir) needrepos = utils.getconfigvar("NEEDREPOS", ourconfig, args.target, None) @@ -51,5 +49,8 @@ if callinit: for repo in needrepos: if repo in repos and "no-layer-add" in repos[repo] and repos[repo]["no-layer-add"]: continue - bitbakecmd(args.abworkdir, "bitbake-layers add-layer %s" % (args.abworkdir + "/" + repo)) - + try: + bitbakecmd(args.abworkdir, "bitbake-layers add-layer %s" % (args.abworkdir + "/" + repo)) + except subprocess.CalledProcessError as e: + utils.printheader("ERROR: Command %s failed with exit code %d, see errors above." % (e.cmd, e.returncode)) + sys.exit(e.returncode) -- 2.25.1
|
|
|
|
[PATCH][autobuilder-helper][warrior 03/41] README: Add pointer to the mailing list for patches
Richard Purdie
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
--- README | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README b/README index a6c4f1d..2747510 100644 --- a/README +++ b/README @@ -25,3 +25,8 @@ would also allow customisation. Authors: Richard Purdie <richard.purdie@linuxfoundation.org> Joshua Lock <joshua.g.lock@intel.com> + +Contributions: + +Patches for this code should be sent to the yocto@yoctoproject.org mailing list +with [yocto-autobuilder-helper] in the subject. -- 2.25.1
|
|
|
|
[PATCH][autobuilder-helper][warrior 02/41] config.json: Hide WARNINGS we don't care about for meta-gplv2 testing
Richard Purdie
We're not interested in these warnings, the license incompatibility is
expected. By hiding these, we'll notice when warnings we do care about appear. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- config.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/config.json b/config.json index 90b78f3..43526de 100644 --- a/config.json +++ b/config.json @@ -553,7 +553,8 @@ "MACHINE" : "qemux86", "BBTARGETS" : "core-image-minimal core-image-full-cmdline", "extravars" : [ - "INCOMPATIBLE_LICENSE = '*GPLv3'" + "INCOMPATIBLE_LICENSE = '*GPLv3'", + "WARN_QA_remove = 'incompatible-license'" ], "EXTRACMDS" : [ "../../yocto-autobuilder-helper/scripts/check-gplv3" -- 2.25.1
|
|
|
|
[PATCH][autobuilder-helper][warrior 01/41] config.json: Disable PRSERV
Richard Purdie
This was copied from the old autobuilder configuration without much thought.
It would only be effective if we had a common PRSERV or saved the database but we don't. It therefore makes sense to disable it. One problem it was causing was inconsistency in the buildhistory output as PKGR would change "r0" to "r0.0" and vice versa. The issue depended on whether the build has coming from sstate or not and the settings the sstate had been built with. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- config.json | 6 ------ 1 file changed, 6 deletions(-) diff --git a/config.json b/config.json index 573082a..90b78f3 100644 --- a/config.json +++ b/config.json @@ -24,7 +24,6 @@ "DISTRO" : "poky", "SDKMACHINE" : "i686", "PACKAGE_CLASSES" : "package_rpm package_deb package_ipk", - "PRSERV" : "PRSERV_HOST = 'localhost:0'", "DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'", "SSTATEDIR" : ["SSTATE_DIR ?= '${BASE_SHAREDDIR}/pub/sstate-warrior'"], "SSTATEDIR_RELEASE" : ["SSTATE_MIRRORS += 'file://.* file://${BASE_SHAREDDIR}/pub/sstate/PATH'", "SSTATE_DIR ?= '${BASE_PUBLISHDIR}/sstate/@RELEASENUM@'"], @@ -67,7 +66,6 @@ "SANITYTARGETS" : "core-image-sato:do_testsdk core-image-minimal:do_testsdkext core-image-sato:do_testsdkext" }, "step3" : { - "PRSERV" : false, "BUILDHISTORY" : false, "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest -r runqemu meta_ide -j 15"], "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"] @@ -124,7 +122,6 @@ "MACHINE" : "qemux86-64", "SDKMACHINE" : "x86_64", "PACKAGE_CLASSES" : "package_rpm", - "PRSERV" : false, "extravars" : [ "RPM_GPG_SIGN_CHUNK = '1'" ], @@ -142,7 +139,6 @@ "trigger-build" : { "SDKMACHINE" : "x86_64", "MACHINE" : "qemux86", - "PRSERV" : false, "step1" : { "BBTARGETS" : "universe -c fetch -k", "extravars" : [ @@ -235,7 +231,6 @@ "MACHINE" : "qemux86-64", "SDKMACHINE" : "x86_64", "PACKAGE_CLASSES" : "package_rpm", - "PRSERV" : false, "extravars" : [ "RPM_GPG_SIGN_CHUNK = '1'" ], @@ -596,7 +591,6 @@ "MACHINE" : "qemux86", "SDKMACHINE" : "x86_64", "BBTARGETS" : "universe:do_checkuri", - "PRSERV" : false, "extravars" : [ "SOURCE_MIRROR_FETCH = '1'", "BB_NUMBER_THREADS = '1'", -- 2.25.1
|
|
|
|
Monsees, Steven C (US)
# Append environment subscripts
|
|
|
|
Re: Compiling and packaging libraries
Mike Looijmans
The simplest solution is to use autotools or Cmake for your project. That will automatically "do the right thing" to get the library properly installed and registered.
toggle quoted messageShow quoted text
Even if your project is just one C file and a header, putting that in autotools or cmake is less work than getting all the nitty bits in a hand-crafted Makefile right. 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@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail
On 06-09-2020 10:53, majid.nasiry65 via lists.yoctoproject.org wrote:
Hi
|
|
|
|
Re: poky dhcpcd failed build
Yocto
On 9/10/20 6:58 AM, Khem Raj wrote:
#include <sys/param.h>i ran devtool modify dhcpcd and there is no "socket.c" in the source tree.
|
|
|
|
On 9/9/20 8:57 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Perhaps you need to use ${CC} and ${CXX} etc. in your makefile, and also source the SDK environment script in shell, before using it.
|
|
|
|
On 9/8/20 10:57 PM, Sourab B wrote:
Hello all, i was trying to install Google coral PCIe driver from thisDiscern between source distributions and binary distributions. Yocto project provides tools to build either of those, but it does not support interoperability with other binary distros e.g. debian/ubuntu/fedora etc. so while your yocto based distro might be using apt for online package management, it does not mean it supports feeds from debian/ubuntu or other dpkg based distros. You have to have yocto based binary distro feeds.
|
|
|
|
Re: do_rootfs: Could not invoke dnf
On 9/8/20 3:31 AM, majid.nasiry65@gmail.com wrote:
HelloImage builder uses debian naming for shared libs, and libraries are usually pulled in via shlibs resolver as a dependency so it would be good for you to ensure that this library has a use in image which means some application depends on it during runtime.
|
|
|
|
Re: poky dhcpcd failed build
On 9/7/20 11:27 PM, Yocto wrote:
Can you try adding #include <sys/param.h> into socket.c and see if that help ? if it does then please send it as a patch
|
|
|
|
Re: Compiling and packaging libraries
On 9/6/20 1:53 AM, majid.nasiry65@gmail.com wrote:
Hiin library's build system you want to use symbol versioning during linker stage. Then you can create using ln cmd to creating symlink to lib.so and lib.so.<major_version> see [1] Another question is what is difference between -dev and -dbg output?dev packages contain, development headers and libraries which are useful for building packages on target dbg packages contain debug info, which is useful if you are debugging on target. [1] http://www.microhowto.info/howto/build_a_shared_library_using_gcc.html
|
|
|
|
Re: Outreachy internship project - license tracing enhancement
Hey Paul, First of all, thank you so much for doing this. It's very much appreciated, I am very happy to see our community members willing to contribute to such a great internship program. As I mentioned to you separately, I will do my best to support and help you! On Wed, Sep 9, 2020 at 6:55 PM Paul Eggleton <Paul.Eggleton@...> wrote: Hi Armin I don't need to re-register, I need to confirm that the YP community (which is already registered) will participate in this round, and I need to indicate how the funding is done. I will reach out privately to discuss the funding side of things (there are a couple of questions/information to provide on their form). That said, if anyone else is willing to sponsor another internship, please let me know here or privately!
|
|
|
|
Monsees, Steven C (US)
Looking to understand why the SDK is searching the host/native (x86_64-pokysdk-linux) side when it should be looking at the target side (corei7-64-poky-linux) …
All the “crt” files are present under the target side.
Can someone explain what might be miss-configured ?, or better, point me to a possible patch ?
I have seen some talk on-line about similar issues, but no clear indication what the issue was, or how it was resolved…
I am running Yocto clang 6.0.1, cmake 3.8.2, under “rocko”, my SDK is a standard SDK, not extensible.
11:31 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.2/mybuild>make Scanning dependencies of target gbeinterp [ 0%] Building CXX object backend/src/CMakeFiles/gbeinterp.dir/gbe_bin_interpreter.cpp.o [ 0%] Linking CXX shared library libgbeinterp.so /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crti.o: No such file or directory /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crtbeginS.o: No such file or directory /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lstdc++ /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lm /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lgcc_s /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lc /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lgcc_s /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crtendS.o: No such file or directory /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crtn.o: No such file or directory collect2: error: ld returned 1 exit status make[2]: *** [backend/src/libgbeinterp.so] Error 1 make[1]: *** [backend/src/CMakeFiles/gbeinterp.dir/all] Error 2 make: *** [all] Error 2 11:31 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.2/mybuild>
Thanks, Steve
|
|
|
|
Re: Outreachy internship project - license tracing enhancement
On 9/9/20 3:51 AM, Paul Eggleton via lists.yoctoproject.org wrote:
Hi folksThis sounds great. Are you looking for YP to take action on registration or are you handling this? -armin
|
|
|
|
Outreachy internship project - license tracing enhancement
Paul Eggleton <paul.eggleton@...>
Hi folks
I'd like to propose we put forward the following project proposal for an Outreachy internship (https://www.outreachy.org/communities/cfp/). I'm prepared to be the mentor for the project and Microsoft will provide funding. (Note that we haven't got our community re-registered with Outreachy or set this up as an intern project proposal yet - deadline for YP community registration is September 17th and for project submissions is September 24th). Here's the brief: ------------- Yocto Project License tracing enhancement The Yocto Project build system is typically used to build customised Linux images from source for embedded applications. Along with the image, a manifest of packages and their corresponding licenses is prepared, however the accuracy of the license information is dependent on the accuracy of the metadata we have for each package (i.e. what is in the recipe file). As part of the build, we have an internal mapping from output files to source files which is currently used to prepare source packages to aid in debugging, however with the presence of SPDX headers in source files it could also be used to allow tracing the license of sources used in building a package/image to help improve our metadata and future license manifests. A proof-of concept implementation of this has been put together [1] - during this internship a successful intern will: 1) take the proof-of-concept implementation and get it to a state where it can be merged into the poky repository 2) use the functionality to examine the accuracy of our license tagging (LICENSE fields in recipes); look for errors / noise in the comparison, and produce a simple report with the results 3) run a check over sources in a world build looking for percentage coverage of SPDX headers, and run it for several past releases to see the change over time Bonus: assess the current state of meta-spdx-scanner; investigate what it would take to produce SPDX documents from build output (would likely require integration with Fossology). [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/license-experiments-osls ------------- I'm making the assumption that we're OK with merging the PoC functionality in rather than just keeping it separate and using it for analysis - let me know if otherwise. What I'd really like to know is do people think that this is sufficient for a 3-month internship, assuming that the intern has limited to moderate familiarity with our codebase? Do we need to flesh it out further? Any modifications that you'd suggest to the work? Thanks Paul
|
|
|
|
Sourab B
Hello all, i was trying to install Google coral PCIe driver from this site: https://coral.ai/docs/
Commands : echo "deb https://packages.cloud.google.
curl https://packages.cloud.google. ERROR:
curl https://packages.cloud.google. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 653 100 653 0 0 2176 0 --:--:-- --:--:-- --:--:-- 2176 gpg: signal [ 174.686462] audit: type=1701 audit(1598596554.214:5): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=876 comm="gpg" exe="/usr/bi1 Segmentation fault caught ... exiting Segmentation fault (core dumped)
|
|
|
|
Yocto Zeus stable branch
Hello,
The Zeus branch was defined as a transitional branch with a 9 month stable cycle since LTS was created. The 3.0.4 was the last Zeus dot release. We have since added several Build stabilization changes and last minute backports . We intend on doing on last formal build cycle but no QA so no formal dot release. After this action is complete, this branch will most like transition to Community Support and we will see where it goes from there. regards, Armin ( On behalf of the Yocto Project® TSC) Yocto Project® are registered trademark of the Linux Foundation.
|
|
|
|
Warrior and Thud stable branches
Sorry. still have the old email address in my contacts.
re-sending. -------- Forwarded Message -------- Subject: [yocto] Warrior and Thud stable branches Date: Tue, 8 Sep 2020 21:39:28 -0700 From: akuster via lists.yoctoproject.org <akuster808=gmail.com@lists.yoctoproject.org> Reply-To: akuster808@gmail.com To: openembedded-core@openembedded.org <openembedded-core@openembedded.org>, yocto@yoctoproject.org <yocto@yoctoproject.org>, OpenEmbedded Devel List <openembedded-devel@lists.openembedded.org>, bitbake-devel@lists.openembedded.org <bitbake-devel@lists.openembedded.org> Hello, A few words regarding the older stable releases, Thud and Warrior. Thud no longer has an active Community Maintainer so this release with be move to the EOL state. Warrior did have a volunteer but no activity to date and this branch will also move to the EOL state. This will take affect tomorrow (Wednesday PST). regards, Armin
|
|
|
