nyuuzyou/wikis huggingface dataset:
Bugzilla Templates

==Bugzilla Guidelines==
We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in the Yocto Bugzilla.
* Be patient with others: Sometimes people post imperfect bug reports. In case of missing information, kindly tell reporters how to provide it, and/or suggest what they can do to improve the bug report.
* Stay on topic: Don't start endless debates on topics not directly related to the scope of a specific bug report.
* Use proper quoting practices: Avoid quoting complete previous comments by stripping unneeded lines, and avoid answering above the quoted text.
* Don't abuse your privileges: Submitters have permission to edit their bugs. If you abuse this privilege - for example, by reopening a bug that the maintainers have closed - your privileges will be revoked.
What to do if you find a bug
* Search first: Try to avoid filing duplicates by searching to see whether your issue has already been filed.
* Ask: You can ask on our mailing lists or IRC channels to see if anyone has seen this issue before to gather more details or see if someone has a workaround.
* Submit a bug report: Give us as many details as possible about what happened and how your issue can be reproduced. IMPORTANT: please include the build/commit ID as reported by BitBake, as this will help the team determine whether your bug has been fixed already.
* Track our progress: Get feedback from the development community and track resolution status.
* Provide a fix: Use the tools, project wiki and git source repository in the Yocto Project to fix the problem yourself. 
Learn more about our process for reporting bugs.
==Bugzilla Templates==
Here are 3 options for different templates, which can be cut an pasted into the Description Section of the bug, if these do not suite your needs feel free to create a new one.
=== Feature Enhancement Template ===
1. Feature Description:
2. Feature Present Code Status(including location and version):
3. Code License (e.g. GPLv2):
4. Business Impaction:
5. Other Justification:
=== General Bug Template===
Preconditions/Environment
-------------------------
List here what is the setup used.
Triggering Action/Cause
-----------------------
What how to make the phenomenon to happen.
Expectation
-----------
What should happen.
Actual Result
-------------
What really happens
Reproducibility
---------------
m/n
Where:
n = total number of attempts
m = number of times the phenomenon is visible
===QA Report Template===
BUILD CONFIGURATION
IMAGE TYPE:
STEPS TO REPRODUCE: 
EXPECTED OUTCOME: 
ACTUAL OUTCOME:
Build/SCM/Release Interest Group

==Overview==
This group is for discussion of all things having to do with Yocto Build/Release and git repository maintenance. 
* Contact Eflanagan for more info
===Release Process===
Please see Yocto Release Engineering for the full release process. 
====Yocto 1.1 Release Info====
Yocto 1.1 Schedule
Yocto 1.2 Schedule
Third Party BSP Release Process
====GPG Signing Key for the Yocto Project Git Repo====
This public key is used by Beth Flanagan, the Yocto Project Build and Release Engineer for tag signing of all Major/Minor/Point Releases and Release Candidates, post Bernard 1.0.
 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)
