nyuuzyou/wikis huggingface dataset:
Netbook-ltp

==1.0/M2==
total: 33 (100%)
*LTP: 0
*NAB: 2
*Fixed: 0
*Duplicated: 31
*pending: 0
*not started: 0
similarity: 30 (90.00%):
 msgctl10 alarm06 quota_remount_test01 
LTP cases 	status 	owner 	error msg 	lsb	comment 	bugzilla
msgctl10 	NAB 	Kevin Tian	TBROK : Unexpected signal 2 received.	n/a	this can't be reproduced. normally "unexpected signal 2" received because Ctrl-c is clicked. need double-confirm next time	n/a
alarm06 	NAB 	Kevin Tian	n/a 	n/a	from the LTP output this case actually succeeds. can't reproduce here too. need double confirm next time 	n/a
quota_remount_test01	Blacksand	n/a 	n/a 	n/a	n/a 	n/a
ioctl03 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
lchown02 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
lchown02_16 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
ioctl03 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
lchown02 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
lchown02_16 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
sysctl03 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog02 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog03 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog04 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog05 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog07 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog08 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog09 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
syslog10 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
su01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
cron02 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
cron_deny01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
cron_allow01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
cron_dirs_checks01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
ld 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
ldd 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
file 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
tar 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
cron 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
logrotate 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
cpio 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
unzip01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
gzip01 	qemux86 	n/a 	n/a 	n/a	n/a 	n/a
New QA process

== Intro ==
Given the new QA tooling (resulttool) available to manage QA test results and reporting, here was the proposed new QA process. First release to implement this process was 2.7_M3_RC1.
The new QA process consists below:
 Test Trigger
 Test Planning 
 Test Execution
 Test Result Store
 Test Monitoring & Reporting
 Release Decision
== Test Trigger ==
Each QA team will subscribe to QA notification email (request through Richard Purdie). The list of notifications is maintained on config.json in the yocto- autobuilder-helper which has a branch per release.
== Test Planning ==
Once received the QA notification email, each QA team (eg. intel, windriver, etc) will perform planning on what extra tests they plan to run and when they'll send the results back, then reply to the QA notification email with the planned extra tests and estimate of execution time to QA stakeholders (eg. Richard Purdie, Stephen Jolley), yocto mailing list and the lead QA team. Each QA team can refer to OEQA for automated and manual test cases for their planning. The lead QA team no longer need to setup Testopia and wiki page. 
== Test Execution ==
Each QA team will execute the planned extra tests. To make sure test result from the test execution could fully integrated to the new QA tooling (resulttool for test result management and reporting/regression), execute OEQA automated tests and OEQA manual tests through resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#manualexecution). 
== Test Result Store ==
Each QA team will store test result to the remote yocto-testresults git repository using resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#store), then send the QA completion email (include new defects information) to both QA stakeholder and the lead QA team. 
== Test Monitoring & Reporting ==
QA stakeholder will monitor testing progress from remote yocto-testresults git repository using resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#report). Once every QA team completed the test execution, the lead QA team will create QA test report and regression using resulttool, then store the report and regression into https://wiki.yoctoproject.org/wiki/Main_Page. Send email report to QA stakeholder and public yocto mailing list.
== Release Decision ==
QA stakeholder will make the final decision for release.
Newcomers

== Overview ==
The goal of the Newcomers Guide is to connect people using the software with resources for learning about and contributing to the project. If you just want to get starting building with Yocto, the Quick Start Guide is for you!
As you have questions, these are the two manuals that can help you understand both Bitbake and Yocto.
Also, feel free to ask questions on our mailing lists or stop by our IRC channel.
==Resources for Learning==
There is a getting started video that will give you a high level overview of the Yocto Project.
Rudi Streif gave a great talk at the Embedded Linux Conference in 2015.
For more presentations, check out our presentation page for a full lists of talks given about the Yocto Project.
Rudi has also written a book, "Embedded Linux Systems with the Yocto Project".
Otavio Salvador and Daiane Angolini have also written a book, "Embedded Linux Development with Yocto Project".
==How to Contribute==
First, and most important, is to read our community guidelines.
If you have changes that are specific to poky, there is a page discussing contributions to poky on this wiki. Also of note, the OpenEmbedded wiki has a page where you can learn how to submit a patch to oe-core or meta-openembedded. There are various patch guidelines, as well as a styleguide which you should familiarize yourself with before submitting a patch.
The Yocto Project tracks bugs using bugzilla. You may want to review our bug guidelines to help understand this process.
==Newcomer Bugs==
The Yocto Project has a newcomer bug category which are bugs suited to someone new to the project, in order to learn more about the development process within our community, and become familiar with the project.
The list of such bugs can be found in the table below:
==Helpful Links==
*OpenEmbedded Layer Index - A collection of layers that can be used with OpenEmbedded.
**https://layers.openembedded.org
*Recipe reporting system - Yocto recipes upstream status reporting.
**http://recipes.yoctoproject.org/
*OpenEmbedded Patchwork
**https://patchwork.openembedded.org
*Yocto Downloads - Yocto releases, as well as some other supported and archived software.
**http://downloads.yoctoproject.org/
*Error reporting tool - View a sortable, traceable list of errors thrown during a Yocto build.
**http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/
**http://errors.yoctoproject.org/Errors/Latest/Autobuilder/
NoMorePython2

