nyuuzyou/wikis huggingface dataset:
DNS Configuration

DNS
openembedded.org 	A 	85.214.40.226
bugs.openembedded.org 	A 	80.81.242.146
cgit.openembedded.org 	A 	140.211.169.165
docs.openembedded.org 	A 	80.81.242.146
git.openembedded.org 	A 	140.211.169.165
gitweb.openembedded.org 	A 	140.211.169.165
lists.openembedded.org 	CNAME	openembedded.org
new.openembedded.org 	A 	80.81.242.146
patchwork.openembedded.org	A 	80.81.242.146
tinderbox.openembedded.org	CNAME	tinderbox.openembedded.net
wiki.openembedded.org 	A 	80.81.242.146
www.openembedded.org 	A 	80.81.242.146
Category:Community
Darwin

===Initial notes regarding OE builds on Darwin / OS-X machines===
I am currently testing on i386-darwin.
Notes:
* Use the darwin branch (though currently all of its changes have been merged to master)
* touch conf/sanity.conf, to ignore the chrpath, help2man checks
* touch classes/relocatable.bbclass to avoid the need for chrpath
* touch classes/packaged-staging.bbclass, to work around tar --owner issue
* Note that there *are* some issues remaining with case sensitivity, eglibc is one, it's unable to be fetched. Currently working around this by doing builds in a mounted disk image, sparse, case-sensitive journaled.
* Have *not* managed a complete task-boot as of yet, the bugs have to be fixed one by one as they're encountered, for the most part.
Dealing with checksum mismatch

It happens occasionally that incorrect SRC_URI checksums are being committed or that upstream changes tarballs without changing the filename. In both cases, OE will bail out and complain about a mismatch in checksums. This is a potentially serious issue and it is important to resolve the situation with care.
Firstly, try a bitbake xxxx -c cleanall and try re-fetching the download to ensure this wasn't just a bad download. If it continues to fail, post on the mailing list for the layer concerned and ask whether others are seeing the issue. It can also be worth downloading the file externally from bitbake/OE to confirm its not a fetcher issue.
If there is some mirror with a bad file on it, that file can be removed and a request needs to be made to the maintainer of the mirror server. If the original commit was made with an incorrect checksum, this can also generally easily be identified and corrected.
If upstream itself has changed the tarball, this is a much more problematic situation and we need to understand why this has happened, what the change is and then made a decision on how to proceed.
Above all, the most important thing is not to just blindly change the checksum to the current matching value without understanding why the change has occurred - if you do you could then be using source code which has been tampered with as part of your build.
Category:Policy
Category:FAQ
Deprecate distutils

== Deprecating distutils*.bbclass ==
In Python 3.10 `distutils` has been deprecated and is to be removed in Python 3.12. In preparation for this, the `distutils*` classes have been deprecated and nearly all usage in oe-core has been removed.
We still have a few recipes under the meta-openembedded umbrella that inherit one of the `distutils` classes (the lowest common denominator is `distutils-common-base`)
To get a list, you can run the following command:
 $ bitbake-layers show-recipes -i distutils-common-base -r
This is a call to arms, please help by picking one of the following.
=== List of recipes inheriting distutils* ===
Recipe 	Layer 	Version	Latest 	Upstream 	Assignee 	Status
cxxtest 	meta-oe 	v4.4 	v 	cxxtest.com 	RossBurton 	In review
gammu 	meta-oe 	v1.32.0	v1.42.0	wammu.eu 	Moto-timo 	In progress review
iotop 	meta-oe 	v0.6 	v 	guichaz.free.fr 	RossBurton 	In review
lirc 	meta-oe 	v0.10.1	v 	lirc.org 	Oleksandr Kravchuk	In progress review
python3-dbussy 	meta-python	v1.3 	v 	github.com 	RossBurton 	In review (bug)
python3-greenlet	meta-python	v1.1.2 	v 	greenlet.readthedocs.io	Ross Burton 	In review
python3-hexdump 	meta-python	v3.3 	v 	pypi.org 	RossBurton 	In review (remove)
python3-pycrypto	meta-python	v2.6.1 	v2.6.1 	pycrypto.org 	RossBurton 	In review (Obsolete, remove)
python3-pyparted	meta-python	v3.11.7	v 	github.com 	RossBurton 	In review (bug)
python3-smbus 	meta-python	v4.3 	v 	kernel.org 	RossBurton 	In review
pyxdg 	meta-oe 	v0.26 	v 	freedesktop.org 	RossBurton 	In review
sanlock 	meta-oe 	v3.8.4 	v 	pagure.io 	RossBurton 	In review. Upstream bug
Deprecation Policy