mQENBE3VnhEBCADHRXFx4DTFEYQ/uT96Tuy0L6xXiJW6J0sypDIFxWzPMxW33pef
CNyuil80acWMUMTW+m3aTcplaLegD4+Y87OWtscd4Oz/WpssOdqu3GfWRJ8p0zJ1
ztc2SLmq19ZPW8T23w06HRPssbxTri8O/gbczsdK4t2SQ2YbCzsv0v8i2WTIdhjC
tfcSsJnH5VMmlsya2LYPTHVrurZ/BccNe8MUqZMkAFREmQVeCMf7O7YIB4Z3tSfX
12mZD9/M30i0oycRhtyfD9pyrC7xxGU4r+RG1c/EuWsz1qpzdy7L6nemWN5MqL5y
MH8NXovgA4yZzGllRjtJwy6ywtUxlSSNzv3XABEBAAG0U0VsaXphYmV0aCBGbGFu
YWdhbiAoWW9jdG8gUHJvamVjdCBCdWlsZCBhbmQgUmVsZWFzZSkgPGVsaXphYmV0
aC5mbGFuYWdhbkBpbnRlbC5jb20+iQE4BBMBAgAiBQJN1Z4RAhsDBgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRDazhCxVC4ivl+6B/wMQvX45Yh+VSI2J8CDmBFY
tlBaBUlqHn7ilfWGg4PXvgYBAJHFU3jfDgTRdQRmFLgs0LAVwF+GYXF9ns7K/oag
QEx+uyE0gkA9atzl9VcEMM29lVIRmbAiif9ElPjYb/yz3TFKtAC55PzZ9UM/4VKc
FMeW4abcvvbOla1YjWDOEpxTK37jPHh+G+iDpDIXAKlNGgze0UYqsFXPYepOWLqB
i13/ERi1fFjwnBZ0nRrJoxp03nUAkYy/f5zjH1mPRZyjgxAnjf/07Ivb246Fiy0Y
iFVqMfiUNK9pwrHI0Tci2gF8ZVLGsbcfNPrjL3uKzGwIno/2DAz8huYiYyKXBRKy
uQENBE3VnhEBCADNkGJiAhwkEquajEnxBdvh7r5qEDDrsTBNwFSaZIKcaE4Le4Tv
jaTbk3dH0+1ZacE5Ie3/574jjXXJBvEtuEtNcMiEFz9oE62wMLNHohuHY9Oz0i8R
EUHX60fWmCzjW9A9bHx16XZWEZN+6touI4YU/MG8m9Md5I6yausyGj+vcC3KHTgK
zNYy14uuT+av5yO2IzOqdreDw/aGeWPFpla3Q2xbuRE2mPAKOJCuCkjyDPlHbwLA
6e+rdvV3RXq2OY3xRIOANPLq/okOdS0ghvhMsx5l03oliVoXSKcY20CxA0jinuR+
2DzF3np6gSwU9cYtolMDIqk0Eyv+QTNbice9ABEBAAGJAR8EGAECAAkFAk3VnhEC
GwwACgkQ2s4QsVQuIr6IhggAoRErygEaFF754JbdiM0JJdev4X1JHHA0T3WdmsZW
+Xo6lyHaT+roLNTR1xFkU8WHGuPBUp5zdIqbU6MnGcq1cvKPxjtBykzrmvjLJhby
nMW7deG/ByqSW97EMFUyaDFHbl1iwNlJdfQQ/OjNIundLev2EGq9f3u67WgrVC4w
LmFifhY0pGeBtqtD2odpl46pSVamVRkCySJU2qK+alkDIi4zGutc3bMb5TbPBl4q
ui8vto+Emk3UOPBgCze9Z7x3YzRP9euH2ZpSGH6oaV7ZLctD8d44NOyxXWkgxOK6
6vdkQR9+sBVa5fQgeEDm15Cu3/bszgP/NtI8oj8NzSYZYw==
=oHhw
-----END PGP PUBLIC KEY BLOCK-----
Build Appliance

__TOC__
=== About ===
The Build Appliance is a project under The Yocto Project umbrella.
The purpose of the Build Appliance is to use Yocto to build a virtual machine image, inside of which (i.e. when run) one can perform Yocto builds.
Another tangential purpose of the Build Appliance is for testing Pseudo. The Yocto Project uses up-to-date packages for every component on master. An image built with master will include the latest glibc, etc. Using this Yocto-built image in which to build Yocto verifies that Yocto (and therefore pseudo) works with all the latest host packages.
=== Design ===
The following document was created when the Build Appliance was initial conceived. It is a planning/design document for the Build Appliance's initial inception:
Build Appliance Design.
In time the Build Appliance lost its maintainer and stopped working. In 2023 an effort was made to revive it. Updated notes about the Build Appliance from this time can be found at: Build Appliance 2023.
Build Performance