= No More Python 2! =
== Problem Statement ==
Python 2 is in maintenance mode and everyone should shift to Python 3. We've made the move in OpenEmbedded Core so that core-image-sato doesn't pull in Python 2, but Python 2 is still needed during the build.
There are two ways in which Python 2 is needed:
# Use of /usr/bin/python on the host
# Explicit dependency on python-native
== Goal ==
To be able to build first core-image-sato and then world of OpenEmbedded Core without Python 2 being present on the host, or being built via python-native.
== Method ==
To find implicit dependencies on the build host having Python 2, one option is to just remove Python 2 from your build host. Whilst this works, unless you're building inside a container this might not be feasible. The next best thing is to make the binary not executable briefly for the test builds. Sadly you can't remove Python 2 from HOSTTOOLS as several upstreams will explicitly poke around /usr/bin looking for a Python to run.
To find recipes that depend on python-native then simply build an image/world/whatever with -g and search the resulting task-depends.dot. For example, building core-image-sato for intel-corei7-64 results in:
 "core-image-sato.do_build" -> "bmap-tools-native.do_build"
 "bmap-tools-native.do_prepare_recipe_sysroot" -> "python-native.do_populate_sysroot"
So, an image depends on bmap-tools-native which depends on Python 2.
Patches, from ready to submit to utter hacks, are being collected in poky-contrib:ross/nopy2.
== Status ==
=== Done ===
* bmaptool
* texinfo-dummy-native
=== Patches Ready ===
* ca-certificates (in ross/nopy2)
* libsoup
* grub
* pseudo
* ninja
=== To Review ===
* xcb-proto (do all callers use py3)
=== Broken ===
* python3-pycairo (new upstream uses distutils)
* webkitgtk
* ovmf
* eglinfo-x11 eglinfo-fb (waf update?)
** Waf uses Python 2 by default
** Add waf-native to oe-core
** Extend waf class to invoke waf-native using Python 3
** Use waf class in recipe
* SCons (scons 3 is working towards py3)
=== Needs Python 2, actively refuses to use Python 3 ===
* apr
* qemu (https://bugs.launchpad.net/qemu/+bug/1708462)
Nodejs Workflow Improvements

== Summary ==
Many industry pundits predict that IoT will not be built by traditional C/C++ embedded developers as there just aren't enough of them to go around. The 2016 Stack Overflow developer survey shows JavaScript to be the most popular language. Node.js is a popular JavaScript runtime environment. These two data-points indicate that Node.js is likely to become increasingly popular among IoT developers. The Yocto Project has some support for npm project packaging, but can be enhanced to better support the typical Node.js workflow.
== Workflow Assumption ==
Typical workflow involves tinkering with npm on the target and then locking down once app is working.
== Proposals and Opens ==
* Comprehend Node.js LTS and decide what version we support
* Move nodejs into openemebdded core?
* Should we create a node.js category in Bugzilla ?
* Create image for node development (core-image-nodejs) with node and npm (and what else?)
* Once project is working on target, how do we package it. devtool cleverness that sucks files from target?
* Extend devtool to handle multiple layers to help structure complex projects
== Tasks in Bugzilla ==
See Project Management bug #10653 that has all current Node.js tasks/bugs as dependencies.
Old resolved bugs and features

= Old Milestone - Bugs Need Verification - BY OWNER (3.X) =
= Old Milestone - Bugs Need Verification - BY OWNER (2.X) =
= Old Milestone - Bugs Need Verification - BY OWNER (1.X) =
= Old Milestone - Enhancements Need Verification - BY OWNER (2.5+) =
= Old Milestone - Enhancements Need Verification - BY OWNER (2.1) - (2.4) =
= Old Milestone - Enhancements Need Verification - BY OWNER (1.X) =
OpenGL pass-through in QEMU

== Overview ==
The OpenGL pass-through in QEMU is used to 'redirect' the OpenGL calls running on the emulated target to the host's native OpenGL library. This brings an important speed up on the execution speed of the target applications that use OpenGL. It is currently available only for x86 targets. It consists on a number of a set of QEMU patches.
== Details ==
Edwin Zhai created an in-depth presentation about the OpenGL pass-through (see attachment below).
Package Exclusion

== Introduction ==
This page describes some proposed updates to the INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms within Poky for the Yocto Project version 1.1. See also License Infrastructure Interest Group for some overlapping work (particularly for the first part of the proposed implementation below).
== Aims ==
* Make error messages clear when user/dependencies have asked for something to be built that can't be due to restrictions
* Ensure that exclusion system is reliable
== Proposed implementation ==
# Ensure all documentation of LICENSE field value syntax is clear, concise and up-to-date (wiki and manual) [Beth/ScottR ?]
# Go through and audit all recipes LICENSE field values to ensure that they all conform to the specifications. This includes making sure that | (package may be used under one of a selection of licences) and & (recipe has mixed licences that apply to the code base, so conditions of all must be observed) are used correctly. [Beth]
# bitbake/core changes:
#* LICENSE field checking must fully parse the field and understand the difference between | and &, and must not e.g. mark Qt as being GPLv3 only.
#* All error messages should be clear about which version of a package is being excluded not just the name (different versions may have different licences)
#* Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)
#* Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a deny list which also includes flags indicating the reason for deny-listing
#* Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch GPL3 as apposed to GPLv3) - if not, error out
#* Check when calculating dependencies if anything is scheduled to be built that is on the deny-list - if any are, gather all of them up and then stop and list them in an error message along with reason and depchain for each one
#* Check when constructing the rootfs if anything in the runtime provides denylist is going to be included - if so, error out
Some further possible extensions:
* Possibly apply similar logic to COMPATIBLE_MACHINE?
* Replace COMMERCIAL* with some more generic exclusion mechanism that allows the reason to be defined as part of the exclusion list?
* As a helper for non-en_US users, fail on parse if user defines any of the *LICENSE* variables as *LICENCE*? (we definitely don't want the build to continue and just ignore this as the user might not realise what has happened)
Patch Triage

The Yocto Project community is experimenting with a regular patchwork triage meeting; to triage, review, and assign incoming patches.
Everyone is welcome to attend, the call is held on Thursdays at 08:30 - 09:30 PST (the hour after the Bug Triage call). Other meetings may be added to cater for other timezones or if there are more patches than can be triaged.
The focus of the meeting is to triage new patches in patchwork: https://patchwork.yoctoproject.org/project/oe-core/list/
=== Process ===
This process is inspired by the process the glibc project use.
# Obtain last patch ID reviewed from the minutes
# Iterate through the patches since the last patch reviewed, oldest first. Quickly review as a group and assign a delegate and provisional status:
** Looks Good: move to Under Review status. Will be incorporated into a staging branch by the delegate so that if it fails testing the status can be changed.
** Looks Bad: move to Rejected status. Note the feedback in the minutes, the delegate is responsible for responding on the list with this feedback.
** Needs Work (quick): move to Action Required. Note the feedback in the minutes, the delegate is responsible for responding on the list with this feedback.
** Needs Further Review. Move to Action Required. Note this choice in the minutes, and either discuss later in the call or in the Engineering Sync. It is the responsiblity of the delegate to have this discussion.
# Discuss any patches marked a Needs Further Review, and any other patches that the group wish to discuss.
# Review the state of all patches that have been delegated but not yet resolved.
# Note down in the minutes the last patch ID reviewed, for the next meeting.
=== Patch State Summary ===
* New: Nobody has reviewed it yet
* Under Review: The patch is under review and testing. Change the delegate to the reviewer.
* Accepted: There is consensus for merging this patch.
* Rejected: There is consensus for not merging this patch.
* RFC: The patch is a Request for Comments to solicit feedback and doesn't need to be tracked further.
* Change Requested: The patch has been reviewed and needs further work.
* Superseded - A newer version of the patch exists.
* Deferred - Review of this patch is waiting for another event to happen.
TODO There is ambiguity around the "Accepted" state. Should this indicate a patch which is ready to be merged, or only for patches that have already been merged? Glibc has a "committed" state to handle this.
TODO Now thinking Under Review until merged (accepted) or rejected (rejected).
=== Minutes ===
==== 2023-10-12 ====
...
Performance Test

== Build time tracking ==
Script used for running the builds: 
*Before morty: poky/scripts/contrib/build-perf-test.sh
*After morty: poky/scripts/oe-build-perf-test
Two identical test systems are used for the results, with all updates available installed. Extra packages installed (besides what's by the default in the distro) are the ones in the Quick Start guide.
Configuration of the GDC Setup 2.1 - Current master
* Ubuntu 15.10 (Wily Werewolf)" --> 4.2.0-16-generic
* Fedora release 23 (Twenty Three) --> 4.7.10-100.fc23.x86_64
* HW configuration: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 16GB RAM, 1 x 600 GB SDD, 1 x 2 TB HDD
All system/distro settings are distro's defaults, that includes:
- FS mount options: ext4 rw,relatime,data=ordered 
- IO scheduler: cfq and CPU governer: ondemand
local.conf it's the default one (the script doesn't touch it except for changing DL_DIR if necessary).
It however exports these in the enviroment:
 BB_NUMBER_THREADS = "8"
PARALLEL_MAKE = "-j 8"
MACHINE = "qemux86"
FAQ:
*Q: Where is 1.5_M2? It's there but it's called: 1.5_M1.final-412-geaa5df3 The M2 build wasn't released hence no git tag
*Q: What's with the different number of RCs? See Yocto_Project_Release_Process#Milestone_Releases
*Q: Why are there more results for some commits? The script is ran from a cron job multiple times a day, sometimes master changes daily sometimes it doesn't, hence more results for one commit (ie weekends)
== Daily Test Results ==
Build performance test suite is run multiple times per day. Latest test reports for master branch can found here:
* Ubuntu 16.04
* Ubuntu 16.04 (Intel® Xeon® HW)
* CentOS 7
* OpenSUSE Leap 42.2 (retired)
* Fedora 25 (retired)
* Fedora 23 (retired)
* Ubuntu 15.10 (retired)
== Milestone Test results ==
Guadalajara Setup from 2.1 M4 to actual master 
* GDC Charts
== Old Test results ==
Milestone test results from the retired Romania Setup (Yocto 1.6 – 2.1) can be found from here:
* RO Charts
Raw test data from the retired Romania test setup has been moved to
* Performance_Test_Old_Results
* Performance_Test_Weekly_1.5 has the old weekly results ran during the 1.5 cycle.
Configuration for the Romania Setup 1.6 - 2.1:
* Ubuntu 12.04 (uname -nr: ubuntu12 3.8.0-31-generic) and 
* Fedora 19 (uname -nr: fedora19 3.11.3-201.fc19.x86_64)
* HW configuration: SandyBridge i7-2600 CPU @ 3.40GHz (4 cores/8 threads), 8GB RAM, 1 x 500 GB HDD
Poky/GettingStarted/Dependencies

NOTE: This page is no longer maintained. For a up-to-date build host requirements please see the Quick Start Guide.'''
== Fedora ==
To run Poky on Fedora (tested on F13 and F14) you will need to install the following dependencies:
yum install patch gcc gcc-c++ texinfo wget diffstat texi2html makeinfo svn chrpath git
If you want to build qemu you will also need
yum install SDL-devel mesa-libGLU-devel mesa-libGL-devel
== RHEL/CentOS 6.x == 
In the 6.x series of RHEL/CentOS all required dependencies are available in the distribution repositories:
 yum groupinstall "Development Tools"
 yum install patch diffstat texi2html texinfo subversion chrpath git wget
If you want to use qemu you will also need:
 yum install SDL-devel mesa-libGL-devel mesa-libGLU-devel
Finally RHEL/CentOS on x86_64 hosts includes 32bit glibc, Poky will try and build various tools with both 32bit and 64bit compatibility. You can either enable this to proceed by installing the headers for 32bit glibc:
 yum install glibc-devel.i686 
or alternatively you can disable the 32bit library support by adding NO32LIBS = "1" to your local.conf
== RHEL/CentOS 5 ==
There are two options for To run Poky on CentOS (tested on CentOS 5.5) you will need to follow several steps. Poky requires a more recent (2.6) version of Python than is shipped with RHEL/CentOS 5.x and therefore we need to install a Python 2.6 or 2.7 interpreter.
One approach is to use the EPEL repository: https://fedoraproject.org/wiki/EPEL
This includes the required Python 2.6 and chrpath but may affect other Python applications running on the system.
With EPEL installed you may follow the instructions for CentOS 6.x above only making note that the name of the 32bit glibc package is glibc-devel.i386 *not* glibc-devel.i686.
Alternativel, to enable use of Poky in a non-intrusive manner the Yocto project provides a standalone Python tarball. Grab the appropriate python-nativesdk-standalone from http://downloads.yoctoproject.org/releases/miscsupport/
This tarball also includes the chrpath utility.
Add the python directory to your PATH:
 /opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/python
or
 /opt/poky/sysroots/i586-pokysdk-linux/usr/bin/python
Next you will need to install the required package dependencies:
 yum groupinstall "Development Tools"
 yum install patch diffstat texi2html texinfo cvs subversion git wget
If you want to use qemu you will also need:
 yum install SDL-devel mesa-libGL-devel mesa-libGLU-devel
Finally CentOS on x86_64 hosts includes 32bit glibc, Poky will try and build various tools with both 32bit and 64bit compatibility. You can either enable this to proceed by installing the headers for 32bit glibc:
 yum install glibc-devel.i386 
or alternatively you can disable the 32bit library support by adding NO32LIBS = "1" to your local.conf
Poky Contrib

=Poky Contrib Pruning=
To keep poky-contrib from growing endlessly we move branches that have not been updated to poky-contrib-archive. We are planning to do this quarterly.
Before doing the move we will e-mail users so they can prune branches that do not need to be archived.
==Exempt poky-contrib Branches==
These branches need to stay in place but are no longer receiving updates. They might be referenced in documentation or used in established workflows. Please feel free to add your branches.
* cagurida/compliance
* rpurdie/daisy
* rpurdie/datasock
* rpurdie/jethro
* rpurdie/krog
* rpurdie/master-next
* rpurdie/mpx
* rpurdie/multiconfig
* rpurdie/mut
* rpurdie/mut-rp
* rpurdie/nfsroot
* rpurdie/python3
* rpurdie/pythonsdkfixes
* rpurdie/rewitt
* rpurdie/tizen
* rpurdie/wip
* rpurdie/wip-rss
* rpurdie/wip-rss2
* rpurdie/wip-temp
* rpurdie/wip-temp2
* rpurdie/wip5
* rpurdie/wipqueue
* rpurdie/wipqueue2
* rpurdie/wipqueue3
* rpurdie/wipqueue4
Processes and Activities

Welcome to the Processes and Activities Page!
* Contribution Guidelines
* Recipe & Patch Style Guide
* Building your own recipes from first principles
* Development Best Practices
* Distro Tracking
* Best Known Methods (BKMs) for Package Updating
* Working Behind a Network Proxy
* QA
* Kernel
* Core
* Bugzilla Configuration and Bug Tracking
* Bug Triage
* Yocto Point-Release Development Workflow
* Yocto Release Engineering
* Performance
* Security
* PAM Integration
* Program Management Plan
* Enable sstate cache
* Guidelines for contributing to meta-intel layer
* Building and running embedded Linux .NET applications from first principles
Projects

== Welcome to the Projects Page ==
* AutoBuilder
* Poky
* Pseudo
* Cross-Prelink
* QA
* Documentation
* BSPs
* Tracing and Profiling
* Linux Kernel
** Boot Time
** Image Size
* Multilib
* BitBake GUI's
* x32 abi
* Build Appliance
* Toaster
* OpenGL pass-through in QEMU
* Running an x86 Yocto Linux image under QEMU KVM
* Web Application for Interactive Kiosk Devices
* Virtualization with KVM
* Poky-Tiny
* System Update
* Wayland
== Archived Projects ==
* Eclipse Plug-in
* Anjuta Plug-in
* SDK Generator
* Hob2 (Hob v2)
* DLNA Media Server Virtual Appliance
* Swabber
* Baryon
* ELC2013kiosk_demo