= Recipes and metadata deprecation policy =
Here is deprecation policy and guidelines for recipes and related metadata maintained in layers under meta-openembedded repository
= Why: =
* Reduce the security gap
* Increase quality of layer and recipes
* Reduce technical debt
* Improved developer productivity
= Challenges: =
* Obsolete code adds to maintenance burden.
* Old code consumes developers’ time which could be better focused elsewhere
* Can’t tell who is using things
* Sometimes recipes are one-off contributions which are unmaintained
* There might be a perception that obsolete/removed recipes from OE-Core can be added to meta-oe
* Users aren’t often paying attention to development branches, only release branches
* Full meta-openembedded builds consume significant resources. Long builds slow down development and narrows down testing matrix
* Obsolete recipes adds inertia towards new developments
* Older/obsolete recipes tend to become of poorer quality more so over time as they are either not brought to use latest stuff or are simply missing it.
Keeping this in sight, here is a proposal to define some guidelines for community to assess recipe deprecation
= Deprecation guideline criteria: =
* Recipe is not buildable
* Recipe has known security issues (particularly high impact ones)
* package's upstream is not actively responding to build or security issues (e.g. a large patch backlog)
* Functionality from recipe has been obsoleted by other recipes and no longer commonly used
* Recipe has no activity upstream (no activity for e.g. 5+ years is a concern)
* Recipe with many architecture exclusions and isn’t portable but not hardware specific recipe
* It is not a key dependency for large set of recipes/layers (check layer index using depends:[recipename])
* Niche specific recipe may better moved to a more focused topic layer
* Poor quality recipe or recipe build environment with no maintainer willing to improve
* Recipe has problematic host dependencies (e.g. 32-bit runtime) and no maintainer improving situation
= Process: =
* Maintainer can remove if the decision is clear to them and has discretion over the process
* For unclear situations, exclude from parsing initially with reason documented
* Notification is in the form of a patch adding the exclusion
* After a reasonable time if not fixed, recipe is removed
* Recipe removals scheduled after each release point
* If someone addresses the underlying issues the recipe can be added back or have parsing re-enabled.
* If there is a conflict, issue can be raised to OE TSC for a decision
Category:Policy
Devshell

Q: I want to get a shell where all the variables OE and the recipe defines (CC, CFLAGS, ARCH, ...) are set.
When a build fails, it is often useful to interactively build the part that is failing. Because OE sets up the build environment, it may not be obvious how to quickly reproduce such an environment. This is where the interactive devshell can help you.
== Background ==
One technique that can be use is:
* cd into tmp/work/<failing package dir>/<failing package build dir>
* copy ../temp/run.do_compile.. x (or do_install or whatever task is failing)
* edit x and replace the do_compile (at the end of the file) function call w/ bash 
* ./bash --norc (you now have a shell w/ the environment set up properly for doing a build)
* make (debug issues, etc)
* exit (when done to go back to shell without run.do_compile settings)
== Setup devshell ==
The above is mainly for illustration purposes. A better/quicker way to set up a development shell is this.
* Add 'devshell' to your local.conf's INHERIT variable and enjoy the power of devshell by running it like this:
 bitbake -c devshell <target>
* You now have all the environment variables set up to correctly to run configure, make, etc.
The following variables affect the terminal handling:
 TERMCMD = "${SCREEN_TERMCMD}"
 TERMCMDRUN = "${SCREEN_TERMCMDRUN}"
 
 # Some common terminal programs to choose from
 # for GNOME
 TERMCMD='gnome-terminal --disable-factory -t "$TERMWINDOWTITLE"'
 TERMCMDRUN='${GNOME_TERMCMD} -x $SHELLCMDS'
 # for screen
 TERMCMD='screen -D -m -t "$TERMWINDOWTITLE"'
 TERMCMDRUN='${SCREEN_TERMCMD} $SHELLCMDS'
 # for xterm
 TERMCMD='xterm -T "$TERMWINDOWTITLE"'
 TERMCMDRUN='${XTERM_TERMCMD} -e $SHELLCMDS'
 # for KONSOLE
 TERMCMD='konsole -T "$TERMWINDOWTITLE"'
 TERMCMDRUN='${KONSOLE_TERMCMD} -e $SHELLCMDS'