Note that this is fairly old and may be out of date.
This page is intended to serve as a guide to tweaking your build system and bitbake configuration for optimal build time as well as to provide some guidance on how to collect build metrics and identify bottlenecks.
== General Tips ==
Some general tips on how to ensure good performance of builds:
* Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.
* Use the ext4 filesystem for the build disk
* Turn off journaling for ext4 ("tune2fs -O ^has_journal <disk>")
* Mount using the options "noatime,barrier=0,commit=6000"
* Use a tmpfs for /tmp
== bb-matrix ==
The bb-matrix.sh script (scripts/contrib/bb-perf) can be used to collect all the relevant metrics of the TIME(1) command for a build. The bb-matrix.sh generates a datfile similar to the following (trimmed for display purposes):
 BB PM %e %S %U %P %c %w %R %F %M
 04 04 7584.13 3106.60 19818.78 302% 10038479 53837200 2381052920 52972 1857632
 04 05 7488.93 3143.40 20344.21 313% 10290920 53308215 2380549395 51668 2027232
 04 06 7524.69 3141.34 20575.58 315% 10287288 53626500 2380333579 51820 2027248
 04 07 7464.62 3141.47 20741.94 319% 10613016 53459858 2381025909 50929 2027376
 04 08 7570.45 3151.23 20949.85 318% 10625744 53485726 2382061127 52367 2027232
 05 04 7479.95 3254.95 20444.40 316% 13858856 50054205 2387500546 53457 2027232
 05 05 7494.82 3282.37 20643.16 319% 14274000 49852477 2380346993 52289 2027248
 05 06 7432.55 3277.54 21049.68 327% 14340685 49998524 2380221845 53622 2027376
 05 07 7377.66 3300.18 21238.96 332% 13926958 50634688 2384699997 53851 1941840
 05 08 7408.57 3297.64 21306.12 332% 14139864 50330053 2380869210 54169 1912272
The bb-matrix-plot.sh script can then be used to visualize this data, generating images like the following:
== buildstats ==
If you enable buildstats (by adding INHERIT += "buildstats" to local.conf) you will get detailed build performance log data in tmp/buildstats.
Richard Purdie has modified pybootbootchartgui to parse this data and produce pretty charts.
== parallelism ==
Small builds do not scale to a large number of cores, due to package inter-dependencies. Going far beyond 8 is not giving much benefit. Here is a graph of a 64-core machine building core-image-minimal with different build parameters:
Bigger builds are less hampered by linear dependency chains, and fill the cores better.
== discussion ==
Build system performance is a recurring mailing list topic. Here maybe there is Richard Purdie discussing the challenges of improving many-core build performance and package dependency issues. The first link fails, possibly because of database renumbering?.
As it is recurring, here is Richard Purdie discussing a build performance analysis chronicle in 2016.
Since the "performance analysis chronicle" focused on configure to a large extent, I was curious as to how/if the use of configure cache's would affect a build. The results from a limited experiment on building bash, are viewable on Configure Cache Effects on Bash Build.
CVE-2023-44487 impact

= (WIP) CVE-2023-44487 (HTTP2 RapidReset issue) =
This is a synchronization wiki page to coordinate work on CVE-2023-44487 (known as HTTP/2 Rapid Reset issue) impact in the Yocto Project. When you have new information, do not hesitate to update/add to this page.
== OE-core ==
* go
Status: Fixed (master)
Master version: 1.20.10 (fixed, commit 262d5386c6293dbd6b9c677fbb7ed7431651db5)
Nanbield version: Under analysis
Kirkstone version: 1.17.x, need backport
Dunfell version: Under analysis
Sources: https://go.dev/doc/devel/release#go1.20
* lighthttpd
Status: not affected
Sources: https://redmine.lighttpd.net/boards/2/topics/11188
* nghttpd2
Status: Fixed (master)
Master version: 1.57.0 (fixed commit c24b75f027f2609dac935e8981f2eb58394b1cc6)
Nanbield version: Under analysis
Kirkstone version: 1.47, need backport
Dunfell version: Under analysis
Sources: https://github.com/nghttp2/nghttp2/releases/tag/v1.57.0
== meta-openembedded ==
* apache2
Status: Not affected
Sources: https://chaos.social/@icing/111210915918780532
* ngnix
Status: Likely not affected, configuration check needed. We MIGHT want to include the hardening patch
Master version: Under analysis
Nanbield version: Under analysis
Kirkstone version: Under analysis
Dunfell version: Under analysis
Sources: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ and https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html
* nodejs
Status: Affected, via a dependency on nghttpd2
Master version: 20.5.1, need update to 20.8.1, patch pending https://lists.openembedded.org/g/openembedded-devel/message/105567
Nanbield version: 20.5.1, need update to 20.8.1
Kirkstone version: Under analysis
Dunfell version: Under analysis
Sources: https://github.com/nodejs/node/pull/50121 and https://github.com/nodejs/node/releases
== meta-java ==
* tomcat
- Includes tomcat 5.5.26 which is outdated. No more analysis
CVE Triage

