|
Re: [yocto-autobuilder2][RFC][PATCH] README-Guide.md: Add multi-node content, extra config info
Trevor Gamblin
On 2021-04-05 2:55 p.m., Michael
Halstead wrote:
You're right, I don't need the others. Fixing this for the next revision. The beginning of README-Guide.md mentions that the user should reference the Yocto Manual for the required packages, so maybe copying the list here is inconsistent. I'll put the link near the top of the doc and we can look at a better way to do this if/when a new version of this guide makes it into the Manual.
Good point. Fixing this for the next patch. Thanks again for your review! - Trevor
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
is there a *compelling* use case for "FILESEXTRAPATHS_append"?
Robert P. J. Day
over the years, i've always been uncomfortable with the admittedly
small number of examples in various layers i've found that append to FILESEXTRAPATHS rather than prepend, so i'm curious if there is an actual, persuasive reason to ever do that. philosophically, when one uses FILESEXTRAPATHS_prepend, one is effectively saying, "here, use my content. nobody else's. mine. it's right here. you can see it." and there should be no ambiguity, of course. when you append, however, you're allowing for some hitherto unknown earlier layer to jump in and override some of your content. effectively, it seems (and i'm willing to be corrected) that you're saying, "i have some content that *could* be used, but if some earlier layer has the same content, we'll use that instead." that seems to open up a huge can of non-determinism, if an earlier layer suddenly introduces (or, conversely removes) content of the same name without you noticing, and weird things start to happen. so the question is, is there a really, well-defined use case for appending to this variable? rday
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Monsees, Steven C (US)
EXT SDK, aarch64, zeus…
How do I best modify the EXT SDK build env so as to reference the “vivado” env dependencies ?
Is there a way to build in support so that the “module load” command would be usable from the “.conf” or the env-setup script, (i.e. “module load vivado…” ?
Thanks, Steve
From: Monsees, Steven C (US)
Sent: Thursday, April 1, 2021 6:52 AM To: 'Khem Raj' <raj.khem@...> Cc: yocto@... Subject: RE: [yocto] #yocto #sdk
Thanks for your patience…
I was able to followed your advice and I am now able to build and install the Extended SDK for our Intel platform…
Can you tell me when building for Arm/Xilinx based platforms, how you incorporate the dependency of the low level Xilinx FPGA support on “Vivado” into the Ext SDK build env ?
Thanks, Steve From: Khem Raj <raj.khem@...>
On Thu, Mar 25, 2021 at 1:01 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:
Perhaps get into install env and do signatures check for this task
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
WiFi P2P support
JH
Hi,
I am building WiFi wlan Linux image on Zeus using Linux WiFi linux-firmware-sd8801 and connman, I need to add WiFi P2P support, is it sufficient to create wpa-supplicant_2.9.bbappend to enable CONFIG_P2P=y (it is disabled in wpa-supplicant_2.9 defconfig)? Do I need to make other changes on OE configurations? Thank you very much. Kind regards, jupier
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW14
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3Enhancements/Bugs closed WW14!
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.3
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)
Stephen Jolley
All,
Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (4/6)
Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto
Wiki: https://www.yoctoproject.org/public-virtual-meetings/
When Monthly from 8am to 9am on the first Tuesday Pacific Time Where Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them. The world should have view access.
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 360 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: [yocto-autobuilder2][RFC][PATCH] README-Guide.md: Add multi-node content, extra config info
Michael Halstead
On Mon, Apr 5, 2021 at 9:23 AM Trevor Gamblin <trevor.gamblin@...> wrote: Signed-off-by: Trevor Gamblin <trevor.gamblin@...> On the AB at typhoon.yocto.io only LANG=en_US.UTF-8 is set. I don't know why LC_ALL or LANGUAGE need to be set on your cluster for builds to succeed. + Should we link to https://docs.yoctoproject.org/ref-manual/system-requirements.html#ubuntu-and-debian for the current package set as well as listing this information here? + Let's only chown the directories we intend to export. Other data may be present in /srv and leaving its owner intact is desirable. +``` Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[yocto-autobuilder2][RFC][PATCH] README-Guide.md: Add multi-node content, extra config info
Trevor Gamblin
Signed-off-by: Trevor Gamblin <trevor.gamblin@...>
--- README-Guide.md | 94 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) diff --git a/README-Guide.md b/README-Guide.md index 21dd7c1..8558c48 100644 --- a/README-Guide.md +++ b/README-Guide.md @@ -43,6 +43,16 @@ yocto-controller/yoctoabb yocto-worker ``` +Before proceeding, make sure that the following is added to the +pokybuild3 user's exports (e.g. in .bashrc), or builds will fail after +being triggered: + +``` +export LC_ALL=en_US.UTF-8 +export LANG=en_US.UTF-8 +export LANGUAGE=en_US.UTF-8 +``` + Next, we need to update the `yocto-controller/yoctoabb/master.cfg` towards the bottom where the `title`, `titleURL`, and `buildbotURL` are all set. This is also where you would specify a different password for binding workers to the master. Then, we need to update the `yocto-controller/yoctoabb/config.py` to include our worker. In that file, find the line where `workers` is set and add: ["example-worker"]. _NOTE:_ if your worker's name is different, use that here. Section 3.1 discusses how to further refine this list of workers. @@ -112,6 +122,90 @@ sudo /home/pokybuild3/yocto-worker/qemuarm/build/scripts/runqemu-gen-tapdevs \ In the above command, we assume the a build named qemuarm failed. The value of 8 is the number of tap interfaces to create on the worker. +### 1.3) Adding Dedicated Worker Nodes + +Running both the controller and the worker together on a single machine +can quickly result in long build times and an unresponsive web UI, +especially if you plan on running any of the more comprehensive builders +(e.g. a-full). Additional workers can be added to the cluster by +following the steps given above, except that the yocto-controller steps +do not need to be repeated. For example, to add a new worker +"ala-blade51" to an Autobuilder cluster with a yocto-controller at the +IP address 147.11.105.72: + +1. On the yocto-controller host, add the name of the new worker to a worker +list (or create a new one) e.g. 'workers_wrlx = ["ala-blade51"]' and +make sure that it is added to the "workers" list. + +2. On the new worker node: + +``` +sudo apt-get install gawk wget git-core diffstat unzip texinfo \ +gcc-multilib build-essential chrpath socat cpio python python3 \ +python3-pip python3-pexpect xz-utils debianutils iputils-ping \ +libsdl1.2-dev xterm + +sudo pip3 install buildbot buildbot-www buildbot-waterfall-view \ +buildbot-console-view buildbot-grid-view buildbot-worker + +useradd -m --system pokybuild3 +cd /home/pokybuild3 +mkdir -p git/trash +buildbot-worker create-worker -r --umask=0o22 yocto-worker 147.11.105.72 ala-blade51 pass +chown -R pokybuild3:pokybuild3 /home/pokybuild3 +``` + + > Note 1: The URL/IP given to the create-worker command must match the +host running the yocto-controller. + + > Note 2: The "pass" argument given to the create-worker command must +match the common "worker_pass" variable set in yocto-controller/yoctoabb/config.py. + + +### 1.4) Configuring NFS for the Autobuilder Cluster + +The Yocto Autobuilder relies on NFS to distribute a common sstate cache +and other outputs between nodes. A similar configuration can be +deployed by performing the steps given below, which were written for +Ubuntu 18.04.In order for both the controller and worker nodes to be able +to access the NFS share without issue, the "pokybuild3" user on all +systems must have the same UID/GID, or sufficient permissions must be +granted on the /srv/autobuilder path (or wherever you modified the config +files to point to). The following instructions assume a controller node +at 147.11.105.72 and a single worker node at 147.11.105.71, but +additional worker nodes can be added as needed (see the previous +section). + +1. On the NFS host: + +``` +sudo apt install -y nfs-kernel-server +sudo mkdir -p /srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate +sudo chown -R pokybuild3:pokybuild3 /srv +``` +2. Add the following to /etc/exports, replacing the path and IP fields + as necessary for each client node: +``` +/srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate 147.11.105.71(rw,sync,no_subtree_check) +``` + +3. Run +``` +sudo systemctl restart nfs-kernel-server +``` + +4. Adjust the firewall (if required). Example: +``` +sudo ufw allow from 147.11.105.71 to any port nfs +``` + +5. On the client node(s): +``` +sudo mkdir -p /srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate +sudo chown -R pokybuild3:pokybuild3 /srv/autobuilder/ +sudo mount 147.11.105.72:/srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate /srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate +``` + ## 2) Basics This section is an overview of operation and a few basic configuration file relationships. See Section 3 for more detailed instructions. -- 2.30.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
BB_NO_NETWORK ignored, causing fetch failure
Kent Dorfman <kent.dorfman766@...>
upstream vendors provided me with a git repo of ALL necessary layers
with the understanding that I'd clone the repo locally and disable network access, using only our local cloned repo in dl_mirror/ The files in dl_mirror are either raw tarballs, gitshallow, or gitsmshallow. I've touched the .done file for all of them. After removing all state cache and attempting a clean rebuild I'm getting a do_fetch failure on a recipe for one of the vendor specific fragments. ERROR: XXX-pll-ctrl-git-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command \ LANG=C git -c core.fsyncobjectfiles=0 clone --bare --mirror \ ssh://git@.../XXXXXX/internal/sw/XXXXXXXXX/XXX_pll_ctrl.git /HD/home/XXdev/XX-yocto-git/build/../dl_mirror \ /git2/gitlab.XXXXXX.com.XXXXXX.internal.sw.XXXXXXXXX.XXX_pll_ctrl.git \ --progress (for url git://gitlab.XXXXXX.com/XXXXXX/internal/sw/XXXXXXXXX/XXX_pll_ctrl.git;user=git;protocol=ssh;branch=master) ERROR: XXX-pll-ctrl-git-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /HD/home/XXdev/XX-yocto-git/build/tmp-glibc/work/cortexa9hf-neon-XXXXXX-linux-gnueabi/XXX-pll-ctrl/git-r0/temp/log.do_fetch.7513 I need to force yocto to ONLY use or attempt to use dl_mirror/ content...regardless of what the SRC_URI is in the recipe. Not clear on why "git clone --mirror" still references upstream repo How to accomplish bombproof local dl_mirror/ reference only?
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-rockchip][PATCH v2 1/4] linux-yocto: reduce bbappend duplication
Trevor Woerner
Hi Yann,
toggle quoted messageShow quoted text
I've added this one to master, thanks! I'm still playing around with the others, thanks for your patience :-)
On Thu, Apr 1, 2021 at 4:52 AM <yann.dirson@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi
toggle quoted messageShow quoted text
Can you try this patch ( if you are using master ) and see if that helps diff --git a/recipes-devtools/clang/clang_git.bb b/recipes-devtools/clang/clang_git.bb index b8986be..b0c81f1 100644 --- a/recipes-devtools/clang/clang_git.bb +++ b/recipes-devtools/clang/clang_git.bb @@ -15,7 +15,6 @@ BUILD_CXX_class-nativesdk = "clang++" BUILD_AR_class-nativesdk = "llvm-ar" BUILD_RANLIB_class-nativesdk = "llvm-ranlib" BUILD_NM_class-nativesdk = "llvm-nm" -LDFLAGS_append_class-nativesdk = " -fuse-ld=lld" inherit cmake cmake-native pkgconfig python3native
On Sat, Apr 3, 2021 at 3:34 PM msg board <msgboardpana@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Private: Re: [poky] Weird Compilation issue with a c++ recipe
arunlee@...
I have posted the top level CMakeList.txt in the first post, which added a sub directory INCLUDE_DIRECTORIES(include) # Add the sources to the target add_subdirectory(src) that has one CMakeList.txt. # Set minimum required CMake version cmake_minimum_required(VERSION 3.5.1) # Name the project project (sources) add_subdirectory(calsimple) add_subdirectory(calibinfo) add_subdirectory(writer) add_subdirectory(converter) add_subdirectory(server) regards Arun
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
msg board
Hello, I need Clang compiler apart from currently available default gcc compiler as I am trying to compile eBPF which will run on my custom yocto which is based on core-image-minimal. Therefore I added Clang compiler to my yocto sdk build using the meta-clang layer available at https://github.com/kraj/meta-clang . My yocto is based on dunfell and uses package_deb inside local.conf. SDK compilation succeeded with command "bitbake <mycustomdistro> -c populate_sdk " but while installation on host there errors similar to the ones mentioned in this issue . Therefore, I removed the LDFLAGS_append_class-nativesdk = " -fuse-ld=gold" line from clang_git.bb and compiled. This gave me errors related to this issue . Therefore, I added package_ipk and also kept package_deb . The compilation was successful but there was one warning as below : ------------------------- <CUSTOMDISTRO> do_populate_sdk: Unable to install packages. Command <Path>/opkg --volatile-cache -f <Path>/opkg.conf -t <Path>/sysroots/core2-64-poky-linux --force-postinstall --prefer-arch-to-version install <Long list of space seperate package names> returned 1 Collected errors: Solver encountered 1 problem(s) ....
------------------------- The installation of on host was successful When I tried to use the sdk to compile eBPF, I got errors mentioning that the sysroot does not contain /usr/include/gelf.h . After looking I saw that elfutils-dev tools were not installed. elfutils-dev would have installed gelf.h. in /usr/include of sysroot. Without the addition of Clang I was able to generate working sdk with just package_deb in local.conf.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
does meta-virtualization layer have superfluous dynamic layers stuff?
Robert P. J. Day
just noticed this is meta-virt layer, file layer.conf:
# The dynamic-layers directory hosts extensions and layer-specific # modifications. # # The .bbappend and .bb files are included if the respective layer # collection is available. BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \ for layer in BBFILE_COLLECTIONS.split())}" BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' % layer \ for layer in BBFILE_COLLECTIONS.split())}" BBFILES_DYNAMIC += " \ raspberrypi:${LAYERDIR}/dynamic-layers/raspberrypi/*/*/*.bb \ raspberrypi:${LAYERDIR}/dynamic-layers/rasbperrypi/*/*/*.bbappend \ xilinx:${LAYERDIR}/dynamic-layers/xilinx/*/*/*.bb \ xilinx:${LAYERDIR}/dynamic-layers/xilinx/*/*/*.bbappend \ " i'm *assuming* that those first two assignments to BBFILES represent the earlier technique for supporting dynamic layers, otherwise i'm not sure what they're doing there. with the assignment to BBFILES_DYNAMIC, is there any value to the earlier assignments? rday
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[ANNOUNCEMENT] Yocto Project 3.2.3 (gatesgarth-24.0.3) is Released
Vineela
Hello,
We are pleased to announce the Yocto Project 3.2.3 (gatesgarth-24.0.3) Release is now available for download. http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2 A gpg signed version of these release notes is available at: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/RELEASENOTES Full Test Report: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/testreport.txt Thank you for everyone's contributions to this release. Vineela Tummalapalli Yocto Project Build and Release vineela.tummalapalli@... - -------------------------- yocto-3.2.3 Release Notes - -------------------------- - -------------------------- Repositories/Downloads - -------------------------- Repository Name: poky Repository Location: https://git.yoctoproject.org/git/poky Branch: gatesgarth Tag: yocto-3.2.3 Git Revision: 08665a81dcd41069eed1468f1587abe6b5893471 Release Artefact: poky-gatesgarth-24.0.3 sha: 174cdc436360fb8a11f08b54e6e39d3159aa80f57a3cabc165c625cdd111f9da Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2 Repository Name: openembedded-core Repository Location: https://git.openembedded.org/openembedded-core Branch: gatesgarth Tag: 2020-10.3-gatesgarth Git Revision: fdae970656cc421c542af9856bc9ae038c61db13 Release Artefact: oecore-gatesgarth-24.0.3 sha: 22b293dda4bb47b6d57ef3058ccb8fc8d49c41a5d5b4e8f86ca94b49eed37a07 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/oecore-gatesgarth-24.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/oecore-gatesgarth-24.0.3.tar.bz2 Repository Name: meta-mingw Repository Location: https://git.yoctoproject.org/git/meta-mingw Branch: gatesgarth Tag: yocto-3.2.3 Git Revision: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879 Release Artefact: meta-mingw-gatesgarth-24.0.3 sha: 03ae3c3695e60a8130023c6eff1f75ca2b735484b9889a8689f33bb220fa9dbc Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/meta-mingw-gatesgarth-24.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/meta-mingw-gatesgarth-24.0.3.tar.bz2 Repository Name: meta-gplv2 Repository Location: https://git.yoctoproject.org/git/meta-gplv2 Branch: gatesgarth Tag: yocto-3.2.3 Git Revision: 6e8e969590a22a729db1ff342de57f2fd5d02d43 Release Artefact: meta-gplv2-gatesgarth-24.0.3 sha: 7c639c543b01b0ffdac3ac3b3a25513af690113f29a528408aaecf1f3618aa4f Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/meta-gplv2-gatesgarth-24.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/meta-gplv2-gatesgarth-24.0.3.tar.bz2 Repository Name: bitbake Repository Location: https://git.openembedded.org/bitbake Branch: gatesgarth Tag: 2020-10.3-gatesgarth Git Revision: 5d02c98489d3a5836676b9c3fb3bd0157449db2b Release Artefact: bitbake-gatesgarth-24.0.3 sha: 527828a79ec0cd92cdabc779247e31787cd7f5451b8ed568fd4bd511c0a5cd23 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/bitbake-gatesgarth-24.0.3.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/bitbake-gatesgarth-24.0.3.tar.bz2 Repository Name: yocto-docs Repository Location: https://git.yoctoproject.org/git/yocto-docs Branch: gatesgarth Tag: yocto-3.2.3 Git Revision:10ea3bc5691bdf32df47a28252ce4b74ca7fd646 - ------------- Contributors - ------------- Alejandro Hernandez Samaniego Anatol Belski Andrei Gherzan Anuj Mittal Armin Kuster Bruce Ashfield Chee Yang Lee Chen Qi Dorinda Florian Bezdeka Jan Brzezanski Jan-Simon Möller Jon Mason Joshua Watt Khem Raj Lee Chee Yang Marek Vasut Martin Jansa Michael Halstead Mike Crowe Milan Shah Mingli Yu Minjae Kim Peter Kjellerstedt Purushottam Choudhary Richard Leitner Richard Purdie Ross Burton Sangeeta Jain Scott Murray Stefan Ghinea Stefan Schmidt Stephen Jolley Thomas Viehweger Tomasz Dziendzielski Vineela Tummalapalli Vivien Didelot Wang Mingyu Wes Lindauer Yi Fan Yu Yi Zhao Yoann Congal Zbigniew Bodek - --------------- Known Issues - --------------- N/A - --------------- Security Fixes - --------------- glib-2.0: Fix CVE-2021-27219 python3-jinja2: set CVE_PRODUCT shadow: whitelist CVE-2013-4235 wpa-supplicant: fix CVE-2021-27803 qemu: fix CVE-2021-20203 libsdl2: fix CVE-2020-14409 CVE-2020-14410 python3: fix CVE-2021-23336 bind: fix CVE-2020-8625 cups: fix CVE-2020-10001 wpa-supplicant: fix CVE-2021-0326 screen: fix CVE-2021-26937 openssh: fix CVE-2020-14145 qemu: fix CVE-2020-29443 CVE-2020-35517 - --------------- Fixes - --------------- build-appliance-image: Update to gatesgarth head revision poky.conf: bump version for 3.2.3 release documentation: version bumps for 3.2.3 release build-appliance-image: Drop kernel module handling xcb-proto: update to 1.14.1 linux-yocto/5.4: update to v5.4.103 Revert "sstatesig.py: show an error instead of warning when sstate manifest isn't found" systemd-conf: do not ask for DHCP if configured on kernel command line populate_sdk_ext: record METADATA_REVISION runqemu: use "raw" instead of "bin" for ovmf devtool: Fix do_kernel_configme task iso-codes: fix protocol in SRC_URI gcc-sanitizers: Move content from gcclibdir into libdir gstreamer1.0-python: Set internal python library path correcty selftest/reproducible: Don't call sync between each file compare apr-util: Fix CFLAGS used in build igt-gpu-tools: Fix reproducibility issue libsecret: Improve determimism ptest-packagelists: remove libinput-ptest linux-yocto/5.4: update to v5.4.101 linux-yocto/5.4: update to v5.4.99 libinput: less parallism to increase chances the test suite works bitbake: Force parser shutdown after catching an exception bitbake: runqueue: Add setscene task overlap sanity check bitbake: runqueue: Fix task execution corruption issue linux-yocto: update genericx86* to v5.4.94 yocto-uninative.inc: version 3.0 incorporate seccomp filter workaround yocto-uninative.inc: version 2.11 updates glibc to 2.33 parted: Fix reproducibility issue valgrind: Increase timeout duration 30 -> 90 s oeqa/pam: Need shadow installed for the tests bitbake.conf: Split PSEUDO_IGNORE_PATHS to be more readable bitbake.conf/image: Move image specific PSEUDO_IGNORE_PATHS to image class populate_sdk: Add directories to PSEUDO_IGNORE_PATHS image: Add directories to PSEUDO_IGNORE_PATHS epiphany: Fix distributor contamination from /etc/os-release epiphany: Fix reproducibility issue wic: Warn if an ext filesystem affected by the Y2038 problem is used externalsrc: Pass through npmsw URIs in SRC_URI gcr: Fix reproducibility issue cups: Fix reproducibility issues asciidoc: Switch to using the main branch sstatesig.py: show an error instead of warning when sstate manifest isn't found bitbake.conf: Introduce FAKEROOTLOGS variable used by bitbake to print pseudo.log babeltrace2: Fix reproducibility report-error.bbclass: Add layer and bitbake version info to error report python3: Fix python interpreter line length for nativesdk libevdev: Update patch status to backport rsync: Fix group name determinism issue rsync: Fix a file sorting determinism issue openssl: upgrade 1.1.1i -> 1.1.1j systemd: Fix importd requirements comment linux-firmware: upgrade 20201218 -> 20210208 wpebackend-fdo: Fix missing .so symlink when using dev package oeqa/commands: Fix compatibility with python 3.9 oe/recipeutils: Fix copying patches when BBLAYERS entries are not normalised package_rpm: Enable use_source_date_epoch_as_buildtime in package_rpm class mtd-utils: Remove duplicate assignments to alternative link names npm.bbclass: avoid building target nodejs for native npm recipes go: Update to 1.15.8 cve-check: add include/exclude layers cve-check.bbclass: add layer to cve log df.py: Add feature check for read-only-rootfs groff: Fix determinism issue linux-yocto/5.4: update to v5.4.98 linux-yocto/5.4: update to v5.4.96 valgrind: Disable ptest nlcontrolc for x86-64 git: Fix determinism issue xorg-minimal-fonts: Really fix determinism xorg-fonts-minimal: Fix reproducibility rootfs_deb: handle aarch64 SDK_ARCH bitbake: __init__.py: Fix bitbake debug log handling documentation: version bumps for 3.2.2 release acpica: Fix reproducibility issues bison: Fix up file name mapping systemd: Re-enable chvt as non-root user without polkit xmlto: Fix reproducibility watchdog: Avoid reproducibility failures after fixing build watchdog: Fix determinism issue from sendmail host path oeqa: reproducible: Add more logging oeqa: reproducible: Fix SSTATE_MIRRORS variable buildtools-extended-tarball: Add glibc-gconvs needed for build quilt: Be determnistic about column presence package_manager/deb: Fix image generation with package removal deb: export INTERCEPT_DIR for remove actions vim: Fix a race over creation of the desktop files vim: Improve determinism weston-init: Fix weston-keyboard path in weston.ini cwautomacros: Ensure version is set deterministically opkg: Fix patch glitches opkg: Fix build reproducibility issue pseudo: Update to include fixes for glibc 2.33 weston: remoting backend requires GStreamer base plugins libomxil: Fix up commercial license flag tcf-agent: Fix build on riscv32 connman: update to 1.39 pseudo: Update for rename and faccessat fixes oe-pkgdata-util: Check if environment script is initialized wic: debug mode to keep tmp directory initrdscripts: init-install-efi.sh install extra files for ESP
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
where is the definitive/canonical layer for TPM stuff?
Robert P. J. Day
i just noticed that both of the layers meta-secure-core and
meta-security: https://github.com/jiazhang0/meta-secure-core https://git.yoctoproject.org/cgit/cgit.cgi/meta-security seem to include a good deal of TPM/TPM2 content ... is there a primary layer for that stuff? rday
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: OPencv 3.1 with Rocko
#rocko
rohit jadhav
Observed same error.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|