If you set these from e.g. your .bashrc do not forget to add them to BB_ENV_EXTRAWHITE
E.g. 
 export BB_ENV_EXTRAWHITE="TERMCMD SCREEN_TERMCMD"
== How to get a Screen-Devshell working ==
Using the above variables create you a devshell. Unfortunatelly you can't see anything because a new screen session is created - not a new tab in the existing session. Just use a new (SSH) connection to your (remote) account and list your screen sessions with screen -list. The last one should be your devshell and you can connect to it with screen -r <id>.
== X11 connection rejected because of wrong authentication ==
Sometimes if you try to run devshell remote over SSH with X11 redirection this error occurs:
 X11 connection rejected because of wrong authentication.
 ERROR: function do_devshell failed
The problem seems to be the XAUTHORITY handling. The following part in .profile helped some users.
 if [ -e "$HOME/.Xauthority" ] ; then
 export XAUTHORITY="$HOME/.Xauthority"
 fi
Category:FAQ
Category:Debug build
Document Consolidation

This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual as a sort of Contributors Manual.
When a page has been consolidated, redirect it to the YP docs and cross it off the list (but please keep it in the list for posterity)
* https://git.yoctoproject.org/meta-yocto/tree/meta-poky/README.poky.md
* https://git.openembedded.org/bitbake/tree/README
* https://git.openembedded.org/openembedded-core/tree/README.OE-Core.md
Redirect complete (check after docs are published):
* https://www.openembedded.org/wiki/Styleguide
* https://www.openembedded.org/wiki/Versioning_Policy
* https://www.openembedded.org/wiki/Getting_started
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
* https://wiki.yoctoproject.org/wiki/Poky_Contributions
* https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project
* https://www.openembedded.org/wiki/Recipe_License_Fields
* https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Documentation

Documentation that relates to OpenEmbedded.
== Yocto Project Manuals ==
The most up-to-date manuals relating to OpenEmbedded (in particular, the new OpenEmbedded-Core) is the Yocto Project documentation, in particular the Quick Start Guide, Development Manual and Reference Manual.
See for links to all the manuals.
== Solutions for common problems ==
* Set PREFERRED_PROVIDER for jpeg and jpeg-native
== Bitbake Manual ==
Bitbake Manual
== Other ==
Guides and HowTos:
* Bootlin's freely available Yocto Project and OpenEmbedded training materials
* How to Capture OE Source Code Changes to a Package
* How to submit a patch to OpenEmbedded
* List of Executable tasks Usage: bitbake -c <task>
Category:User
Category:Dev
Donate

Your donations to the OpenEmbedded Project help keep the project running smoothly. Historically, OpenEmbedded depended on the generosity of individuals and organizations to cover expenses for hardware to support project operations, meeting space, travel and publicity.
Due to the success of OpenEmbedded it is clear we need to start active fund raising so we can reduce out dependence on other entities and reduce out of pocket expenses for people contributing to the project.
==How to Donate==
OpenEmbedded is an associated project of Software in the Public Interest a US based 501c3. They handle donations for us. Use the donate button on the left of the page to donate via PayPal. Recurring donations really help us understand our income stream and that helps us plan for expenses, but one time donations are always welcome.
For more information how to donate read the SPI page on donating. This should be helpful if you are not based in the US.
For US people (and possibly people working for US corporations) there are programs that can match the value of your donation. Many employers match donations to 501c3's. Please check your company benefits package to see if your company does.
Some companies will donate on your behalf to organizations you do volunteer work for. Many people also work on OpenEmbedded outside regular business hours. Check if your company makes such donations. This is a great way to support OpenEmbedded financially!
And yes, the doublethedonation website is annoying, but is a good explanation of these programs.
Donating to OpenEmbedded