Rough notes on the CVE triage process, to be expanded:
Weekly CVE reports to go yocto-security@lists.yoctoproject.org and openembedded-core@lists.openembedded.org.
Trends available at https://autobuilder.yocto.io/pub/non-release/patchmetrics/, also links to the latest report eg https://autobuilder.yocto.io/pub/non-release/patchmetrics/cve-status-master.txt.
The reports list the found CPE identifiers and links to the NIST page.
== Triage Process ==
For each CVE, read the summary and description.
Is this even relevant? Some CVEs are false-positives, eg may be specific to Windows. If the CVE is inappropriate add to CVE_CHECK_IGNORE. For example CVE-2008-1033 only applies to the CUPS that is part of macOS, so the cups recipe has:
 # Issue only applies to MacOS
 CVE_CHECK_IGNORE += "CVE-2008-1033"
Look at the references. Follow any links to bugs or commits. Has this CVE been fixed upstream? Has that fix made it into a release?
If the CVE has been released then the CPE information (the list of vulnerable releases) may need updating: email cpe_dictionary@nist.gov explaining what release has the fix and why, and they'll update the page. If in your research you have better references (such as the commit which fixed the issue) then submit an Update References request to https://cveform.mitre.org.
If it hasn't been released then can the fix be backported easily? Best to grab the git repo and cherry-pick the commit to the release tag to avoid fuzz. Add the patch to the recipe with your Signed-off-by, a CVE: tag, and Upstream-Status: Backport.
Compliancy Discussion

== Working Draft of Compliance Proposal ==
The current working draft can be found here 
== Yocto Project Aligned ==
To use this term in connection with any product or project or in marketing materials you need to:
* Be working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks.
* Be promoting the OpenEmbedded Architecture, layer model and BSP format
* Be making visible contributions in the OpenEmbedded and component projects of the Yocto Project 
* Aim for compatibility and interoperability between different metadata layers.
* Be an open source project, charity organisation, small business or consultancy or member of the project. Larger companies (80+ employees) may also meet this criteria but are strongly recommended to be members of the project.
== Yocto Project Powered ==
To use this term in connection with any product or project or in marketing materials you need to:
* Be able to satisfy all the criteria for "Yocto Project Aligned"
* Be an open source project, charity organisation or a member of the Yocto Project
* Be able to answer 'Yes' to all the criteria in the compliancy checklist.
== Yocto Project Powered Compliancy Checklist ==
* If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? (Y/N)
* If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components?
* Have all patches applied to BitBake and OpenEmbedded-Core (if present) been discussed with the open source community? (Y/N)
* Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes for it and what dependencies or version requirements it has? (Y/N)
* Do all layers present build cleanly against OpenEmbedded-Core with only the dependencies/requirements listed in their documentation? (Y/N)
* Does any hardware support follow the format defined in the Yocto Project Board Support Package (BSP) Developers Guide? (Y/N)
* Are hardware support, configuration (distro) policy and recipe meatdata clearly separated into different layers which do not depend on each other? (Y/N)
* Is clear documentation of which combinations of layers, recipes and machines were tested included? (Y/N)
* Where any item in the "Yocto Project Powered Compliancy Recommendations" list is not true, is this documented in the testing documentation? (Y/N)
== Yocto Project Powered Compliancy Recommendations ==
* Linux kernels are either based around LTSI kernel versions or are more recent that the last LTSI release
* Everything should build successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard?
Contributors Manual

Note: The Yocto Project and OpenEmbedded Contributor Guide should be the place to store this information.
Plans for a hypothetical Maintainers Manual (which doubles as a Contributor manual).
* Patch guidelines (style guide (code and patch description), patch tags)
** What to look for before sending? (No warning added, tests to do)
** A checklist
* Patch submission process (git-send-email, lore, master-then-branches)
** What does it mean to review a patch? (kernel doc "Submitting patches" has an example of this)
* CVE Triage process
* Autobuilder
Some related sparse info elsewhere :
* Yocto docs: Contributions and Additional Information
* Yocto docs: Making Changes to the Yocto Project
* Newcomers
* Community_Guidelines
* Poky_Contributions
* Submitting patches: the essential guide to getting your code into the kernel
Cookbook

[WORK IN PROGRESS]
'''
This Yocto Project Cookbook collects working examples of how to use the Yocto Project, filling some of the gaps between the
Yocto Project Quick Start Guide and the
full reference documentation. Like any
cookbook, we'll include both basic and complex examples you can follow to learn about the pantry of
components and files available, and about the techniques for manipulating them using Yocto Project tools.
We encourage you, the Yocto Project community, to add 
* your own examples,
* pointers to training materials, 
* tips,
* and any other material that may be helpful to new and experienced users of Yocto Project.
Please test all procedures before adding them to this page; and if you do see a problem or improvement, start a 
discussion (use the discussion tab at the top of this page)
, or edit the page itself!
== Cookbook Topics ==
* Adding packages to your OS image
* Application Development with Extensible SDK (Test Kitchen)
* Understanding the fetch/unpack/configure/build/package pipeline
* Locating and understanding failures
* [[Cookbook:Example:Understanding the tmp/work directory structure]] (and what goes where)
* Intro to writing recipes
* Package management
* Application Development with Legacy SDK (Test Kitchen) 
* Configuring your kernel
* Upgrading your kernel
* What else ... ?
== Other Links ==
;Quick Start Guide
:The official Yocto Project Quick Start Guide contains a step-by-step walk-through showing how to set up your environment and perform your first build
;Developer Manual: Common Tasks
:The Common Tasks section of the Yocto Project Developer Manual's documentation discusses creating layers, customizing images, writing recipes, configuring and patching the kernel, performing automated runtime testing, and more.
;Creating a Custom Embedded Linux Distribution for Any Embedded Device Presentation from ELC 2016 Dev Day
:A good overview presentation from the Linux Foundation covering many topics for creating a custom embedded Linux distribution with Yocto Project.
Here are links that were in a previous version of this Cookbook. (Some seem rather outdated that we'll need to comb through, but we wanted to keep them around for now.)
;Everything you need to know to create and maintain a Yocto BSP
:TomZ's page on how to create and maintain a Yocto Project BSP, including how to interact with the community 
;Startup scripts
:How to get things to happen or start automatically:
Creating a recipe for a Qt application

Creating a recipe for a Qt application is usually fairly straightforward and not much different to creating a recipe for any other kind of application; there are a few things specific to Qt that are worth noting however. This page is intended to cover these specifics.
== Selecting the appropriate class to inherit ==
If you wish to build against Qt/X11, you should add the following to the recipe:
 inherit qt4x11
Alternatively, for Qt/Embedded (i.e. for framebuffer/DirectFB output), add this instead:
 inherit qt4e
This will set up the appropriate build-time dependencies for your application.
== Running qmake ==
qmake_base.bbclass, which both qt4x11 and qt4e inherit, will run qmake automatically as part of the normal do_configure step.
If you need to set any configuration variables or pass any options to qmake, you can add these to the EXTRA_QMAKEVARS_PRE or EXTRA_QMAKEVARS_POST variables, depending on whether the arguments need to be before or after the .pro file list on the command line respectively.
By default, all .pro files will be built. If you want to specify your own subset of .pro files to be built, specify them in the QMAKE_PROFILES variable.
== Dependencies ==
The build system's normal shared library dependency generation will take care of setting up runtime dependencies such that all of the appropriate Qt libraries needed by your application will be installed alongside it. However, if your application requires other Qt components that are not directly linked to your application (such as Qt image plugins) then you will need to add these dependencies within the recipe, for example:
 RRECOMMENDS_${PN} += "qt4-plugin-imageformat-jpeg qt4-plugin-imageformat-tiff"
Alternatively, if you want to be a bit more flexible you can add these for installation within your custom image recipe instead.
== Example recipes ==
There are example Qt application recipes in OE-Core under meta/recipes-qt/qt-apps/.
Cross-Prelink

== Project Background ==
The upstream prelink project was founded by Jakub Jelinek at Red Hat. The upstream project is primarily focused on self-hosted configurations and does not support prelinking a target filesystem in a cross-development environment.
This limitation is due to the prelink software requiring the runtime linker to be available in order to resolve linking dependencies.
The cross prelink patches began at MontaVista around 2003 in order to work around this limitation. The original patches added the ability to emulate a runtime linker, as well as enabled a sysroot option. Over time, this work was continued by MontaVista, Wind River and CodeSourcery. Unfortunately, while all of the patches had been made public in one fashion or another, there was no central location that gathered and offered to manage these changes. Starting with the Yocto Project we have decided to put together these patches and make them available as a single unit, with a clear upstream that will happily accept patches.
== Upstream Prelink ==
The upstream prelink project is located at sourceware.org.
For mailing lists, see: http://sourceware.org/ml/prelink/
For SVN access to the upstream tree, see: svn://sourceware.org/svn/prelink/
== Yocto Project Cross-Prelink ==
See the https://www.yoctoproject.org/tools-resources/projects/cross-prelink page on the website for more information on this project.
Mark Hatle -- User:Mhatle is the project maintainer for the cross-prelink component of the Yocto Project.
== Patch Submission ==
For Yocto-generic information on patch submission, see the Contribution Guidelines.
For cross-prelink specific information, see README.cross.
== Git Archive Branches ==
The main branches of interest of the git archive are:
* cross_prelink contains the cross-prelink sources.
* cross_prelink_staging contains proposed changes for the cross-prelink sources.
* master tracks the upstream prelink tree. Note that this may or may not be up to date.
== Testing prelink/cross-prelink on Ubuntu ==
On recent Ubuntu versions, the default gcc passes -Wl,--as-needed to the linker by default (see here for more info). This will cause some prelink/cross-prelink tests to fail. This can be worked around by passing overrides in CC and CXX to make check:
 
$ make check CC='gcc -Wl,--no-as-needed' CXX='g++ -Wl,--no-as-needed'
On recent Ubuntu versions, the libraries are layed out according to the multiarch spec. This causes most cross-prelink tests to fail. This can be worked around by passing a library path to prelink-rtld:
 
$ make check LDD="../src/rtld/prelink-rtld --library-path=/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu"
Design feedback v2

ED: why it's not possible to add packages if image is not built? As far as I understood user should be able to add packages
from other layers. I agree it's a bit tricky to add packages to the unknown set, but still.
ED: Would it make sense to show only built images in the list of base images for customization? It would simplify UI even more. We are forcing user to build an image to be able to customize it. Why not go further and make the procedure even more simpler?
ED: What does it mean 'Package size'? Is it image size or something else?
ED: What about editing of .bb files?