Your donations to the OpenEmbedded Project help keep the project running smoothly. Historically, OpenEmbedded depended on the generosity of individuals and organizations to cover expenses for hardware to support project operations, meeting space, travel and publicity.
Due to the success of OpenEmbedded it is clear we need to start active fund raising so we can reduce out dependence on other entities and reduce out of pocket expenses for people contributing to the project.
==How to Donate==
OpenEmbedded is an associated project of Software in the Public Interest a US based 501c3. They handle donations for us. Use the donate button on the left of the page to donate via PayPal. Recurring donations really help us understand our income stream and that helps us plan for expenses, but one time donations are always welcome.
For more information how to donate read the SPI page on donating. This should be helpful if you are not based in the US.
For US people (and possibly people working for US corporations) there are programs that can match the value of your donation. Many employers match donations to 501c3's. Please check your company benefits package to see if your company does.
Some companies will donate on your behalf to organizations you do volunteer work for. Many people also work on OpenEmbedded outside regular business hours. Check if your company makes such donations. This is a great way to support OpenEmbedded financially!
And yes, the doublethedonation website is annoying, but is a good explanation of these programs.
==Merchandise==
Polo, Sweatshirts and T-shirts with an embroidered OpenEmbedded logo: https://www.hellotux.com/openembedded
Your board members have bought a few and they do help us look more professional. Certainly more respectable than the usual T-Shirt. We found ordering a size larger than we normally wear helps.
Donations

Here the OpenEmbedded project lists one-time donations in form of hardware or money. We have separate page for ongoing sponsorship.
= Money =
2009: 1500€ Eukréa Electromatique ARM based System on Module, Hardware Engineering, Embedded Linux Development and Training.
2010: 3000$ Texas Instruments
= Infrastructure =
Details about the services can be found on our infrastructure page.
* Hosting for melo by OSU Open Source Lab / nslu2-linux.org
* CPU for the melo server by BEC Systems
* 3 Harddisks for the melo server by Eukréa Electromatique
= Misc =
* New logo design by BugLabs, Inc.
* OEDEM 2010 venue and catering by Intel
Doom Demo

This page contains information about the OpenEmbedded Doom Demo for use at the conference booth
NOTE: This demo is still under construction
== Hardware ==
Boards
* Raspberry Pi 4 (any RAM amount should work)
* Raspberry Pi 0 W? Maybe not, these are horrendously expensive unless someone wants to donate one
* ODroid H3
* Libre Le Potato?
* .... some RISC-V board?
Other Hardware
* Network Switch
* USB SD-Card reader
* USB M.2 Adapter or USB SSD, depending on what the Odroid can boot from
* HDMI Touch Screens (one for each board)
* USB Game Controller for each board (currently planning on a Logitech F310)
* Speakers for sound? Maybe just for one board?
== Software ==
The repository for building the software images to run on these boards can be found at https://github.com/JPEWdev/oe-doom-demo. Please read the instructions in that repository for how to build the software.
NOTE: This repository is still waiting on a few upstream changes before it is fully functional
Dusseldorf, 2014

==Location ==
Congress Centre Düsseldorf, Düsseldorf, Germany
October 14, 2014 at 1300 - 1500 in room 111 (room changed, was 10 before).
== Agenda ==
* Financial report
* Election of new members
* Discussion about future of e.V. (started in 2013)
== Forms ==
* Proxy form 
== Attendance ==
* Leon 'likewise' Woestenberg
* Denys 'denix' Dmytriyenko
* Sean 'darknighte' Hudson
* 'Khem' Raj
* Andrea 'g1zer0' Galbusera
* Marco 'mckoan' Cavallini - (proxy for Andrea 'ant_work' Adami)
* Martin 'JaMa' Jansa
* Mark 'fray' Hatle
* Henning "woglinde" Heinold
* Anders Darander
* Richard Purdie (proxy for Paul Eggleton + David Stewart)
* Koen Kooi (proxy Graeme)
* Phil 'Crofton' Ballister
Non members present and elected to become members 
* Nicolas Dechesne
Non members not present but elected to become members 
* Trevor Woerner
* Gary Thomas
* Tim Orling
* Apelete Seketeli
== Meeting notes ==
Meeting opened 13:05
* Atendees Documented
=== Financial Summary Presented ===
* Various forms had to be filed
* Challenges due to lack of German address and language barriers
* SPI Account created with one donation
* No other changes to accounts
* Treasures report approved
=== New member vote ===
* New member vote for all new members except gary
** Passed with all in favour
* New member vote for Gary
** Two objections were raised, all others were in favour
=== Member expiration ===
* Member expiration needs to be handled
* Added as an agenda item for next board meeting
** Board expects to provide feedback to members within one month
=== e.V. structure ===
* Discussion about e.V. structure and whether it still works for the project
* Board recommends replacing the e.V. with something else, exact proposal to be determined in 18 months
* Historically, three things were and are needed for the project. These resulted in the formation of the e.V.
** Financial
** Ownership (e.g. domain names)
** Decision making ability (which implies membership list)
* Currently, the financial issues are covered by SPI, others open question
* Goal is to get the OE membership more involved by reducing the overhead involved with the e.V.
* Members present had no objections for board looking into this
* By the next GA, the board plans to have a proposal to vote on
** Must be well in advance for proxy instructions
=== TSC ===
* Koen formally resigned from TSC
* Board needs to setup TSC elections
* General discussion about the role of the TSC
Meeting Closed at 14:05
== Financial Summary ==
* OpenEmbedded e.V. bank accounts hold EUR 1731. SPI account holds EUR 127.
* Overhead due to lack of German address and language barriers, we now have a German volunteer that provides us with a German address for tax declarations etc. and proxies postal documents.
* Exempt from taxes over 2010, 2011 and 2012.
* Spending were USD 50 (Philip?) on hosting, not yet declared.
* Received EUR 128 worth of donations via SPI http://www.spi-inc.org/donations/
* Treasures report approved
== Action Items ==
Category:General_Assemblies
Edinburgh, 2013

==Location ==
Edinburgh International Conference Centre, Edinburgh, UK
October 25, 2013 at 1830 - 1930 in Harris 1.
== Agenda ==
* Financial report
* Election of new members
== Forms ==
* Proxy form 
== Attendence Record ==
(Proxies are in brackets)
* Marco Cavallini 'mckoan' (proxying for Eric Bénard 'ericben')
* Paul Eggleton 'bluelightning' (proxying for Andrea Adami 'ant')
* Philip Balister 'Crofton' [board member]
* Richard Purdie 'RP'
* Martin Jansa 'JaMa' (Simon Busch 'morphis')
* Denys Dmytriyenko 'denix' [board member]
* Koen Kooi 'koen' ( Khem Raj 'khem')
* Anders Darander
* Mark Hatle 'fray' (Otavio Salvador 'otavio')
* Sean Hudson 'darknighte' [board member]
* Saul Wold 'sgw'
* Stefan Schmidt
* Leon Woestenberg 'likewise' [board member]
* David Stewart
* Jefro
* Scott Garman
Non members present and elected to become members
* Jack Mitchell
* Andrea Galbusera
* Ross Burton
Non members not present but elected to become members
* Bruce Ashfield
* Ulf Samuelsson
== Meeting notes ==
 Meeting opened 18:35
 Attendees Documented
 Financially Summary Presented
 * Euro 1731
 * Taxes had to be filed, issues due to board transition
 * German language issues and documents required to be at a German address. Lots of overhead
 * No spending in last financial year
 * No donations received either
 * Setup SPI affiliation to allow for funds to be collected in and held in the US
 Financial Report Approved
 Discussion of possible uses for collected funds:
 Things membership generally in favor of:
 - travel sponsorship preferred 
 - ship event box for conferences
 - create additional event box for NA
 - financial availability for emergency hardware
 - promotion at events
 Things membership generally not in favor of:
 - sponsorship at events e.g. coffee breaks
 Discussion about future of e.V. and whether SPI (as an example) would make sense
 - nobody against dissolving e.V. in principle
 - Feeling that board should investigate and consult members and come up with a proposal
 Meeting Ended 19:20
== Action Items ==
# Board to review alternate legal structures including affiliation with foundations, e.g. Apache, Gnome, etc
# Board to put together draft budget proposal
# Members: Investigate opportunities for "hack fest" sponsorship (close to conferences)
Category:General_Assemblies