https://www.openembedded.org/api.php?action=feedcontributions&user=PaulEggleton&feedformat=atomOpenembedded.org - User contributions [en]2024-03-19T09:18:48ZUser contributionsMediaWiki 1.29.0https://www.openembedded.org/index.php?title=Document_Consolidation&diff=11108Document Consolidation2023-04-17T22:00:54Z<p>PaulEggleton: Add contrib pages</p>
<hr />
<div>This page lists the various sources of user documentation that should be consolidated into the Yocto Project User Manual<br />
<br />
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)<br />
<br />
* https://www.openembedded.org/wiki/Styleguide<br />
* https://www.openembedded.org/wiki/Getting_started<br />
* http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded<br />
* https://wiki.yoctoproject.org/wiki/Poky_Contributions<br />
* https://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-change-to-the-yocto-project</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=11099Layers FAQ2023-02-23T20:45:38Z<p>PaulEggleton: Add info on submitting a bug</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the ''same email address'' as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@microsoft.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]]. These recipes can also be found in the [http://layers.openembedded.org/layerindex/oe-classic/recipes/ OE-Classic] section in the layer index.<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
=== How do I report an issue with the layer index? ===<br />
<br />
On the [https://lists.yoctoproject.org/g/yocto yocto mailing list], or if you have a concise description of a bug, please file it in the [http://bugzilla.yoctoproject.org Yocto Project bugzilla].<br />
<br />
=== I'd like to contribute improvements to the layer index code/design, how can I do that? ===<br />
<br />
The code can be found on [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ git.yoctoproject.org]. It uses the Django web framework and split into two parts - the web-based frontend that you interact with, and an update script that runs periodically to gather information about all of the layers in the database. There's further information in the README file on how to contribute.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=IRC&diff=10860IRC2021-05-31T18:08:48Z<p>PaulEggleton: Fix typo</p>
<hr />
<div>= Channels =<br />
Server: irc.libera.chat<br />
* [https://kiwiirc.com/nextclient/ #oe] - for discussions relating to the building and testing of Open Embedded and for debugging of the building of distributions with OE. If you need help with a distribution based on OE or a GUI environment shipped with OE, then PLEASE go to one or more of the following channels instead<br />
* [https://kiwiirc.com/nextclient/ #yocto] - for discussions relating to the Yocto Project.<br />
<br />
To reduce spam, the irc channels require you to have an account on irc.libera.chat, so anon access via Kiwi irc webclient needs some<br />
setup.<br />
<br />
Register your nickname on irc.libera.chat [https://libera.chat/guides/registration following this instructions]<br />
<br />
= Bots =<br />
There is also infobot, which gathers various information from the channels. Poke around.<br />
<br />
= Channel-Logs =<br />
<br />
Conversation in those channels can be reviewed at:<br />
* http://infobot.rikers.org/<br />
<br />
= IRC Clients =<br />
* Mac OS X: http://homepage.mac.com/philrobin/conversation/ | http://colloquy.info/ | http://www.pidgin.im/<br />
* GNU/Linux, *BSD: http://www.irssi.org/ | https://hexchat.github.io/ | http://www.pidgin.im/<br />
* Windows XP: http://www.xchat.org/ |http://www.pidgin.im/<br />
* Windows Vista/7: http://www.pidgin.im/<br />
* Opie: Opie-Irc <br />
* Firefox: Chatzilla (very easy to install and use)<br />
* https://kiwiirc.com/nextclient/<br />
<br />
[[Category:Community]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=10793Layers FAQ2020-11-23T16:07:18Z<p>PaulEggleton: Update my email address</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@microsoft.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]]. These recipes can also be found in the [http://layers.openembedded.org/layerindex/oe-classic/recipes/ OE-Classic] section in the layer index.<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
=== I'd like to contribute improvements to the layer index code/design, how can I do that? ===<br />
<br />
The code can be found on [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ git.yoctoproject.org]. It uses the Django web framework and split into two parts - the web-based frontend that you interact with, and an update script that runs periodically to gather information about all of the layers in the database. There's further information in the README file on how to contribute.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=User:PaulEggleton&diff=10790User:PaulEggleton2020-10-20T22:39:07Z<p>PaulEggleton: Update very outdated info</p>
<hr />
<div>= Paul Eggleton =<br />
<br />
== About ==<br />
<br />
Free software enthusiast (naturally), based in Auckland, NZ<br />
<br />
* Involved with OpenEmbedded for some years, commit access since late 2007.<br />
* Working for Microsoft<br />
<br />
== Contact ==<br />
<br />
* E-mail: bluelightning@bluelightning.org<br />
* IRC: bluelightning (in #oe and #yocto on freenode)</div>PaulEggletonhttps://www.openembedded.org/index.php?title=TSC&diff=10704TSC2020-04-20T23:46:43Z<p>PaulEggleton: Add 20 April meeting minutes</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by election:<br />
<br />
* Martin Jansa (JaMa) - re-elected Aug 2019<br />
* Richard Purdie (RP) - re-elected Aug 2019<br />
* Paul Eggleton (bluelightning) - re-elected Aug 2019<br />
* Bruce Ashfield elected Aug 2019<br />
* Joshua Watt (JPEW) elected Aug 2019<br />
<br />
Each member serves a two-year term. During election time, one member may stand for election every two months.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Further discussion on how to increase participation in the project<br />
* OE/YP Training and certification<br />
<br />
= TSC mailing list archive =<br />
<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
Meetings are usually held in #oe-tsc on Freenode on 3rd Monday of each month 9PM UTC (10PM UTC during winter time).<br />
<br />
== 2020 Minutes ==<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188966 20 January 2020]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72189000 17 March 2020]<br />
* [https://lists.openembedded.org/g/tsc/message/487 20 April 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188896 21 October 2019]<br />
* [https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/72188949 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=TSC&diff=10696TSC2020-03-17T02:52:56Z<p>PaulEggleton: /* 2020 Minutes */</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by election:<br />
<br />
* Martin Jansa (JaMa) - re-elected Aug 2019<br />
* Richard Purdie (RP) - re-elected Aug 2019<br />
* Paul Eggleton (bluelightning) - re-elected Aug 2019<br />
* Bruce Ashfield elected Aug 2019<br />
* Joshua Watt (JPEW) elected Aug 2019<br />
<br />
Each member serves a two-year term. During election time, one member may stand for election every two months.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC topics =<br />
<br />
This list keeps a running list of topics for the TSC. If you would like to add a topic for discussion, please e-mail one of the TSC members or the list curator [mailto:JPEWhacker@gmail.com Joshua Watt] so that the TSC is aware of the change. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
* Talk about how to acknowledge contributions from community members<br />
* Yocto version tags for released version are in OE-core, should milestone tags be added as well?<br />
* Further discussion on how to increase participation in the project<br />
<br />
= TSC mailing list archive =<br />
<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
== 2020 Minutes ==<br />
* [http://lists.openembedded.org/pipermail/tsc/2020-January/000477.html 20 January 2020]<br />
* [http://lists.openembedded.org/pipermail/tsc/2020-March/000491.html 17 March 2020]<br />
<br />
== 2019 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2019-October/000448.html 21 October 2019]<br />
* [http://lists.openembedded.org/pipermail/tsc/2019-December/000471.html 16 December 2019]<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.openembedded.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.openembedded.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=10531OE-Core Standalone Setup2019-07-16T04:48:14Z<p>PaulEggleton: Update for warrior (late unfortunately)</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout warrior<br />
cd bitbake<br />
git checkout 1.42<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OpenEmbedded-Core&diff=10397OpenEmbedded-Core2018-09-02T21:20:57Z<p>PaulEggleton: </p>
<hr />
<div>== OpenEmbedded-Core ==<br />
<br />
<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev --><br />
<br />
=== Introduction ===<br />
<br />
Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.<br />
<br />
The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") grew organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout was very difficult, and near to impossible to support commercially. Like many other OE forks that were created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.<br />
<br />
OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.<br />
<br />
=== Differences to OE-classic ===<br />
<br />
The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.<br />
<br />
Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.<br />
<br />
Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.<br />
<br />
=== OpenEmbedded-Core scope ===<br />
<br />
The scope of OE-Core itself is as follows:<br />
<br />
* Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)<br />
* Only QEMU emulated machines<br />
* Distro-less (DISTRO = "nodistro" and default values are used)<br />
* Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)<br />
* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core<br />
* Attempt to keep only one version of each recipe<br />
<br />
Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.<br />
<br />
=== meta-openembedded ===<br />
<br />
For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://git.openembedded.org/meta-openembedded/ meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.<br />
<br />
== Getting Started ==<br />
<br />
See [[Getting started]].<br />
<br />
== Available Layers ==<br />
<br />
OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].<br />
<br />
== Creating Layers ==<br />
<br />
See [[Creating a new Layer]].<br />
<br />
== Required changes for existing metadata ==<br />
<br />
See [[Migrating metadata to OE-Core]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OpenEmbedded-Core&diff=10396OpenEmbedded-Core2018-09-02T21:20:13Z<p>PaulEggleton: GPLv2 recipes got moved out so we don't need to mention them here</p>
<hr />
<div>== OpenEmbedded-Core ==<br />
<br />
<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev --><br />
<br />
=== Introduction ===<br />
<br />
Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.<br />
<br />
The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") grew organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout was very difficult, and near to impossible to support commercially. Like many other OE forks that were created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.<br />
<br />
OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.<br />
<br />
=== Differences to OE-classic ===<br />
<br />
The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.<br />
<br />
Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.<br />
<br />
Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.<br />
<br />
=== OpenEmbedded-Core scope ===<br />
<br />
The scope of OE-Core itself is as follows:<br />
<br />
* Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)<br />
* Only QEMU emulated machines<br />
* Distro-less (DISTRO = "nodistro" and default values are used)<br />
* Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)<br />
* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core<br />
* Attempt to keep only one version of each recipe<br />
<br />
Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.<br />
<br />
=== meta-openembedded ===<br />
<br />
For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://cgit.openembedded.org/cgit.cgi/meta-openembedded meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.<br />
<br />
== Getting Started ==<br />
<br />
See [[Getting started]].<br />
<br />
== Available Layers ==<br />
<br />
OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].<br />
<br />
== Creating Layers ==<br />
<br />
See [[Creating a new Layer]].<br />
<br />
== Required changes for existing metadata ==<br />
<br />
See [[Migrating metadata to OE-Core]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=10395OE-Core Standalone Setup2018-09-02T21:15:13Z<p>PaulEggleton: Update for sumo release</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout sumo<br />
cd bitbake<br />
git checkout 1.38<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Getting_started&diff=9839Getting started2017-10-10T00:38:18Z<p>PaulEggleton: Update package lists from latest YP quick start guide</p>
<hr />
<div>== Required software ==<br />
<br />
Before being able to build you will need to install a fairly short list of required software on your host system. <br />
<br />
'''Note:''' for a headless (i.e. non-graphical / server) machine you can skip installing SDL and xterm, these are optional; however without SDL you will not be able to run graphical OS images within QEMU.<br />
<br />
(Lists below borrowed from the Yocto Project Quick Start guide.)<br />
<br />
=== Ubuntu / Debian ===<br />
<br />
sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \<br />
build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \<br />
xz-utils debianutils iputils-ping<br />
<br />
=== Fedora ===<br />
<br />
sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \<br />
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \<br />
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \<br />
python3-pexpect findutils which file cpio python python3-pip xz<br />
<br />
=== openSUSE ===<br />
<br />
sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \<br />
diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \<br />
python3-pexpect xz which<br />
<br />
=== CentOS ===<br />
<br />
sudo yum install -y epel-release<br />
sudo yum makecache<br />
sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \<br />
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \<br />
perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip xz \<br />
which<br />
<br />
== Setup Instructions ==<br />
<br />
At this point you have a number of different alternatives:<br />
<br />
=== Standalone OE-Core setup ===<br />
<br />
As OE-Core can be used to build working images entirely on its own, you can get started with it immediately. <br />
<br />
See '''[[OE-Core Standalone Setup]]''' for instructions.<br />
<br />
=== Systems based upon OE-Core ===<br />
<br />
There are a number of other systems that make use of the OE-Core metadata which provide their own set of setup instructions. Here are some links to "getting started" information for these:<br />
<br />
* [http://github.com/Angstrom-distribution/meta-angstrom/blob/master/README Angstrom]<br />
* [http://shr-project.org/trac/wiki/Building%20SHR SHR]<br />
* [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Yocto Project]<br />
<br />
More can be found in the [http://layers.openembedded.org layer index] (click on ''Layers'', then click on ''Filter Layers'' on the right hand side and make it so ''Distribution'' is the only ticked item.)<br />
<br />
=== Alternative methods ===<br />
<br />
* [[oe-made-easy]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Getting_started&diff=9837Getting started2017-10-10T00:35:09Z<p>PaulEggleton: Update package lists for python3</p>
<hr />
<div>== Required software ==<br />
<br />
Before being able to build you will need to install a fairly short list of required software on your host system. <br />
<br />
'''Note:''' for a headless (i.e. non-graphical / server) machine you can skip installing SDL and xterm, these are optional; however without SDL you will not be able to run graphical OS images within QEMU.<br />
<br />
(Lists below borrowed from the Yocto Project Quick Start guide.)<br />
<br />
=== Ubuntu / Debian ===<br />
<br />
sudo apt-get install cpio python3 gawk wget git-core diffstat unzip texinfo gcc-multilib \<br />
build-essential chrpath libsdl1.2-dev xterm<br />
<br />
=== Fedora ===<br />
<br />
sudo dnf install cpio find which gawk make wget tar bzip2 gzip python3 unzip perl patch \<br />
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \<br />
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue SDL-devel xterm<br />
<br />
=== openSUSE ===<br />
<br />
sudo zypper install python3 gcc gcc-c++ git chrpath make wget python3-xml \<br />
diffstat texinfo python3-curses patch libSDL-devel xterm<br />
<br />
=== CentOS ===<br />
<br />
sudo yum install gawk make wget tar bzip2 gzip python3 unzip perl patch \<br />
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath SDL-devel xterm<br />
<br />
== Setup Instructions ==<br />
<br />
At this point you have a number of different alternatives:<br />
<br />
=== Standalone OE-Core setup ===<br />
<br />
As OE-Core can be used to build working images entirely on its own, you can get started with it immediately. <br />
<br />
See '''[[OE-Core Standalone Setup]]''' for instructions.<br />
<br />
=== Systems based upon OE-Core ===<br />
<br />
There are a number of other systems that make use of the OE-Core metadata which provide their own set of setup instructions. Here are some links to "getting started" information for these:<br />
<br />
* [http://github.com/Angstrom-distribution/meta-angstrom/blob/master/README Angstrom]<br />
* [http://shr-project.org/trac/wiki/Building%20SHR SHR]<br />
* [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Yocto Project]<br />
<br />
More can be found in the [http://layers.openembedded.org layer index] (click on ''Layers'', then click on ''Filter Layers'' on the right hand side and make it so ''Distribution'' is the only ticked item.)<br />
<br />
=== Alternative methods ===<br />
<br />
* [[oe-made-easy]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=9509OE-Core Standalone Setup2017-06-22T13:58:01Z<p>PaulEggleton: Update for pyro</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout pyro<br />
cd bitbake<br />
git checkout 1.34<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=9507Layers FAQ2017-06-22T13:55:37Z<p>PaulEggleton: Remove gitorious reference</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@linux.intel.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]]. These recipes can also be found in the [http://layers.openembedded.org/layerindex/oe-classic/recipes/ OE-Classic] section in the layer index.<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
=== I'd like to contribute improvements to the layer index code/design, how can I do that? ===<br />
<br />
The code can be found on [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ git.yoctoproject.org]. It uses the Django web framework and split into two parts - the web-based frontend that you interact with, and an update script that runs periodically to gather information about all of the layers in the database. There's further information in the README file on how to contribute.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=How_to_submit_a_patch_to_OpenEmbedded&diff=9421How to submit a patch to OpenEmbedded2017-04-25T21:54:49Z<p>PaulEggleton: Add note about patches being delayed during feature freeze</p>
<hr />
<div>OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.<br />
<br />
== Finding the right place for your patch ==<br />
<br />
OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.<br />
<br />
New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].<br />
<br />
== A task-oriented guide to creating a patch ==<br />
<br />
Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.<br />
<br />
=== Set up git ===<br />
<br />
Properly configuring git (using tekkub@gmail.com as an example user)<br />
<br />
On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)<br />
<br />
sudo aptitude install git-core git-email<br />
<br />
These are important to the commit meta-data<br />
<br />
git config --global user.name "Tekkub"<br />
git config --global user.email "tekkub@gmail.com"<br />
<br />
Any Google Apps account<br />
<br />
git config --global sendemail.smtpserver smtp.gmail.com<br />
git config --global sendemail.smtpserverport 587<br />
git config --global sendemail.smtpencryption tls<br />
git config --global sendemail.smtpuser tekkupl@gmail.com<br />
<br />
You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.<br />
<br />
=== Subscribe to the mailing list ===<br />
<br />
You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.<br />
<br />
=== Committing your patch ===<br />
<br />
Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code. <br />
<br />
cd oe-core/ # or whereever you keep your clone of the repo<br />
git add meta/recipes-devtools/flex<br />
git commit -s # don't use the -m option but include my signature<br />
<br />
flex: backport Debian patches to fix generated code warnings<br />
<br />
The generated parser had warnings regarding signess and return check<br />
which makes Linux Kernel's perf tool from 3.4 release to fail without<br />
those patches.<br />
<br />
All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].<br />
<br />
Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.<br />
<br />
=== Sending patches ===<br />
<br />
There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.<br />
<br />
==== Sending using git-send-email ====<br />
<br />
To send just the top commit on your current branch (substitute mailing list address as appropriate):<br />
<br />
git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1<br />
<br />
For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.<br />
<br />
Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:<br />
--subject-prefix="meta-oe][PATCH"<br />
<br />
Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)<br />
<br />
==== Sending via a pull request ====<br />
<br />
Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:<br />
<br />
# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.<br />
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.<br />
# Push the branch to the remote.<br />
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.<br />
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.<br />
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.<br />
<br />
== Community review ==<br />
<br />
Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/<br />
<br />
If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.<br />
<br />
If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.<br />
<br />
== Appendix ==<br />
<br />
=== Steps for people which don't have SMTP access for git === <br />
<br />
Patches should not be sent as attachment but inline.<br />
<br />
If you do not have SMTP access to your email account you have two options:<br />
<br />
1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)<br />
<br />
2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,<br />
wrap lines etc etc).<br />
<br />
A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.<br />
<br />
=== Streamlining git-send-email with configuration ===<br />
<br />
Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.<br />
<br />
<ul><br />
<li>Always confirm sending (for all repositories):<br />
<pre>git config --global sendemail.confirm always</pre></li><br />
<li>Set send-to email address for the repository (don't forget to specify the right address!):<br />
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre><br />
</li><br />
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):<br />
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre><br />
</li><br />
</ul><br />
<br />
==See also==<br />
* [[Commit Patch Message Guidelines]]<br />
* [[Styleguide]]<br />
<br />
[[Category:FAQ]]<br />
[[Category:User]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Migrating_metadata_to_OE-Core&diff=9357Migrating metadata to OE-Core2017-03-22T03:18:33Z<p>PaulEggleton: Mention HOSTTOOLS under master</p>
<hr />
<div>The classes and BitBake configuration used in [[OpenEmbedded-Core]] require a few changes for recipes brought over from OE-Classic (and for new recipes written by developers used to working with OE-Classic).<br />
<br />
== Recipes ==<br />
<br />
The following section lists changes applicable to recipes (.bb files).<br />
<br />
=== Mandatory changes ===<br />
<br />
For recipes the following changes are required in order to build successfully:<br />
<br />
* '''Add LIC_FILES_CHKSUM''': this specifies one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version. It is mandatory and checked at the end of do_configure. See [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-specifying-LIC_FILES_CHKSUM Specifying LIC_FILES_CHKSUM] for more details.<br />
* '''Remove legacy staging''': legacy staging (do_stage) is no longer supported. Items previously in do_stage should be moved to do_install as appropriate; however they should actually install the files to somewhere under ${D} and ''not'' copy them into the staging directory directly or things will break later on. See [[Legacy staging]] for more information.<br />
* '''Ensure LICENSE is present''': the LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.<br />
* '''Ensure SRC_URI checksums are present''': for entries in SRC_URI pointing to sources other than SCMs or local files, i.e. http, ftp, etc., at least one SRC_URI checksum (md5sum/sha256sum) must be provided. If these are not present for an entry where it is required you will get an error which gives you the appropriate values to be added to the recipe. You can use the "name=" parameter within SRC_URI to distinguish between multiple entries. (This used to be optional, now it is mandatory.)<br />
* '''Remove comments in string values''': recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. is no longer allowed. Remove the commented out lines or move them to beyond where the string terminates.<br />
* '''Ensure values are quoted''': current versions of BitBake require that values are quoted; this was optional in the past. Single or double quotes are allowed but all values must now be quoted. (This does not affect how numeric values are interpreted, these have always been treated as strings.)<br />
* '''Use package name override with packaging variables''': the runtime package specific variables (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY, and the pre/post install/uninstall script functions pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm) should always have a package name override. For example, to set a runtime dependency for the main package use RDEPENDS_${PN}.<br />
* '''Replace oe* logging commands''': Any calls to oenote, oewarn, oefatal etc. in shell scripts need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.<br />
* '''Use FILESEXTRAPATHS to extend file search path''': Modifications to FILESPATHPKG and/or FILESPATH (or FILESDIR which is deprecated) should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
Changes applicable to the "danny" release and later:<br />
* '''Python functions should always use four spaces for indentation''' and not tabs - a warning will be produced if tabs are found. Previously four spaces was the convention but many python functions used tabs. This has been fixed in OE-Core and other layers, and since python uses indentation for statement blocks, is very important that you make the same changes to python functions in your recipes.<br />
* '''Change proto= to protocol= in SRC_URI''' - all fetchers have been changed to be consistent. Previously, some fetchers used proto and some protocol.<br />
* '''Change tasks to package groups''' - for custom task recipes, rename them from task-*.bb to packagegroup-*.bb, inherit packagegroup instead of inheriting task and remove anything that is now handled by meta/classes/packagegroup.bbclass. Also change any references to task-* to packagegroup-*.<br />
* '''Change any assumptions that libexecdir is /usr/libexec''': we now set libexecdir to ${libdir}/${BPN} to match with the Filesystem Hierarchy Standard (FHS).<br />
Changes applicable to the "dylan" release and later:<br />
* '''Fix continuation on last line of a comment''': if a comment ends in a line continuation (\) then the next line must also be a comment; any instance where this is not the case will now trigger a warning. Either remove the continuation character or make the next line a comment as well.<br />
* '''Remove use of BROKEN''' - use EXCLUDE_FROM_WORLD instead; ideally fix up the cause of the recipe being marked as BROKEN.<br />
Changes applicable to the "dora" release and later:<br />
* '''Rename functions/variables that currently contain "_remove_" or end with "_remove"''' - _remove is now a BitBake operator, so referencing it when you aren't intending to remove a value from a list variable will result in unexpected behaviour.<br />
Changes applicable to the "daisy" release and later:<br />
* '''Git SRCREV must match up with the branch''': if you are specifying a SRCREV value then it must now be on the branch specified in the URL entry (with the <tt>branch=</tt> parameter, or the master branch if none is specified). Alternatively if you wish to fetch a revision which isn't on any branch, specify <tt>nobranch=1</tt> in the URL.<br />
Changes applicable to the "dizzy" release and later:<br />
* '''Handle B != S in autotools recipes''': if the software being built is capable of building in a separate directory to the source, you don't need to do anything. Otherwise, either patch it so that it does, or inherit <tt>autotools-brokensep</tt> instead of <tt>autotools</tt>.<br />
* '''Handle the --foreign option in autotools recipes''': some older autotooled software does not follow the GNU standards in distributing certain files such as ChangeLog, AUTHORS, etc. Most upstream software packages that need to already tell automake to enable foreign mode themselves, but some recipes will need patches for this change. You can easily make the change by patching configure.ac so that it passes "foreign" to AM_INIT_AUTOMAKE() - see [http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2 this example].<br />
* '''Use pkg-config instead of standalone configuration scripts''': configuration scripts such as xml2-config, pcre-config, freetype-config etc. were being mangled in the past in order to have them return the correct paths within the sysroot, but this is no longer being done - instead of running these scripts, use pkg-config which has proper sysroot support. These scripts will now return an exit code and an invalid option for those calling scripts that don't pay attention to the exit code.<br />
* '''Do not stage the same files in multiple recipes''': overwriting files in the sysroot now triggers an error instead of a warning. Recipes should not be staging files to the sysroot (as a result of installing files within do_install) that are also staged by other recipes; allowing this in the past led to nasty situations that were often difficult to debug.<br />
Changes applicable to the "fido" release and later:<br />
* '''Set CLEANBROKEN if make clean doesn't work''': if a Makefile exists, do_configure runs <tt>make clean</tt> when re-executing in order to clean out generated files. If this isn't expected to work for the software a recipe builds, set CLEANBROKEN = "1" in the recipe.<br />
* '''Ensure dependencies on kernel headers are accounted for''': recipes that rely on the kernel source code/headers that do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example: <code>do_configure[depends] += "virtual/kernel:do_shared_workdir"</code><br />
Changes applicable to the "krogoth" release and later:<br />
* '''Explicitly expand variable references in python functions''': BitBake no longer expands variable references (e.g. <code>${VARNAME}</code>) in python functions - you should now explicitly expand these using <code>d.expand()</code> or simply by calling <code>d.getVar()</code> if you just want to get the value of a single variable.<br />
* '''Ensure recipe names are all lower-case''' - BitBake now requires overrides to be all lower case, which in practice means that anything that can be an override (distro names, machine names and recipe names) must also be lower case if the corresponding overrides are to function.<br />
* '''Ensure calls to d.getVar() and d.getVarFlag() specify the expansion parameter''' - <code>d.getVar('SOMEVAR')</code> and <code>d.getVarFlag('SOMEVAR', 'flagname')</code> are no longer allowed - the expansion parameter is now required. <code>d.getVar('SOMEVAR', True)</code> and <code>d.getVarFlag('SOMEVAR', 'flagname', True)</code> is usually what you want; in the rare cases that you explicitly do not want the value expanded, specify <code>False</code> instead of <code>True</code> (though it is worth pointing out that the default in earlier versions was <code>False</code>).<br />
* '''Handle change of default EXTRA_OEMAKE''': EXTRA_OEMAKE now defaults to "" instead of "-e MAKEFLAGS=". Setting EXTRA_OEMAKE to "-e MAKEFLAGS=" by default was a historical accident that has required many classes (e.g. autotools, module) and recipes to override this default in order to work with sensible build systems. When upgrading to the release, you must edit any recipe that relies upon this old default by either setting EXTRA_OEMAKE back to "-e MAKEFLAGS=" or by explicitly setting any required variable value overrides using EXTRA_OEMAKE, which is typically only needed when a Makefile sets a default value for a variable that is inappropriate for cross-compilation using the "=" operator rather than the "?=" operator.<br />
Changes applicable to the morty release and later:<br />
* '''Handle Python 3''': BitBake now requires Python 3 and as such all python code in recipes and classes now needs to be compatible with Python 3.<br />
Changes applicable to master:<br />
* '''Fix for recipe specific sysroots''': we now use a sysroot per recipe to resolve long-standing issues with config script auto-detection of undeclared dependencies. This means all build-time dependencies for your recipe must be explicitly declared, or they won't be populated into the sysroot for the recipe. Additionally we now sanitise PATH, symlinking only the binaries from the host mentioned in HOSTTOOLS and HOSTTOOLS_NONFATAL into our own directory added to PATH, thus any native binaries that you need to call should either be in HOSTTOOLS (or HOSTTOOLS_NONFATAL) at the configuration level, or alternatively provided by a -native recipe that is included in the recipe's DEPENDS value.<br />
* '''Replace <code>bb.data.getVar()/bb.data.setVar()</code> with <code>d.getVar()/d.setVar()</code>''' - the old functions have now been removed.<br />
<br />
=== Best practices ===<br />
<br />
The following practices are required for patch submission to layers such as OE-Core and meta-oe, and recommended for recipes in your own layers:<br />
<br />
* Machine and distro-specific overrides should be removed from recipes for generic layers (especially meta-oe and OE-Core). These can be moved to bbappends in the appropriate machine / distro layer respectively. (Note however that architecture-specific overrides are allowed if necessary.)<br />
* Fix any QA issues reported during packaging.<br />
* Avoid hardcoding system paths such as /etc, /usr/bin, /usr/share and so on. Instead the values of the appropriate variables should be used (e.g. ${libdir}, ${bindir}, ${datadir} ...). If there are scripts or other files provided by the application such as initscripts you can fix the paths in them within do_install using sed. See bitbake.conf for a list of standard path variables and their default values (which may be - and often are - overridden by the distro configuration).<br />
* Initscripts should have the standard [http://wiki.debian.org/LSBInitScripts LSB header] (especially if no systemd unit file is being provided, since systemd relies upon information in the header when handling an initscript.)<br />
* In-tree patches to be applied to the source should have a proper header explaining what the patch does, a valid Signed-off-by, an [http://lists.yoctoproject.org/pipermail/yocto/2011-April/003446.html Upstream-Status] indicator.<br />
* Reset PR to "r0" by removing it. PR is still used, but new recipes being migrated should start again from r0 (the default value if not specified), and if you need it to increment on recipe changes you should use the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service PR service].<br />
* Use ${BPN} instead of ${PN} where you just want the recipe name without any prefixes/suffixes added by things like multilib and nativesdk (e.g. installation paths)<br />
* Use the <code>useradd</code> class instead of running useradd/groupadd directly to add users/groups.<br />
* NATIVE_INSTALL_WORKS for native recipes is no longer used and should be removed.<br />
* PRIORITY is no longer used and should be removed.<br />
* ENTERPRISE_DISTRO is no longer used. We now have LICENSE_FLAGS to support the uses that ENTERPRISE_DISTRO covered - see the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes Yocto Project Reference Manual].<br />
* Use d.getVar()/d.setVar() instead of bb.data.getVar()/bb.data.setVar() in python functions. The latter will still work, but are deprecated.<br />
* For class overrides (other than multilib) use class-xxx instead of virtclass-xxx. The latter will still work, but is deprecated.<br />
* "[http://mywiki.wooledge.org/Bashism Bashisms]" in shell scripts (particularly those that will be executed on the host) should be avoided. This allows compatibility with alternative shells e.g. Ubuntu's default (dash).<br />
* Pre/postinstall scripts (pkg_preinst / pkg_postinst) should ideally be written such that they can run on the host during do_rootfs instead of only on the target. In practice this means that you need to use ${D} before all paths, and anything that is architecture-specific will need to be run under qemu (although the latter is not very common).<br />
* For readability, the variables/functions within a recipe should be ordered in the same order in which they are used - i.e. "meta" information above (DESCRIPTION, SUMMARY, DEPENDS, LICENSE etc.), followed by information needed for do_fetch (SRC_URI, etc.), then anything for do_patch, do_compile, do_install, and then do_package (e.g. PACKAGES, FILES, RDEPENDS, RRECOMMENDS...).<br />
* Shell functions in OE-Core are using tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell task, python tasks and for indentation of multi-line variables)<br />
<br />
== Machine configuration ==<br />
<br />
The following section lists changes applicable to machine configuration files (conf/machine/*).<br />
<br />
* '''Ensure you are using the correct tune files''': the tune files in OE-Core have been reorganised and updated; see conf/machine/include/ and check that you are including the appropriate file(s).<br />
* '''Remove variable settings already handled by the tune files''': check if any values you are setting are already set by the tune files; if they are, you don't need to set them again. Of course if you wish to override one of the settings for your machine that is fine.<br />
* '''Update to a newer Linux kernel''': current versions of kernel-sensitive userspace components (e.g. udev) expect a modern kernel; older kernels may not allow the system to boot. If you're not able to do this you may need to provide downgraded versions of these components that are compatible with the kernel you are building. Note that all support for the 2.4 kernel has been removed.<br />
* '''Check MACHINE_FEATURES value''': check the list you are setting against the currently available features (see [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine here], or you can do "git grep MACHINE_FEATURES" in the layers containing recipes you are using.) In particular, the "kernel26" feature can be removed as we no longer support the 2.4 kernel which necessitated having a flag to say the machine is using a 2.6 kernel instead.<br />
* '''Remove unused variables''': the following variables are no longer used:<br />
** KERNEL<br />
** PCMCIA_MANAGER<br />
** MACHINE_KERNEL_VERSION<br />
** ROOT_FLASH_SIZE<br />
* '''Use =+ to set IMAGE_FSTYPES''': this interacts best when adding/overriding from other configuration files.<br />
* '''Remove MACHINE_KERNEL_PR''': this is no longer needed when BB_SIGNATURE_HANDLER is OEBasicHash (now the default) and the PR service is being used (in the dylan branch and newer); any changes to underlying metadata or dependencies of the kernel will automatically rebuild the kernel so there is no need to force it by hand.<br />
<br />
== Distro configuration ==<br />
<br />
* '''Build on top of defaultsetup.conf''': OE-Core provides a very basic distro config in meta/conf/distro/defaultsetup.conf which is included automatically by bitbake.conf, thus you only need to include bits of this config file that you want to change.<br />
* '''Replace references to glibc with eglibc''': set TCMODE and TCLIBC to select the toolchain mode and libc variant if you are not using the defaults.<br />
* '''Check DISTRO_FEATURES value''': if you are setting DISTRO_FEATURES, check the list you have against the currently available features (look at the default value in conf/distro/include/default-distrovars.inc in OE-Core; you can also do "git grep DISTRO_FEATURES" in the layers containing recipes you are using.)<br />
* '''Avoid setting machine configuration variables''': machine configuration should almost always be handled in each machine configuration file and not in the distro configuration.<br />
* '''Update blacklisting''': Replace ANGSTROM_BLACKLIST_pn-somerecipe = "message" with BLACKLIST[somerecipe] = "message" (assuming the recipe still exists and the blacklisting is still needed)<br />
* '''Replace references to ONLINE_PACKAGE_MANAGEMENT''': this variable has been replaced by checking for package-management within IMAGE_FEATURES.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=9353Layers FAQ2017-03-14T02:32:27Z<p>PaulEggleton: Add link to OE-Classic section of the layer index</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github] or [http://gitorious.org gitorious].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@linux.intel.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]]. These recipes can also be found in the [http://layers.openembedded.org/layerindex/oe-classic/recipes/ OE-Classic] section in the layer index.<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
=== I'd like to contribute improvements to the layer index code/design, how can I do that? ===<br />
<br />
The code can be found on [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ git.yoctoproject.org]. It uses the Django web framework and split into two parts - the web-based frontend that you interact with, and an update script that runs periodically to gather information about all of the layers in the database. There's further information in the README file on how to contribute.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Migrating_metadata_to_OE-Core&diff=9351Migrating metadata to OE-Core2017-03-03T01:24:21Z<p>PaulEggleton: We no longer check for do_stage so remove reference to that causing an error</p>
<hr />
<div>The classes and BitBake configuration used in [[OpenEmbedded-Core]] require a few changes for recipes brought over from OE-Classic (and for new recipes written by developers used to working with OE-Classic).<br />
<br />
== Recipes ==<br />
<br />
The following section lists changes applicable to recipes (.bb files).<br />
<br />
=== Mandatory changes ===<br />
<br />
For recipes the following changes are required in order to build successfully:<br />
<br />
* '''Add LIC_FILES_CHKSUM''': this specifies one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version. It is mandatory and checked at the end of do_configure. See [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-specifying-LIC_FILES_CHKSUM Specifying LIC_FILES_CHKSUM] for more details.<br />
* '''Remove legacy staging''': legacy staging (do_stage) is no longer supported. Items previously in do_stage should be moved to do_install as appropriate; however they should actually install the files to somewhere under ${D} and ''not'' copy them into the staging directory directly or things will break later on. See [[Legacy staging]] for more information.<br />
* '''Ensure LICENSE is present''': the LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.<br />
* '''Ensure SRC_URI checksums are present''': for entries in SRC_URI pointing to sources other than SCMs or local files, i.e. http, ftp, etc., at least one SRC_URI checksum (md5sum/sha256sum) must be provided. If these are not present for an entry where it is required you will get an error which gives you the appropriate values to be added to the recipe. You can use the "name=" parameter within SRC_URI to distinguish between multiple entries. (This used to be optional, now it is mandatory.)<br />
* '''Remove comments in string values''': recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. is no longer allowed. Remove the commented out lines or move them to beyond where the string terminates.<br />
* '''Ensure values are quoted''': current versions of BitBake require that values are quoted; this was optional in the past. Single or double quotes are allowed but all values must now be quoted. (This does not affect how numeric values are interpreted, these have always been treated as strings.)<br />
* '''Use package name override with packaging variables''': the runtime package specific variables (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY, and the pre/post install/uninstall script functions pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm) should always have a package name override. For example, to set a runtime dependency for the main package use RDEPENDS_${PN}.<br />
* '''Replace oe* logging commands''': Any calls to oenote, oewarn, oefatal etc. in shell scripts need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.<br />
* '''Use FILESEXTRAPATHS to extend file search path''': Modifications to FILESPATHPKG and/or FILESPATH (or FILESDIR which is deprecated) should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
Changes applicable to the "danny" release and later:<br />
* '''Python functions should always use four spaces for indentation''' and not tabs - a warning will be produced if tabs are found. Previously four spaces was the convention but many python functions used tabs. This has been fixed in OE-Core and other layers, and since python uses indentation for statement blocks, is very important that you make the same changes to python functions in your recipes.<br />
* '''Change proto= to protocol= in SRC_URI''' - all fetchers have been changed to be consistent. Previously, some fetchers used proto and some protocol.<br />
* '''Change tasks to package groups''' - for custom task recipes, rename them from task-*.bb to packagegroup-*.bb, inherit packagegroup instead of inheriting task and remove anything that is now handled by meta/classes/packagegroup.bbclass. Also change any references to task-* to packagegroup-*.<br />
* '''Change any assumptions that libexecdir is /usr/libexec''': we now set libexecdir to ${libdir}/${BPN} to match with the Filesystem Hierarchy Standard (FHS).<br />
Changes applicable to the "dylan" release and later:<br />
* '''Fix continuation on last line of a comment''': if a comment ends in a line continuation (\) then the next line must also be a comment; any instance where this is not the case will now trigger a warning. Either remove the continuation character or make the next line a comment as well.<br />
* '''Remove use of BROKEN''' - use EXCLUDE_FROM_WORLD instead; ideally fix up the cause of the recipe being marked as BROKEN.<br />
Changes applicable to the "dora" release and later:<br />
* '''Rename functions/variables that currently contain "_remove_" or end with "_remove"''' - _remove is now a BitBake operator, so referencing it when you aren't intending to remove a value from a list variable will result in unexpected behaviour.<br />
Changes applicable to the "daisy" release and later:<br />
* '''Git SRCREV must match up with the branch''': if you are specifying a SRCREV value then it must now be on the branch specified in the URL entry (with the <tt>branch=</tt> parameter, or the master branch if none is specified). Alternatively if you wish to fetch a revision which isn't on any branch, specify <tt>nobranch=1</tt> in the URL.<br />
Changes applicable to the "dizzy" release and later:<br />
* '''Handle B != S in autotools recipes''': if the software being built is capable of building in a separate directory to the source, you don't need to do anything. Otherwise, either patch it so that it does, or inherit <tt>autotools-brokensep</tt> instead of <tt>autotools</tt>.<br />
* '''Handle the --foreign option in autotools recipes''': some older autotooled software does not follow the GNU standards in distributing certain files such as ChangeLog, AUTHORS, etc. Most upstream software packages that need to already tell automake to enable foreign mode themselves, but some recipes will need patches for this change. You can easily make the change by patching configure.ac so that it passes "foreign" to AM_INIT_AUTOMAKE() - see [http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2 this example].<br />
* '''Use pkg-config instead of standalone configuration scripts''': configuration scripts such as xml2-config, pcre-config, freetype-config etc. were being mangled in the past in order to have them return the correct paths within the sysroot, but this is no longer being done - instead of running these scripts, use pkg-config which has proper sysroot support. These scripts will now return an exit code and an invalid option for those calling scripts that don't pay attention to the exit code.<br />
* '''Do not stage the same files in multiple recipes''': overwriting files in the sysroot now triggers an error instead of a warning. Recipes should not be staging files to the sysroot (as a result of installing files within do_install) that are also staged by other recipes; allowing this in the past led to nasty situations that were often difficult to debug.<br />
Changes applicable to the "fido" release and later:<br />
* '''Set CLEANBROKEN if make clean doesn't work''': if a Makefile exists, do_configure runs <tt>make clean</tt> when re-executing in order to clean out generated files. If this isn't expected to work for the software a recipe builds, set CLEANBROKEN = "1" in the recipe.<br />
* '''Ensure dependencies on kernel headers are accounted for''': recipes that rely on the kernel source code/headers that do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example: <code>do_configure[depends] += "virtual/kernel:do_shared_workdir"</code><br />
Changes applicable to the "krogoth" release and later:<br />
* '''Explicitly expand variable references in python functions''': BitBake no longer expands variable references (e.g. <code>${VARNAME}</code>) in python functions - you should now explicitly expand these using <code>d.expand()</code> or simply by calling <code>d.getVar()</code> if you just want to get the value of a single variable.<br />
* '''Ensure recipe names are all lower-case''' - BitBake now requires overrides to be all lower case, which in practice means that anything that can be an override (distro names, machine names and recipe names) must also be lower case if the corresponding overrides are to function.<br />
* '''Ensure calls to d.getVar() and d.getVarFlag() specify the expansion parameter''' - <code>d.getVar('SOMEVAR')</code> and <code>d.getVarFlag('SOMEVAR', 'flagname')</code> are no longer allowed - the expansion parameter is now required. <code>d.getVar('SOMEVAR', True)</code> and <code>d.getVarFlag('SOMEVAR', 'flagname', True)</code> is usually what you want; in the rare cases that you explicitly do not want the value expanded, specify <code>False</code> instead of <code>True</code> (though it is worth pointing out that the default in earlier versions was <code>False</code>).<br />
* '''Handle change of default EXTRA_OEMAKE''': EXTRA_OEMAKE now defaults to "" instead of "-e MAKEFLAGS=". Setting EXTRA_OEMAKE to "-e MAKEFLAGS=" by default was a historical accident that has required many classes (e.g. autotools, module) and recipes to override this default in order to work with sensible build systems. When upgrading to the release, you must edit any recipe that relies upon this old default by either setting EXTRA_OEMAKE back to "-e MAKEFLAGS=" or by explicitly setting any required variable value overrides using EXTRA_OEMAKE, which is typically only needed when a Makefile sets a default value for a variable that is inappropriate for cross-compilation using the "=" operator rather than the "?=" operator.<br />
Changes applicable to the morty release and later:<br />
* '''Handle Python 3''': BitBake now requires Python 3 and as such all python code in recipes and classes now needs to be compatible with Python 3.<br />
Changes applicable to master:<br />
* '''Fix for recipe specific sysroots''': we now use a sysroot per recipe to resolve long-standing issues with config script auto-detection of undeclared dependencies. This means all build-time dependencies for your recipe must be explicitly declared, or they won't be populated into the sysroot for the recipe.<br />
* '''Replace <code>bb.data.getVar()/bb.data.setVar()</code> with <code>d.getVar()/d.setVar()</code>''' - the old functions have now been removed.<br />
<br />
=== Best practices ===<br />
<br />
The following practices are required for patch submission to layers such as OE-Core and meta-oe, and recommended for recipes in your own layers:<br />
<br />
* Machine and distro-specific overrides should be removed from recipes for generic layers (especially meta-oe and OE-Core). These can be moved to bbappends in the appropriate machine / distro layer respectively. (Note however that architecture-specific overrides are allowed if necessary.)<br />
* Fix any QA issues reported during packaging.<br />
* Avoid hardcoding system paths such as /etc, /usr/bin, /usr/share and so on. Instead the values of the appropriate variables should be used (e.g. ${libdir}, ${bindir}, ${datadir} ...). If there are scripts or other files provided by the application such as initscripts you can fix the paths in them within do_install using sed. See bitbake.conf for a list of standard path variables and their default values (which may be - and often are - overridden by the distro configuration).<br />
* Initscripts should have the standard [http://wiki.debian.org/LSBInitScripts LSB header] (especially if no systemd unit file is being provided, since systemd relies upon information in the header when handling an initscript.)<br />
* In-tree patches to be applied to the source should have a proper header explaining what the patch does, a valid Signed-off-by, an [http://lists.yoctoproject.org/pipermail/yocto/2011-April/003446.html Upstream-Status] indicator.<br />
* Reset PR to "r0" by removing it. PR is still used, but new recipes being migrated should start again from r0 (the default value if not specified), and if you need it to increment on recipe changes you should use the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service PR service].<br />
* Use ${BPN} instead of ${PN} where you just want the recipe name without any prefixes/suffixes added by things like multilib and nativesdk (e.g. installation paths)<br />
* Use the <code>useradd</code> class instead of running useradd/groupadd directly to add users/groups.<br />
* NATIVE_INSTALL_WORKS for native recipes is no longer used and should be removed.<br />
* PRIORITY is no longer used and should be removed.<br />
* ENTERPRISE_DISTRO is no longer used. We now have LICENSE_FLAGS to support the uses that ENTERPRISE_DISTRO covered - see the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes Yocto Project Reference Manual].<br />
* Use d.getVar()/d.setVar() instead of bb.data.getVar()/bb.data.setVar() in python functions. The latter will still work, but are deprecated.<br />
* For class overrides (other than multilib) use class-xxx instead of virtclass-xxx. The latter will still work, but is deprecated.<br />
* "[http://mywiki.wooledge.org/Bashism Bashisms]" in shell scripts (particularly those that will be executed on the host) should be avoided. This allows compatibility with alternative shells e.g. Ubuntu's default (dash).<br />
* Pre/postinstall scripts (pkg_preinst / pkg_postinst) should ideally be written such that they can run on the host during do_rootfs instead of only on the target. In practice this means that you need to use ${D} before all paths, and anything that is architecture-specific will need to be run under qemu (although the latter is not very common).<br />
* For readability, the variables/functions within a recipe should be ordered in the same order in which they are used - i.e. "meta" information above (DESCRIPTION, SUMMARY, DEPENDS, LICENSE etc.), followed by information needed for do_fetch (SRC_URI, etc.), then anything for do_patch, do_compile, do_install, and then do_package (e.g. PACKAGES, FILES, RDEPENDS, RRECOMMENDS...).<br />
* Shell functions in OE-Core are using tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell task, python tasks and for indentation of multi-line variables)<br />
<br />
== Machine configuration ==<br />
<br />
The following section lists changes applicable to machine configuration files (conf/machine/*).<br />
<br />
* '''Ensure you are using the correct tune files''': the tune files in OE-Core have been reorganised and updated; see conf/machine/include/ and check that you are including the appropriate file(s).<br />
* '''Remove variable settings already handled by the tune files''': check if any values you are setting are already set by the tune files; if they are, you don't need to set them again. Of course if you wish to override one of the settings for your machine that is fine.<br />
* '''Update to a newer Linux kernel''': current versions of kernel-sensitive userspace components (e.g. udev) expect a modern kernel; older kernels may not allow the system to boot. If you're not able to do this you may need to provide downgraded versions of these components that are compatible with the kernel you are building. Note that all support for the 2.4 kernel has been removed.<br />
* '''Check MACHINE_FEATURES value''': check the list you are setting against the currently available features (see [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine here], or you can do "git grep MACHINE_FEATURES" in the layers containing recipes you are using.) In particular, the "kernel26" feature can be removed as we no longer support the 2.4 kernel which necessitated having a flag to say the machine is using a 2.6 kernel instead.<br />
* '''Remove unused variables''': the following variables are no longer used:<br />
** KERNEL<br />
** PCMCIA_MANAGER<br />
** MACHINE_KERNEL_VERSION<br />
** ROOT_FLASH_SIZE<br />
* '''Use =+ to set IMAGE_FSTYPES''': this interacts best when adding/overriding from other configuration files.<br />
* '''Remove MACHINE_KERNEL_PR''': this is no longer needed when BB_SIGNATURE_HANDLER is OEBasicHash (now the default) and the PR service is being used (in the dylan branch and newer); any changes to underlying metadata or dependencies of the kernel will automatically rebuild the kernel so there is no need to force it by hand.<br />
<br />
== Distro configuration ==<br />
<br />
* '''Build on top of defaultsetup.conf''': OE-Core provides a very basic distro config in meta/conf/distro/defaultsetup.conf which is included automatically by bitbake.conf, thus you only need to include bits of this config file that you want to change.<br />
* '''Replace references to glibc with eglibc''': set TCMODE and TCLIBC to select the toolchain mode and libc variant if you are not using the defaults.<br />
* '''Check DISTRO_FEATURES value''': if you are setting DISTRO_FEATURES, check the list you have against the currently available features (look at the default value in conf/distro/include/default-distrovars.inc in OE-Core; you can also do "git grep DISTRO_FEATURES" in the layers containing recipes you are using.)<br />
* '''Avoid setting machine configuration variables''': machine configuration should almost always be handled in each machine configuration file and not in the distro configuration.<br />
* '''Update blacklisting''': Replace ANGSTROM_BLACKLIST_pn-somerecipe = "message" with BLACKLIST[somerecipe] = "message" (assuming the recipe still exists and the blacklisting is still needed)<br />
* '''Replace references to ONLINE_PACKAGE_MANAGEMENT''': this variable has been replaced by checking for package-management within IMAGE_FEATURES.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Migrating_metadata_to_OE-Core&diff=9349Migrating metadata to OE-Core2017-03-03T01:22:48Z<p>PaulEggleton: Add some master changes</p>
<hr />
<div>The classes and BitBake configuration used in [[OpenEmbedded-Core]] require a few changes for recipes brought over from OE-Classic (and for new recipes written by developers used to working with OE-Classic).<br />
<br />
== Recipes ==<br />
<br />
The following section lists changes applicable to recipes (.bb files).<br />
<br />
=== Mandatory changes ===<br />
<br />
For recipes the following changes are required in order to build successfully:<br />
<br />
* '''Add LIC_FILES_CHKSUM''': this specifies one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version. It is mandatory and checked at the end of do_configure. See [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-specifying-LIC_FILES_CHKSUM Specifying LIC_FILES_CHKSUM] for more details.<br />
* '''Remove legacy staging''': legacy staging (do_stage) is no longer supported and BitBake will error out on parse of recipes that use it. Items previously in do_stage should be moved to do_install as appropriate; however they should actually install the files to somewhere under ${D} and ''not'' copy them into the staging directory directly or things will break later on. See [[Legacy staging]] for more information.<br />
* '''Ensure LICENSE is present''': the LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.<br />
* '''Ensure SRC_URI checksums are present''': for entries in SRC_URI pointing to sources other than SCMs or local files, i.e. http, ftp, etc., at least one SRC_URI checksum (md5sum/sha256sum) must be provided. If these are not present for an entry where it is required you will get an error which gives you the appropriate values to be added to the recipe. You can use the "name=" parameter within SRC_URI to distinguish between multiple entries. (This used to be optional, now it is mandatory.)<br />
* '''Remove comments in string values''': recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. is no longer allowed. Remove the commented out lines or move them to beyond where the string terminates.<br />
* '''Ensure values are quoted''': current versions of BitBake require that values are quoted; this was optional in the past. Single or double quotes are allowed but all values must now be quoted. (This does not affect how numeric values are interpreted, these have always been treated as strings.)<br />
* '''Use package name override with packaging variables''': the runtime package specific variables (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY, and the pre/post install/uninstall script functions pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm) should always have a package name override. For example, to set a runtime dependency for the main package use RDEPENDS_${PN}.<br />
* '''Replace oe* logging commands''': Any calls to oenote, oewarn, oefatal etc. in shell scripts need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.<br />
* '''Use FILESEXTRAPATHS to extend file search path''': Modifications to FILESPATHPKG and/or FILESPATH (or FILESDIR which is deprecated) should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
Changes applicable to the "danny" release and later:<br />
* '''Python functions should always use four spaces for indentation''' and not tabs - a warning will be produced if tabs are found. Previously four spaces was the convention but many python functions used tabs. This has been fixed in OE-Core and other layers, and since python uses indentation for statement blocks, is very important that you make the same changes to python functions in your recipes.<br />
* '''Change proto= to protocol= in SRC_URI''' - all fetchers have been changed to be consistent. Previously, some fetchers used proto and some protocol.<br />
* '''Change tasks to package groups''' - for custom task recipes, rename them from task-*.bb to packagegroup-*.bb, inherit packagegroup instead of inheriting task and remove anything that is now handled by meta/classes/packagegroup.bbclass. Also change any references to task-* to packagegroup-*.<br />
* '''Change any assumptions that libexecdir is /usr/libexec''': we now set libexecdir to ${libdir}/${BPN} to match with the Filesystem Hierarchy Standard (FHS).<br />
Changes applicable to the "dylan" release and later:<br />
* '''Fix continuation on last line of a comment''': if a comment ends in a line continuation (\) then the next line must also be a comment; any instance where this is not the case will now trigger a warning. Either remove the continuation character or make the next line a comment as well.<br />
* '''Remove use of BROKEN''' - use EXCLUDE_FROM_WORLD instead; ideally fix up the cause of the recipe being marked as BROKEN.<br />
Changes applicable to the "dora" release and later:<br />
* '''Rename functions/variables that currently contain "_remove_" or end with "_remove"''' - _remove is now a BitBake operator, so referencing it when you aren't intending to remove a value from a list variable will result in unexpected behaviour.<br />
Changes applicable to the "daisy" release and later:<br />
* '''Git SRCREV must match up with the branch''': if you are specifying a SRCREV value then it must now be on the branch specified in the URL entry (with the <tt>branch=</tt> parameter, or the master branch if none is specified). Alternatively if you wish to fetch a revision which isn't on any branch, specify <tt>nobranch=1</tt> in the URL.<br />
Changes applicable to the "dizzy" release and later:<br />
* '''Handle B != S in autotools recipes''': if the software being built is capable of building in a separate directory to the source, you don't need to do anything. Otherwise, either patch it so that it does, or inherit <tt>autotools-brokensep</tt> instead of <tt>autotools</tt>.<br />
* '''Handle the --foreign option in autotools recipes''': some older autotooled software does not follow the GNU standards in distributing certain files such as ChangeLog, AUTHORS, etc. Most upstream software packages that need to already tell automake to enable foreign mode themselves, but some recipes will need patches for this change. You can easily make the change by patching configure.ac so that it passes "foreign" to AM_INIT_AUTOMAKE() - see [http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2 this example].<br />
* '''Use pkg-config instead of standalone configuration scripts''': configuration scripts such as xml2-config, pcre-config, freetype-config etc. were being mangled in the past in order to have them return the correct paths within the sysroot, but this is no longer being done - instead of running these scripts, use pkg-config which has proper sysroot support. These scripts will now return an exit code and an invalid option for those calling scripts that don't pay attention to the exit code.<br />
* '''Do not stage the same files in multiple recipes''': overwriting files in the sysroot now triggers an error instead of a warning. Recipes should not be staging files to the sysroot (as a result of installing files within do_install) that are also staged by other recipes; allowing this in the past led to nasty situations that were often difficult to debug.<br />
Changes applicable to the "fido" release and later:<br />
* '''Set CLEANBROKEN if make clean doesn't work''': if a Makefile exists, do_configure runs <tt>make clean</tt> when re-executing in order to clean out generated files. If this isn't expected to work for the software a recipe builds, set CLEANBROKEN = "1" in the recipe.<br />
* '''Ensure dependencies on kernel headers are accounted for''': recipes that rely on the kernel source code/headers that do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example: <code>do_configure[depends] += "virtual/kernel:do_shared_workdir"</code><br />
Changes applicable to the "krogoth" release and later:<br />
* '''Explicitly expand variable references in python functions''': BitBake no longer expands variable references (e.g. <code>${VARNAME}</code>) in python functions - you should now explicitly expand these using <code>d.expand()</code> or simply by calling <code>d.getVar()</code> if you just want to get the value of a single variable.<br />
* '''Ensure recipe names are all lower-case''' - BitBake now requires overrides to be all lower case, which in practice means that anything that can be an override (distro names, machine names and recipe names) must also be lower case if the corresponding overrides are to function.<br />
* '''Ensure calls to d.getVar() and d.getVarFlag() specify the expansion parameter''' - <code>d.getVar('SOMEVAR')</code> and <code>d.getVarFlag('SOMEVAR', 'flagname')</code> are no longer allowed - the expansion parameter is now required. <code>d.getVar('SOMEVAR', True)</code> and <code>d.getVarFlag('SOMEVAR', 'flagname', True)</code> is usually what you want; in the rare cases that you explicitly do not want the value expanded, specify <code>False</code> instead of <code>True</code> (though it is worth pointing out that the default in earlier versions was <code>False</code>).<br />
* '''Handle change of default EXTRA_OEMAKE''': EXTRA_OEMAKE now defaults to "" instead of "-e MAKEFLAGS=". Setting EXTRA_OEMAKE to "-e MAKEFLAGS=" by default was a historical accident that has required many classes (e.g. autotools, module) and recipes to override this default in order to work with sensible build systems. When upgrading to the release, you must edit any recipe that relies upon this old default by either setting EXTRA_OEMAKE back to "-e MAKEFLAGS=" or by explicitly setting any required variable value overrides using EXTRA_OEMAKE, which is typically only needed when a Makefile sets a default value for a variable that is inappropriate for cross-compilation using the "=" operator rather than the "?=" operator.<br />
Changes applicable to the morty release and later:<br />
* '''Handle Python 3''': BitBake now requires Python 3 and as such all python code in recipes and classes now needs to be compatible with Python 3.<br />
Changes applicable to master:<br />
* '''Fix for recipe specific sysroots''': we now use a sysroot per recipe to resolve long-standing issues with config script auto-detection of undeclared dependencies. This means all build-time dependencies for your recipe must be explicitly declared, or they won't be populated into the sysroot for the recipe.<br />
* '''Replace <code>bb.data.getVar()/bb.data.setVar()</code> with <code>d.getVar()/d.setVar()</code>''' - the old functions have now been removed.<br />
<br />
=== Best practices ===<br />
<br />
The following practices are required for patch submission to layers such as OE-Core and meta-oe, and recommended for recipes in your own layers:<br />
<br />
* Machine and distro-specific overrides should be removed from recipes for generic layers (especially meta-oe and OE-Core). These can be moved to bbappends in the appropriate machine / distro layer respectively. (Note however that architecture-specific overrides are allowed if necessary.)<br />
* Fix any QA issues reported during packaging.<br />
* Avoid hardcoding system paths such as /etc, /usr/bin, /usr/share and so on. Instead the values of the appropriate variables should be used (e.g. ${libdir}, ${bindir}, ${datadir} ...). If there are scripts or other files provided by the application such as initscripts you can fix the paths in them within do_install using sed. See bitbake.conf for a list of standard path variables and their default values (which may be - and often are - overridden by the distro configuration).<br />
* Initscripts should have the standard [http://wiki.debian.org/LSBInitScripts LSB header] (especially if no systemd unit file is being provided, since systemd relies upon information in the header when handling an initscript.)<br />
* In-tree patches to be applied to the source should have a proper header explaining what the patch does, a valid Signed-off-by, an [http://lists.yoctoproject.org/pipermail/yocto/2011-April/003446.html Upstream-Status] indicator.<br />
* Reset PR to "r0" by removing it. PR is still used, but new recipes being migrated should start again from r0 (the default value if not specified), and if you need it to increment on recipe changes you should use the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service PR service].<br />
* Use ${BPN} instead of ${PN} where you just want the recipe name without any prefixes/suffixes added by things like multilib and nativesdk (e.g. installation paths)<br />
* Use the <code>useradd</code> class instead of running useradd/groupadd directly to add users/groups.<br />
* NATIVE_INSTALL_WORKS for native recipes is no longer used and should be removed.<br />
* PRIORITY is no longer used and should be removed.<br />
* ENTERPRISE_DISTRO is no longer used. We now have LICENSE_FLAGS to support the uses that ENTERPRISE_DISTRO covered - see the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes Yocto Project Reference Manual].<br />
* Use d.getVar()/d.setVar() instead of bb.data.getVar()/bb.data.setVar() in python functions. The latter will still work, but are deprecated.<br />
* For class overrides (other than multilib) use class-xxx instead of virtclass-xxx. The latter will still work, but is deprecated.<br />
* "[http://mywiki.wooledge.org/Bashism Bashisms]" in shell scripts (particularly those that will be executed on the host) should be avoided. This allows compatibility with alternative shells e.g. Ubuntu's default (dash).<br />
* Pre/postinstall scripts (pkg_preinst / pkg_postinst) should ideally be written such that they can run on the host during do_rootfs instead of only on the target. In practice this means that you need to use ${D} before all paths, and anything that is architecture-specific will need to be run under qemu (although the latter is not very common).<br />
* For readability, the variables/functions within a recipe should be ordered in the same order in which they are used - i.e. "meta" information above (DESCRIPTION, SUMMARY, DEPENDS, LICENSE etc.), followed by information needed for do_fetch (SRC_URI, etc.), then anything for do_patch, do_compile, do_install, and then do_package (e.g. PACKAGES, FILES, RDEPENDS, RRECOMMENDS...).<br />
* Shell functions in OE-Core are using tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell task, python tasks and for indentation of multi-line variables)<br />
<br />
== Machine configuration ==<br />
<br />
The following section lists changes applicable to machine configuration files (conf/machine/*).<br />
<br />
* '''Ensure you are using the correct tune files''': the tune files in OE-Core have been reorganised and updated; see conf/machine/include/ and check that you are including the appropriate file(s).<br />
* '''Remove variable settings already handled by the tune files''': check if any values you are setting are already set by the tune files; if they are, you don't need to set them again. Of course if you wish to override one of the settings for your machine that is fine.<br />
* '''Update to a newer Linux kernel''': current versions of kernel-sensitive userspace components (e.g. udev) expect a modern kernel; older kernels may not allow the system to boot. If you're not able to do this you may need to provide downgraded versions of these components that are compatible with the kernel you are building. Note that all support for the 2.4 kernel has been removed.<br />
* '''Check MACHINE_FEATURES value''': check the list you are setting against the currently available features (see [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine here], or you can do "git grep MACHINE_FEATURES" in the layers containing recipes you are using.) In particular, the "kernel26" feature can be removed as we no longer support the 2.4 kernel which necessitated having a flag to say the machine is using a 2.6 kernel instead.<br />
* '''Remove unused variables''': the following variables are no longer used:<br />
** KERNEL<br />
** PCMCIA_MANAGER<br />
** MACHINE_KERNEL_VERSION<br />
** ROOT_FLASH_SIZE<br />
* '''Use =+ to set IMAGE_FSTYPES''': this interacts best when adding/overriding from other configuration files.<br />
* '''Remove MACHINE_KERNEL_PR''': this is no longer needed when BB_SIGNATURE_HANDLER is OEBasicHash (now the default) and the PR service is being used (in the dylan branch and newer); any changes to underlying metadata or dependencies of the kernel will automatically rebuild the kernel so there is no need to force it by hand.<br />
<br />
== Distro configuration ==<br />
<br />
* '''Build on top of defaultsetup.conf''': OE-Core provides a very basic distro config in meta/conf/distro/defaultsetup.conf which is included automatically by bitbake.conf, thus you only need to include bits of this config file that you want to change.<br />
* '''Replace references to glibc with eglibc''': set TCMODE and TCLIBC to select the toolchain mode and libc variant if you are not using the defaults.<br />
* '''Check DISTRO_FEATURES value''': if you are setting DISTRO_FEATURES, check the list you have against the currently available features (look at the default value in conf/distro/include/default-distrovars.inc in OE-Core; you can also do "git grep DISTRO_FEATURES" in the layers containing recipes you are using.)<br />
* '''Avoid setting machine configuration variables''': machine configuration should almost always be handled in each machine configuration file and not in the distro configuration.<br />
* '''Update blacklisting''': Replace ANGSTROM_BLACKLIST_pn-somerecipe = "message" with BLACKLIST[somerecipe] = "message" (assuming the recipe still exists and the blacklisting is still needed)<br />
* '''Replace references to ONLINE_PACKAGE_MANAGEMENT''': this variable has been replaced by checking for package-management within IMAGE_FEATURES.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Migrating_metadata_to_OE-Core&diff=9213Migrating metadata to OE-Core2017-01-15T19:54:31Z<p>PaulEggleton: </p>
<hr />
<div>The classes and BitBake configuration used in [[OpenEmbedded-Core]] require a few changes for recipes brought over from OE-Classic (and for new recipes written by developers used to working with OE-Classic).<br />
<br />
== Recipes ==<br />
<br />
The following section lists changes applicable to recipes (.bb files).<br />
<br />
=== Mandatory changes ===<br />
<br />
For recipes the following changes are required in order to build successfully:<br />
<br />
* '''Add LIC_FILES_CHKSUM''': this specifies one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version. It is mandatory and checked at the end of do_configure. See [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-specifying-LIC_FILES_CHKSUM Specifying LIC_FILES_CHKSUM] for more details.<br />
* '''Remove legacy staging''': legacy staging (do_stage) is no longer supported and BitBake will error out on parse of recipes that use it. Items previously in do_stage should be moved to do_install as appropriate; however they should actually install the files to somewhere under ${D} and ''not'' copy them into the staging directory directly or things will break later on. See [[Legacy staging]] for more information.<br />
* '''Ensure LICENSE is present''': the LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.<br />
* '''Ensure SRC_URI checksums are present''': for entries in SRC_URI pointing to sources other than SCMs or local files, i.e. http, ftp, etc., at least one SRC_URI checksum (md5sum/sha256sum) must be provided. If these are not present for an entry where it is required you will get an error which gives you the appropriate values to be added to the recipe. You can use the "name=" parameter within SRC_URI to distinguish between multiple entries. (This used to be optional, now it is mandatory.)<br />
* '''Remove comments in string values''': recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. is no longer allowed. Remove the commented out lines or move them to beyond where the string terminates.<br />
* '''Ensure values are quoted''': current versions of BitBake require that values are quoted; this was optional in the past. Single or double quotes are allowed but all values must now be quoted. (This does not affect how numeric values are interpreted, these have always been treated as strings.)<br />
* '''Use package name override with packaging variables''': the runtime package specific variables (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY, and the pre/post install/uninstall script functions pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm) should always have a package name override. For example, to set a runtime dependency for the main package use RDEPENDS_${PN}.<br />
* '''Replace oe* logging commands''': Any calls to oenote, oewarn, oefatal etc. in shell scripts need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.<br />
* '''Use FILESEXTRAPATHS to extend file search path''': Modifications to FILESPATHPKG and/or FILESPATH (or FILESDIR which is deprecated) should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
Changes applicable to the "danny" release and later:<br />
* '''Python functions should always use four spaces for indentation''' and not tabs - a warning will be produced if tabs are found. Previously four spaces was the convention but many python functions used tabs. This has been fixed in OE-Core and other layers, and since python uses indentation for statement blocks, is very important that you make the same changes to python functions in your recipes.<br />
* '''Change proto= to protocol= in SRC_URI''' - all fetchers have been changed to be consistent. Previously, some fetchers used proto and some protocol.<br />
* '''Change tasks to package groups''' - for custom task recipes, rename them from task-*.bb to packagegroup-*.bb, inherit packagegroup instead of inheriting task and remove anything that is now handled by meta/classes/packagegroup.bbclass. Also change any references to task-* to packagegroup-*.<br />
* '''Change any assumptions that libexecdir is /usr/libexec''': we now set libexecdir to ${libdir}/${BPN} to match with the Filesystem Hierarchy Standard (FHS).<br />
Changes applicable to the "dylan" release and later:<br />
* '''Fix continuation on last line of a comment''': if a comment ends in a line continuation (\) then the next line must also be a comment; any instance where this is not the case will now trigger a warning. Either remove the continuation character or make the next line a comment as well.<br />
* '''Remove use of BROKEN''' - use EXCLUDE_FROM_WORLD instead; ideally fix up the cause of the recipe being marked as BROKEN.<br />
Changes applicable to the "dora" release and later:<br />
* '''Rename functions/variables that currently contain "_remove_" or end with "_remove"''' - _remove is now a BitBake operator, so referencing it when you aren't intending to remove a value from a list variable will result in unexpected behaviour.<br />
Changes applicable to the "daisy" release and later:<br />
* '''Git SRCREV must match up with the branch''': if you are specifying a SRCREV value then it must now be on the branch specified in the URL entry (with the <tt>branch=</tt> parameter, or the master branch if none is specified). Alternatively if you wish to fetch a revision which isn't on any branch, specify <tt>nobranch=1</tt> in the URL.<br />
Changes applicable to the "dizzy" release and later:<br />
* '''Handle B != S in autotools recipes''': if the software being built is capable of building in a separate directory to the source, you don't need to do anything. Otherwise, either patch it so that it does, or inherit <tt>autotools-brokensep</tt> instead of <tt>autotools</tt>.<br />
* '''Handle the --foreign option in autotools recipes''': some older autotooled software does not follow the GNU standards in distributing certain files such as ChangeLog, AUTHORS, etc. Most upstream software packages that need to already tell automake to enable foreign mode themselves, but some recipes will need patches for this change. You can easily make the change by patching configure.ac so that it passes "foreign" to AM_INIT_AUTOMAKE() - see [http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2 this example].<br />
* '''Use pkg-config instead of standalone configuration scripts''': configuration scripts such as xml2-config, pcre-config, freetype-config etc. were being mangled in the past in order to have them return the correct paths within the sysroot, but this is no longer being done - instead of running these scripts, use pkg-config which has proper sysroot support. These scripts will now return an exit code and an invalid option for those calling scripts that don't pay attention to the exit code.<br />
* '''Do not stage the same files in multiple recipes''': overwriting files in the sysroot now triggers an error instead of a warning. Recipes should not be staging files to the sysroot (as a result of installing files within do_install) that are also staged by other recipes; allowing this in the past led to nasty situations that were often difficult to debug.<br />
Changes applicable to the "fido" release and later:<br />
* '''Set CLEANBROKEN if make clean doesn't work''': if a Makefile exists, do_configure runs <tt>make clean</tt> when re-executing in order to clean out generated files. If this isn't expected to work for the software a recipe builds, set CLEANBROKEN = "1" in the recipe.<br />
* '''Ensure dependencies on kernel headers are accounted for''': recipes that rely on the kernel source code/headers that do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example: <code>do_configure[depends] += "virtual/kernel:do_shared_workdir"</code><br />
Changes applicable to the "krogoth" release and later:<br />
* '''Explicitly expand variable references in python functions''': BitBake no longer expands variable references (e.g. <code>${VARNAME}</code>) in python functions - you should now explicitly expand these using <code>d.expand()</code> or simply by calling <code>d.getVar()</code> if you just want to get the value of a single variable.<br />
* '''Ensure recipe names are all lower-case''' - BitBake now requires overrides to be all lower case, which in practice means that anything that can be an override (distro names, machine names and recipe names) must also be lower case if the corresponding overrides are to function.<br />
* '''Ensure calls to d.getVar() and d.getVarFlag() specify the expansion parameter''' - <code>d.getVar('SOMEVAR')</code> and <code>d.getVarFlag('SOMEVAR', 'flagname')</code> are no longer allowed - the expansion parameter is now required. <code>d.getVar('SOMEVAR', True)</code> and <code>d.getVarFlag('SOMEVAR', 'flagname', True)</code> is usually what you want; in the rare cases that you explicitly do not want the value expanded, specify <code>False</code> instead of <code>True</code> (though it is worth pointing out that the default in earlier versions was <code>False</code>).<br />
* '''Handle change of default EXTRA_OEMAKE''': EXTRA_OEMAKE now defaults to "" instead of "-e MAKEFLAGS=". Setting EXTRA_OEMAKE to "-e MAKEFLAGS=" by default was a historical accident that has required many classes (e.g. autotools, module) and recipes to override this default in order to work with sensible build systems. When upgrading to the release, you must edit any recipe that relies upon this old default by either setting EXTRA_OEMAKE back to "-e MAKEFLAGS=" or by explicitly setting any required variable value overrides using EXTRA_OEMAKE, which is typically only needed when a Makefile sets a default value for a variable that is inappropriate for cross-compilation using the "=" operator rather than the "?=" operator.<br />
Changes applicable to the morty release and later:<br />
* '''Handle Python 3''': BitBake now requires Python 3 and as such all python code in recipes and classes now needs to be compatible with Python 3.<br />
<br />
=== Best practices ===<br />
<br />
The following practices are required for patch submission to layers such as OE-Core and meta-oe, and recommended for recipes in your own layers:<br />
<br />
* Machine and distro-specific overrides should be removed from recipes for generic layers (especially meta-oe and OE-Core). These can be moved to bbappends in the appropriate machine / distro layer respectively. (Note however that architecture-specific overrides are allowed if necessary.)<br />
* Fix any QA issues reported during packaging.<br />
* Avoid hardcoding system paths such as /etc, /usr/bin, /usr/share and so on. Instead the values of the appropriate variables should be used (e.g. ${libdir}, ${bindir}, ${datadir} ...). If there are scripts or other files provided by the application such as initscripts you can fix the paths in them within do_install using sed. See bitbake.conf for a list of standard path variables and their default values (which may be - and often are - overridden by the distro configuration).<br />
* Initscripts should have the standard [http://wiki.debian.org/LSBInitScripts LSB header] (especially if no systemd unit file is being provided, since systemd relies upon information in the header when handling an initscript.)<br />
* In-tree patches to be applied to the source should have a proper header explaining what the patch does, a valid Signed-off-by, an [http://lists.yoctoproject.org/pipermail/yocto/2011-April/003446.html Upstream-Status] indicator.<br />
* Reset PR to "r0" by removing it. PR is still used, but new recipes being migrated should start again from r0 (the default value if not specified), and if you need it to increment on recipe changes you should use the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service PR service].<br />
* Use ${BPN} instead of ${PN} where you just want the recipe name without any prefixes/suffixes added by things like multilib and nativesdk (e.g. installation paths)<br />
* Use the <code>useradd</code> class instead of running useradd/groupadd directly to add users/groups.<br />
* NATIVE_INSTALL_WORKS for native recipes is no longer used and should be removed.<br />
* PRIORITY is no longer used and should be removed.<br />
* ENTERPRISE_DISTRO is no longer used. We now have LICENSE_FLAGS to support the uses that ENTERPRISE_DISTRO covered - see the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes Yocto Project Reference Manual].<br />
* Use d.getVar()/d.setVar() instead of bb.data.getVar()/bb.data.setVar() in python functions. The latter will still work, but are deprecated.<br />
* For class overrides (other than multilib) use class-xxx instead of virtclass-xxx. The latter will still work, but is deprecated.<br />
* "[http://mywiki.wooledge.org/Bashism Bashisms]" in shell scripts (particularly those that will be executed on the host) should be avoided. This allows compatibility with alternative shells e.g. Ubuntu's default (dash).<br />
* Pre/postinstall scripts (pkg_preinst / pkg_postinst) should ideally be written such that they can run on the host during do_rootfs instead of only on the target. In practice this means that you need to use ${D} before all paths, and anything that is architecture-specific will need to be run under qemu (although the latter is not very common).<br />
* For readability, the variables/functions within a recipe should be ordered in the same order in which they are used - i.e. "meta" information above (DESCRIPTION, SUMMARY, DEPENDS, LICENSE etc.), followed by information needed for do_fetch (SRC_URI, etc.), then anything for do_patch, do_compile, do_install, and then do_package (e.g. PACKAGES, FILES, RDEPENDS, RRECOMMENDS...).<br />
* Shell functions in OE-Core are using tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell task, python tasks and for indentation of multi-line variables)<br />
<br />
== Machine configuration ==<br />
<br />
The following section lists changes applicable to machine configuration files (conf/machine/*).<br />
<br />
* '''Ensure you are using the correct tune files''': the tune files in OE-Core have been reorganised and updated; see conf/machine/include/ and check that you are including the appropriate file(s).<br />
* '''Remove variable settings already handled by the tune files''': check if any values you are setting are already set by the tune files; if they are, you don't need to set them again. Of course if you wish to override one of the settings for your machine that is fine.<br />
* '''Update to a newer Linux kernel''': current versions of kernel-sensitive userspace components (e.g. udev) expect a modern kernel; older kernels may not allow the system to boot. If you're not able to do this you may need to provide downgraded versions of these components that are compatible with the kernel you are building. Note that all support for the 2.4 kernel has been removed.<br />
* '''Check MACHINE_FEATURES value''': check the list you are setting against the currently available features (see [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine here], or you can do "git grep MACHINE_FEATURES" in the layers containing recipes you are using.) In particular, the "kernel26" feature can be removed as we no longer support the 2.4 kernel which necessitated having a flag to say the machine is using a 2.6 kernel instead.<br />
* '''Remove unused variables''': the following variables are no longer used:<br />
** KERNEL<br />
** PCMCIA_MANAGER<br />
** MACHINE_KERNEL_VERSION<br />
** ROOT_FLASH_SIZE<br />
* '''Use =+ to set IMAGE_FSTYPES''': this interacts best when adding/overriding from other configuration files.<br />
* '''Remove MACHINE_KERNEL_PR''': this is no longer needed when BB_SIGNATURE_HANDLER is OEBasicHash (now the default) and the PR service is being used (in the dylan branch and newer); any changes to underlying metadata or dependencies of the kernel will automatically rebuild the kernel so there is no need to force it by hand.<br />
<br />
== Distro configuration ==<br />
<br />
* '''Build on top of defaultsetup.conf''': OE-Core provides a very basic distro config in meta/conf/distro/defaultsetup.conf which is included automatically by bitbake.conf, thus you only need to include bits of this config file that you want to change.<br />
* '''Replace references to glibc with eglibc''': set TCMODE and TCLIBC to select the toolchain mode and libc variant if you are not using the defaults.<br />
* '''Check DISTRO_FEATURES value''': if you are setting DISTRO_FEATURES, check the list you have against the currently available features (look at the default value in conf/distro/include/default-distrovars.inc in OE-Core; you can also do "git grep DISTRO_FEATURES" in the layers containing recipes you are using.)<br />
* '''Avoid setting machine configuration variables''': machine configuration should almost always be handled in each machine configuration file and not in the distro configuration.<br />
* '''Update blacklisting''': Replace ANGSTROM_BLACKLIST_pn-somerecipe = "message" with BLACKLIST[somerecipe] = "message" (assuming the recipe still exists and the blacklisting is still needed)<br />
* '''Replace references to ONLINE_PACKAGE_MANAGEMENT''': this variable has been replaced by checking for package-management within IMAGE_FEATURES.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=9193OE-Core Standalone Setup2017-01-11T20:08:48Z<p>PaulEggleton: Update for morty</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout morty<br />
cd bitbake<br />
git checkout 1.32<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=How_to_submit_a_patch_to_OpenEmbedded&diff=9129How to submit a patch to OpenEmbedded2016-12-01T20:24:55Z<p>PaulEggleton: Add a note about sending revised patches</p>
<hr />
<div>OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.<br />
<br />
== Finding the right place for your patch ==<br />
<br />
OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.<br />
<br />
New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].<br />
<br />
== A task-oriented guide to creating a patch ==<br />
<br />
Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.<br />
<br />
=== Set up git ===<br />
<br />
Properly configuring git (using tekkub@gmail.com as an example user)<br />
<br />
On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)<br />
<br />
sudo aptitude install git-core git-email<br />
<br />
These are important to the commit meta-data<br />
<br />
git config --global user.name "Tekkub"<br />
git config --global user.email "tekkub@gmail.com"<br />
<br />
Any Google Apps account<br />
<br />
git config --global sendemail.smtpserver smtp.gmail.com<br />
git config --global sendemail.smtpserverport 587<br />
git config --global sendemail.smtpencryption tls<br />
git config --global sendemail.smtpuser tekkupl@gmail.com<br />
<br />
You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.<br />
<br />
=== Subscribe to the mailing list ===<br />
<br />
You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.<br />
<br />
=== Committing your patch ===<br />
<br />
Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code. <br />
<br />
cd oe-core/ # or whereever you keep your clone of the repo<br />
git add meta/recipes-devtools/flex<br />
git commit -s # don't use the -m option but include my signature<br />
<br />
flex: backport Debian patches to fix generated code warnings<br />
<br />
The generated parser had warnings regarding signess and return check<br />
which makes Linux Kernel's perf tool from 3.4 release to fail without<br />
those patches.<br />
<br />
All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].<br />
<br />
Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.<br />
<br />
=== Sending patches ===<br />
<br />
There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.<br />
<br />
==== Sending using git-send-email ====<br />
<br />
To send just the top commit on your current branch (substitute mailing list address as appropriate):<br />
<br />
git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1<br />
<br />
For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.<br />
<br />
Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:<br />
--subject-prefix="meta-oe][PATCH"<br />
<br />
Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)<br />
<br />
==== Sending via a pull request ====<br />
<br />
Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:<br />
<br />
# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.<br />
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.<br />
# Push the branch to the remote.<br />
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.<br />
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.<br />
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.<br />
<br />
== Community review ==<br />
<br />
Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/<br />
<br />
If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.<br />
<br />
If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback.<br />
<br />
== Appendix ==<br />
<br />
=== Steps for people which don't have SMTP access for git === <br />
<br />
Patches should not be sent as attachment but inline.<br />
<br />
If you do not have SMTP access to your email account you have two options:<br />
<br />
1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)<br />
<br />
2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,<br />
wrap lines etc etc).<br />
<br />
A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.<br />
<br />
=== Streamlining git-send-email with configuration ===<br />
<br />
Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.<br />
<br />
<ul><br />
<li>Always confirm sending (for all repositories):<br />
<pre>git config --global sendemail.confirm always</pre></li><br />
<li>Set send-to email address for the repository (don't forget to specify the right address!):<br />
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre><br />
</li><br />
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):<br />
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre><br />
</li><br />
</ul><br />
<br />
==See also==<br />
* [[Commit Patch Message Guidelines]]<br />
* [[Styleguide]]<br />
<br />
[[Category:FAQ]]<br />
[[Category:User]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=9097Layers FAQ2016-10-26T02:59:13Z<p>PaulEggleton: /* I'd like to contribute improvements to the layer index code/design, how can I do that? */</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github] or [http://gitorious.org gitorious].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@linux.intel.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]].<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
=== I'd like to contribute improvements to the layer index code/design, how can I do that? ===<br />
<br />
The code can be found on [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ git.yoctoproject.org]. It uses the Django web framework and split into two parts - the web-based frontend that you interact with, and an update script that runs periodically to gather information about all of the layers in the database. There's further information in the README file on how to contribute.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=9095Layers FAQ2016-10-26T02:57:43Z<p>PaulEggleton: Add question on layer index contributions</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github] or [http://gitorious.org gitorious].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@linux.intel.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]].<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
=== I'd like to contribute improvements to the layer index code/design, how can I do that? ===<br />
<br />
The code can be found on [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ git.yoctoproject.org]. It is written in Django and split into two parts - the web-based frontend that you interact with, and an update script that runs periodically to gather information about all of the layers in the database. There's further information in the README file on how to contribute.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=8795OE-Core Standalone Setup2016-07-12T05:19:45Z<p>PaulEggleton: Update to current stable branches</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout krogoth<br />
cd bitbake<br />
git checkout 1.30<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Migrating_metadata_to_OE-Core&diff=8793Migrating metadata to OE-Core2016-07-12T05:16:46Z<p>PaulEggleton: Bring up-to-date</p>
<hr />
<div>The classes and BitBake configuration used in [[OpenEmbedded-Core]] require a few changes for recipes brought over from OE-Classic (and for new recipes written by developers used to working with OE-Classic).<br />
<br />
== Recipes ==<br />
<br />
The following section lists changes applicable to recipes (.bb files).<br />
<br />
=== Mandatory changes ===<br />
<br />
For recipes the following changes are required in order to build successfully:<br />
<br />
* '''Add LIC_FILES_CHKSUM''': this specifies one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version. It is mandatory and checked at the end of do_configure. See [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-specifying-LIC_FILES_CHKSUM Specifying LIC_FILES_CHKSUM] for more details.<br />
* '''Remove legacy staging''': legacy staging (do_stage) is no longer supported and BitBake will error out on parse of recipes that use it. Items previously in do_stage should be moved to do_install as appropriate; however they should actually install the files to somewhere under ${D} and ''not'' copy them into the staging directory directly or things will break later on. See [[Legacy staging]] for more information.<br />
* '''Ensure LICENSE is present''': the LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.<br />
* '''Ensure SRC_URI checksums are present''': for entries in SRC_URI pointing to sources other than SCMs or local files, i.e. http, ftp, etc., at least one SRC_URI checksum (md5sum/sha256sum) must be provided. If these are not present for an entry where it is required you will get an error which gives you the appropriate values to be added to the recipe. You can use the "name=" parameter within SRC_URI to distinguish between multiple entries. (This used to be optional, now it is mandatory.)<br />
* '''Remove comments in string values''': recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. is no longer allowed. Remove the commented out lines or move them to beyond where the string terminates.<br />
* '''Ensure values are quoted''': current versions of BitBake require that values are quoted; this was optional in the past. Single or double quotes are allowed but all values must now be quoted. (This does not affect how numeric values are interpreted, these have always been treated as strings.)<br />
* '''Use package name override with packaging variables''': the runtime package specific variables (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY, and the pre/post install/uninstall script functions pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm) should always have a package name override. For example, to set a runtime dependency for the main package use RDEPENDS_${PN}.<br />
* '''Replace oe* logging commands''': Any calls to oenote, oewarn, oefatal etc. in shell scripts need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.<br />
* '''Use FILESEXTRAPATHS to extend file search path''': Modifications to FILESPATHPKG and/or FILESPATH (or FILESDIR which is deprecated) should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
Changes applicable to the "danny" release and later:<br />
* '''Python functions should always use four spaces for indentation''' and not tabs - a warning will be produced if tabs are found. Previously four spaces was the convention but many python functions used tabs. This has been fixed in OE-Core and other layers, and since python uses indentation for statement blocks, is very important that you make the same changes to python functions in your recipes.<br />
* '''Change proto= to protocol= in SRC_URI''' - all fetchers have been changed to be consistent. Previously, some fetchers used proto and some protocol.<br />
* '''Change tasks to package groups''' - for custom task recipes, rename them from task-*.bb to packagegroup-*.bb, inherit packagegroup instead of inheriting task and remove anything that is now handled by meta/classes/packagegroup.bbclass. Also change any references to task-* to packagegroup-*.<br />
* '''Change any assumptions that libexecdir is /usr/libexec''': we now set libexecdir to ${libdir}/${BPN} to match with the Filesystem Hierarchy Standard (FHS).<br />
Changes applicable to the "dylan" release and later:<br />
* '''Fix continuation on last line of a comment''': if a comment ends in a line continuation (\) then the next line must also be a comment; any instance where this is not the case will now trigger a warning. Either remove the continuation character or make the next line a comment as well.<br />
* '''Remove use of BROKEN''' - use EXCLUDE_FROM_WORLD instead; ideally fix up the cause of the recipe being marked as BROKEN.<br />
Changes applicable to the "dora" release and later:<br />
* '''Rename functions/variables that currently contain "_remove_" or end with "_remove"''' - _remove is now a BitBake operator, so referencing it when you aren't intending to remove a value from a list variable will result in unexpected behaviour.<br />
Changes applicable to the "daisy" release and later:<br />
* '''Git SRCREV must match up with the branch''': if you are specifying a SRCREV value then it must now be on the branch specified in the URL entry (with the <tt>branch=</tt> parameter, or the master branch if none is specified). Alternatively if you wish to fetch a revision which isn't on any branch, specify <tt>nobranch=1</tt> in the URL.<br />
Changes applicable to the "dizzy" release and later:<br />
* '''Handle B != S in autotools recipes''': if the software being built is capable of building in a separate directory to the source, you don't need to do anything. Otherwise, either patch it so that it does, or inherit <tt>autotools-brokensep</tt> instead of <tt>autotools</tt>.<br />
* '''Handle the --foreign option in autotools recipes''': some older autotooled software does not follow the GNU standards in distributing certain files such as ChangeLog, AUTHORS, etc. Most upstream software packages that need to already tell automake to enable foreign mode themselves, but some recipes will need patches for this change. You can easily make the change by patching configure.ac so that it passes "foreign" to AM_INIT_AUTOMAKE() - see [http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2 this example].<br />
* '''Use pkg-config instead of standalone configuration scripts''': configuration scripts such as xml2-config, pcre-config, freetype-config etc. were being mangled in the past in order to have them return the correct paths within the sysroot, but this is no longer being done - instead of running these scripts, use pkg-config which has proper sysroot support. These scripts will now return an exit code and an invalid option for those calling scripts that don't pay attention to the exit code.<br />
* '''Do not stage the same files in multiple recipes''': overwriting files in the sysroot now triggers an error instead of a warning. Recipes should not be staging files to the sysroot (as a result of installing files within do_install) that are also staged by other recipes; allowing this in the past led to nasty situations that were often difficult to debug.<br />
Changes applicable to the "fido" release and later:<br />
* '''Set CLEANBROKEN if make clean doesn't work''': if a Makefile exists, do_configure runs <tt>make clean</tt> when re-executing in order to clean out generated files. If this isn't expected to work for the software a recipe builds, set CLEANBROKEN = "1" in the recipe.<br />
* '''Ensure dependencies on kernel headers are accounted for''': recipes that rely on the kernel source code/headers that do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example: <code>do_configure[depends] += "virtual/kernel:do_shared_workdir"</code><br />
Changes applicable to the "krogoth" release and later:<br />
* '''Explicitly expand variable references in python functions''': BitBake no longer expands variable references (e.g. <code>${VARNAME}</code>) in python functions - you should now explicitly expand these using <code>d.expand()</code> or simply by calling <code>d.getVar()</code> if you just want to get the value of a single variable.<br />
* '''Ensure recipe names are all lower-case''' - BitBake now requires overrides to be all lower case, which in practice means that anything that can be an override (distro names, machine names and recipe names) must also be lower case if the corresponding overrides are to function.<br />
* '''Ensure calls to d.getVar() and d.getVarFlag() specify the expansion parameter''' - <code>d.getVar('SOMEVAR')</code> and <code>d.getVarFlag('SOMEVAR', 'flagname')</code> are no longer allowed - the expansion parameter is now required. <code>d.getVar('SOMEVAR', True)</code> and <code>d.getVarFlag('SOMEVAR', 'flagname', True)</code> is usually what you want; in the rare cases that you explicitly do not want the value expanded, specify <code>False</code> instead of <code>True</code> (though it is worth pointing out that the default in earlier versions was <code>False</code>).<br />
* '''Handle change of default EXTRA_OEMAKE''': EXTRA_OEMAKE now defaults to "" instead of "-e MAKEFLAGS=". Setting EXTRA_OEMAKE to "-e MAKEFLAGS=" by default was a historical accident that has required many classes (e.g. autotools, module) and recipes to override this default in order to work with sensible build systems. When upgrading to the release, you must edit any recipe that relies upon this old default by either setting EXTRA_OEMAKE back to "-e MAKEFLAGS=" or by explicitly setting any required variable value overrides using EXTRA_OEMAKE, which is typically only needed when a Makefile sets a default value for a variable that is inappropriate for cross-compilation using the "=" operator rather than the "?=" operator.<br />
Changes applicable to master:<br />
* '''Handle Python 3''': BitBake now requires Python 3 and as such all python code in recipes and classes now needs to be compatible with Python 3.<br />
<br />
=== Best practices ===<br />
<br />
The following practices are required for patch submission to layers such as OE-Core and meta-oe, and recommended for recipes in your own layers:<br />
<br />
* Machine and distro-specific overrides should be removed from recipes for generic layers (especially meta-oe and OE-Core). These can be moved to bbappends in the appropriate machine / distro layer respectively. (Note however that architecture-specific overrides are allowed if necessary.)<br />
* Fix any QA issues reported during packaging.<br />
* Avoid hardcoding system paths such as /etc, /usr/bin, /usr/share and so on. Instead the values of the appropriate variables should be used (e.g. ${libdir}, ${bindir}, ${datadir} ...). If there are scripts or other files provided by the application such as initscripts you can fix the paths in them within do_install using sed. See bitbake.conf for a list of standard path variables and their default values (which may be - and often are - overridden by the distro configuration).<br />
* Initscripts should have the standard [http://wiki.debian.org/LSBInitScripts LSB header] (especially if no systemd unit file is being provided, since systemd relies upon information in the header when handling an initscript.)<br />
* In-tree patches to be applied to the source should have a proper header explaining what the patch does, a valid Signed-off-by, an [http://lists.yoctoproject.org/pipermail/yocto/2011-April/003446.html Upstream-Status] indicator.<br />
* Reset PR to "r0" by removing it. PR is still used, but new recipes being migrated should start again from r0 (the default value if not specified), and if you need it to increment on recipe changes you should use the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service PR service].<br />
* Use ${BPN} instead of ${PN} where you just want the recipe name without any prefixes/suffixes added by things like multilib and nativesdk (e.g. installation paths)<br />
* Use the <code>useradd</code> class instead of running useradd/groupadd directly to add users/groups.<br />
* NATIVE_INSTALL_WORKS for native recipes is no longer used and should be removed.<br />
* PRIORITY is no longer used and should be removed.<br />
* ENTERPRISE_DISTRO is no longer used. We now have LICENSE_FLAGS to support the uses that ENTERPRISE_DISTRO covered - see the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes Yocto Project Reference Manual].<br />
* Use d.getVar()/d.setVar() instead of bb.data.getVar()/bb.data.setVar() in python functions. The latter will still work, but are deprecated.<br />
* For class overrides (other than multilib) use class-xxx instead of virtclass-xxx. The latter will still work, but is deprecated.<br />
* "[http://mywiki.wooledge.org/Bashism Bashisms]" in shell scripts (particularly those that will be executed on the host) should be avoided. This allows compatibility with alternative shells e.g. Ubuntu's default (dash).<br />
* Pre/postinstall scripts (pkg_preinst / pkg_postinst) should ideally be written such that they can run on the host during do_rootfs instead of only on the target. In practice this means that you need to use ${D} before all paths, and anything that is architecture-specific will need to be run under qemu (although the latter is not very common).<br />
* For readability, the variables/functions within a recipe should be ordered in the same order in which they are used - i.e. "meta" information above (DESCRIPTION, SUMMARY, DEPENDS, LICENSE etc.), followed by information needed for do_fetch (SRC_URI, etc.), then anything for do_patch, do_compile, do_install, and then do_package (e.g. PACKAGES, FILES, RDEPENDS, RRECOMMENDS...).<br />
* Shell functions in OE-Core are using tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell task, python tasks and for indentation of multi-line variables)<br />
<br />
== Machine configuration ==<br />
<br />
The following section lists changes applicable to machine configuration files (conf/machine/*).<br />
<br />
* '''Ensure you are using the correct tune files''': the tune files in OE-Core have been reorganised and updated; see conf/machine/include/ and check that you are including the appropriate file(s).<br />
* '''Remove variable settings already handled by the tune files''': check if any values you are setting are already set by the tune files; if they are, you don't need to set them again. Of course if you wish to override one of the settings for your machine that is fine.<br />
* '''Update to a newer Linux kernel''': current versions of kernel-sensitive userspace components (e.g. udev) expect a modern kernel; older kernels may not allow the system to boot. If you're not able to do this you may need to provide downgraded versions of these components that are compatible with the kernel you are building. Note that all support for the 2.4 kernel has been removed.<br />
* '''Check MACHINE_FEATURES value''': check the list you are setting against the currently available features (see [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine here], or you can do "git grep MACHINE_FEATURES" in the layers containing recipes you are using.) In particular, the "kernel26" feature can be removed as we no longer support the 2.4 kernel which necessitated having a flag to say the machine is using a 2.6 kernel instead.<br />
* '''Remove unused variables''': the following variables are no longer used:<br />
** KERNEL<br />
** PCMCIA_MANAGER<br />
** MACHINE_KERNEL_VERSION<br />
** ROOT_FLASH_SIZE<br />
* '''Use =+ to set IMAGE_FSTYPES''': this interacts best when adding/overriding from other configuration files.<br />
* '''Remove MACHINE_KERNEL_PR''': this is no longer needed when BB_SIGNATURE_HANDLER is OEBasicHash (now the default) and the PR service is being used (in the dylan branch and newer); any changes to underlying metadata or dependencies of the kernel will automatically rebuild the kernel so there is no need to force it by hand.<br />
<br />
== Distro configuration ==<br />
<br />
* '''Build on top of defaultsetup.conf''': OE-Core provides a very basic distro config in meta/conf/distro/defaultsetup.conf which is included automatically by bitbake.conf, thus you only need to include bits of this config file that you want to change.<br />
* '''Replace references to glibc with eglibc''': set TCMODE and TCLIBC to select the toolchain mode and libc variant if you are not using the defaults.<br />
* '''Check DISTRO_FEATURES value''': if you are setting DISTRO_FEATURES, check the list you have against the currently available features (look at the default value in conf/distro/include/default-distrovars.inc in OE-Core; you can also do "git grep DISTRO_FEATURES" in the layers containing recipes you are using.)<br />
* '''Avoid setting machine configuration variables''': machine configuration should almost always be handled in each machine configuration file and not in the distro configuration.<br />
* '''Update blacklisting''': Replace ANGSTROM_BLACKLIST_pn-somerecipe = "message" with BLACKLIST[somerecipe] = "message" (assuming the recipe still exists and the blacklisting is still needed)<br />
* '''Replace references to ONLINE_PACKAGE_MANAGEMENT''': this variable has been replaced by checking for package-management within IMAGE_FEATURES.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=8791Layers FAQ2016-07-12T04:55:22Z<p>PaulEggleton: create-recipe is dead, long live devtool / recipetool</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github] or [http://gitorious.org gitorious].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@linux.intel.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]].<br />
* Try <code>devtool add</code> - this will attempt to automatically create a recipe for a given source tree and set up an environment where you can patch the source easily (which you often need to do when you're writing a recipe). See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#use-devtool-to-integrate-new-code Use devtool add to Integrate New Code] in the Yocto Project Development Manual.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=TSC&diff=8567TSC2016-03-13T23:00:29Z<p>PaulEggleton: Update for changes over the last year</p>
<hr />
<div>=OE Technical Steering Committee=<br />
<br />
The TSC consists of 5 people who are elected by, and ultimately be answerable to, the members of the OpenEmbedded organisation.<br />
<br />
Here is the [[TSCCharter | working copy]] of the new TSC charter.<br />
<br />
The TSC meets on an irregular basis, but is happy to hold meetings on request if there are issues to discuss.<br />
<br />
The TSC discusses technical issues for the direction of OpenEmbedded. Note that the TSC is NOT chartered with actually doing all of the work discussed, but they do make every effort to locate resources to do that work.<br />
<br />
= Members =<br />
<br />
In order by election:<br />
<br />
* Martin Jansa (JaMa) - elected Jun 2015<br />
* Richard Purdie (RP) - elected Oct 2015<br />
* Khem Raj (khem) - elected Oct 2015<br />
* Paul Eggleton (bluelightning) - elected Oct 2015<br />
* Mark Hatle (fray) - elected Oct 2015<br />
<br />
Each member serves a two-year term. During election time, one member may stand for election every two months.<br />
<br />
= Responsibilities =<br />
<br />
On a day-to-day basis the TSC is responsible for making<br />
tactical policy decisions, resolving disputes between contributors,<br />
administering access control to the git tree, and generally promoting<br />
good development practice.<br />
<br />
= Decision Making =<br />
<br />
Decisions are made where necessary by majority vote. Once a decision is made by<br />
the technical steering committee, the decision should be respected as a democratic decision.<br />
<br />
= TSC issue escalation procedure =<br />
<br />
The best way to agendize an issue for the TSC is to send email to one of the TSC members or to [mailto:jefro@jefro.net Jefro], the curator. The issue will be added to the agenda for the next meeting. If the issue is particularly urgent, a specific TSC meeting may be called.<br />
<br />
= TSC mailing list archive =<br />
<br />
http://lists.openembedded.org/pipermail/tsc/<br />
<br />
= Meeting Minutes =<br />
<br />
== 2013 Minutes ==<br />
<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000362.html 29 January 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-February/000363.html 12 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000365.html 26 February 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-March/000366.html 19 March 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-April/000367.html 8 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/000368.html 23 April 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-May/00037.html 7 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000372.html 21 May 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000373.html 4 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-June/000381.html 18 June 2013]<br />
* [http://lists.openembedded.org/pipermail/tsc/2013-August/000393.html 2 July 2013]<br />
* 16 July 2013<br />
* 30 July 2013 (public meeting)<br />
* 13 August 2013 (cancelled)<br />
* 27 August 2013<br />
<br />
== 2012 Minutes ==<br />
<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-January/000330.html 3-Jan-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-January/000331.html 17-Jan-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-February/000332.html 30-Jan-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-March/000334.html 15-Feb-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-March/000335.html 28-Feb-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-March/000336.html 13-Mar-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-April/000337.html 27-Mar-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-April/000340.html 10-Apr-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-May/000342.html 24-Apr-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-May/000341.html 08-May-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-June/000343.html 22-May-2012]<br />
* 5-Jun-2012 (no meeting)<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-June/000344.html 19-Jun-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-August/000346.html 3-Jul-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-August/000347.html 17-Jul-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-August/000348.html 31-Jul-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-August/000353.html 14-Aug-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-September/000354.html 28-Aug-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-September/000355.html 11-Sep-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-October/000356.html 25-Sep-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-October/000357.html 9-Oct-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-November/000358.html 23-Oct-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2012-December/000359.html 6-Nov-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2013-January/000360.html 20-Nov-2012]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2013-January/000361.html 4-Dec-2012]<br />
<br />
== 2011 Minutes ==<br />
<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/029974.html 14-Feb-2011]<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/030355.html 21-Feb-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-March/000113.html 28-Feb-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-March/000192.html 10-Mar-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-March/000193.html 17-Mar-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-March/000208.html 25-Mar-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-April/000224.html 31-Mar-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-April/000232.html 10-Apr-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-May/000241.html 28-Apr-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-May/000240.html 05-May-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000245.html 12-May-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000246.html 19-May-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000249.html 26-May-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000250.html 02-Jun-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000251.html 09-Jun-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000258.html 16-Jun-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-June/000266.html 23-Jun-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-July/000270.html 30-Jun-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-July/000272.html 14-Jul-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-August/000283.html 21-Jul-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-August/000285.html 04-Aug-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-September/000298.html 11-Aug-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-October/000301.html 01-Sep-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-September/000297.html 16-Sep-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-September/000299.html 29-Sep-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-October/000302.html 06-Oct-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-October/000303.html 20-Oct-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-November/000304.html 03-Nov-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-November/000322.html 17-Nov-2011]<br />
* [http://lists.linuxtogo.org/pipermail/tsc/2011-November/000323.html 22-Nov-2011]<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014563.html 13-Dec-2011]<br />
<br />
== 2010 Minutes ==<br />
<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-June/020655.html June 2010]<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html May 2010]<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-March/017876.html March 2010]<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-February/017094.html February 2010]<br />
* [http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-January/015931.html January 2010]<br />
<br />
[[Category:Policy]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=8451OE-Core Standalone Setup2016-02-03T23:04:08Z<p>PaulEggleton: Update for jethro release</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout jethro<br />
cd bitbake<br />
git checkout 1.28<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Testing&diff=8095Testing2015-10-30T09:26:39Z<p>PaulEggleton: This page is outdated</p>
<hr />
<div>{{Outdated}}<br />
<br />
= Overview =<br />
<br />
* [http://search.gmane.org/?query=testing+branch&author=&group=gmane.comp.handhelds.openembedded&sort=date&DEFAULTOP=and&xP=Ztest%09Zbranch&xFILTERS=Gcomp.handhelds.openembedded---A mail list discussions related to the testing branch]<br />
<br />
The OpenEmbedded Testing branch is a git branch of the OE metadata with the goal of providing a recent snapshot of OE that is known to be build-able for a subset of distros, machines, images, and host workstations. The goal of this effort is twofold:<br />
# the testing branch represents a reasonably stable version of OE that builds for most tested combinations<br />
# for all tested combinations, we list the last known-good-build tag so that users can always start with something that will build.<br />
<br />
As an example on how to configure your test setup see [[TestingScript]].<br />
<br />
= Test combinations =<br />
<br />
{| class="sortable" border="1"<br />
!'''machine''' !!'''distro''' !!'''target''' !!'''workstation''' !!'''bitbake''' !!'''tester''' !!'''last successful build''' !!'''build type''' !!'''Current issues'''<br />
|-<br />
|mpc8315e-rdb ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|p2020ds ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemux86 ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemuppc ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemuarm ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemush4 ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemumips ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemumips64 ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|qemumipsel ||minimal minimal-uclibc ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-28 ||clean ||<br />
|-<br />
|mpc8315e-rdb ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|p2020ds ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemux86 ||minimal ||nas-server-image native-sdk-image console-image x11-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-13 ||clean ||<br />
|-<br />
|qemux86 ||minimal ||minimal-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean || Rest fixed in http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=bd7a0fa284e9d3746513b97f4e5672aa3f82a6b2<br />
|-<br />
|qemuppc ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemuarm ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemush4 ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemumips ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemumips64 ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemumipsel ||minimal ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|mpc8315e-rdb ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|p2020ds ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean || http://pastebin.com/62qMxWVu<br />
|-<br />
|qemux86 ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemuppc ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemuarm ||minimal-uclibc ||native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean || http://pastebin.com/0tMmXnuP<br />
|-<br />
|qemush4 ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemumips ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemumips64 ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|qemumipsel ||minimal-uclibc ||nas-server-image native-sdk-image console-image minimal-image x11-image meta-toolchain ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|hawkboard ||angstrom-2008.1 ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|hawkboard ||angstrom-2010.x ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|mini6410 ||angstrom-2008.1 ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|mini6410 ||angstrom-2010.x ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|mini2440 ||angstrom-2008.1 ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|beagleboard ||angstrom-2008.1 ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|beagleboard ||angstrom-2010.x ||console-image ||RHEL5 / Ubuntu 8.04 32-bit || master ||[[User:trini|trini]] [4] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|beagleboard ||angstrom-2008.1 ||beagleboard-linuxtag2010-demo-image ||Ubuntu 10.10 64-bit || master ||[[User:Cbrake|cbrake]] [5] ||testing_2011-01-20 ||clean || <br />
|-<br />
|beagleboard ||angstrom-2008.1 ||console-image ||Ubuntu 10.10 64-bit || master ||[[User:Cbrake|cbrake]] [5] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|beagleboard ||angstrom-2008.1 ||qt4-x11-demo-image (4.7.1) ||Ubuntu 10.10 64-bit || master ||[[User:Cbrake|cbrake]] [5] ||testing_2011-01-20 ||clean ||<br />
|-<br />
|beagleboard ||angstrom-2008.1 ||qt4e-demo-image (4.7.1) ||Ubuntu 10.10 64-bit || master ||[[User:Cbrake|cbrake]] [5] ||testing_2011-01-20 ||clean || <br />
|-<br />
|bug20 ||angstrom-2008.1 ||minimal-image console-image openjdk-6 meta-toolchain meta-toolchain-qte||Ubuntu 9.04 64-bit || 1.10.2 ||[[User:Stefan|Stefan]] ||testing_2011-01-06||clean ||<br />
|-<br />
|bug20 ||angstrom-2008.1 ||minimal-image console-image openjdk-6 meta-toolchain meta-toolchain-qte||Ubuntu 10.10 32-bit || master ||[[User:Stefan|Stefan]] ||testing_2011-01-06||clean ||<br />
|-<br />
|efikamx ||minimal ||native-sdk-image console-image x11-image ||Ubuntu 10.10 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|omap5912osk ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemuarm ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemumips ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemumips64 ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemuppc ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemush4 ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemux86 ||minimal ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|efikamx ||minimal-uclibc ||native-sdk-image console-image x11-image ||Ubuntu 10.10 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|omap5912osk ||minimal-uclibc ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemuarm ||minimal-uclibc ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemumips ||minimal-uclibc ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemuppc ||minimal-uclibc ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemush4 ||minimal-uclibc ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemux86 ||minimal-uclibc ||console-image native-sdk-image x11-image ||Ubuntu 10.04 64-bit || master ||[[User:khem|khem]] ||testing_2010-12-24||clean ||<br />
|-<br />
|qemumipsel ||minimal ||x11-image meta-toolchain ||Slackware 13.1 64-bit || master ||[[User:grg|grg]] ||release-2010.12||clean ||<br />
|-<br />
|qemumipsel ||minimal-uclibc ||minimal-image ||Slackware 13.1 64-bit || master ||[[User:grg|grg]] ||release-2010.12||clean ||<br />
|-<br />
|qemumipsel ||micro-uclibc ||micro-image ||Slackware 13.1 64-bit || master ||[[User:grg|grg]] ||release-2010.12||clean ||<br />
|-<br />
|qemuarm ||angstrom-2010.x ||x11-gpe-image ||Fedora 12 32-bit || ||[[User:gthomas|gthomas]] ||testing_2010-09-07||clean ||testing_2010-09-13 fails to build xf86-input-mouse<br />
|-<br />
|qemuarm ||angstrom-2010.x ||opie-image ||Fedora 12 32-bit || ||[[User:gthomas|gthomas]] ||testing_2010-09-07||clean ||<br />
|-<br />
|qemuarm ||angstrom-2010.x ||opie-kdepim-image ||Fedora 12 32-bit || ||[[User:gthomas|gthomas]] ||None||clean ||fails to build pwmpi<br />
|-<br />
|beagleboard ||angstrom-2008.1 ||angstrom-gnome-image ||Ubuntu 9.10 32-bit || ||[[User:gthomas|gthomas]] ||testing_2010-08-30||clean ||<br />
|-<br />
|beagleboard ||angstrom-2010.x ||beagleboard-linuxtag2010-demo-image ||Fedora 12 32-bit || ||[[User:gthomas|gthomas]] ||None ||clean ||fails to build ti-dsplink if /opt is writeable<br />
|-<br />
|qemuarm ||angstrom-2008.1 ||x11-gpe-image ||Fedora 12 32-bit || ||[[User:gthomas|gthomas]] ||testing_2010-10-04||clean ||<br />
|-<br />
|beagleboard ||angstrom-2008.1 ||x11-gpe-image ||Fedora 12 32-bit || ||[[User:gthomas|gthomas]] ||testing_2010-10-04||clean ||<br />
|-<br />
|imote2 || angstrom-2008.1 || imote2-image || Gentoo || || [[User:jic23|jic23]] || testing_2011-01-28 || clean ||<br />
|-<br />
|imote2 || angstrom-2008.1 || meta-toolchain || Gentoo || || [[User:jic23|jic23]] || testing_2011-01-28 || clean ||<br />
|-<br />
|imote2 || angstrom-2010.x || imote2-image || Gentoo || || [[User:jic23|jic23]] || testing_2011-01-28 || clean ||<br />
|-<br />
|imote2 || angstrom-2010.x || meta-toolchain || Gentoo || || [[User:jic23|jic23]] || testing_2011-01-28 || clean ||<br />
|-<br />
|hipox ||angstrom-2008.1 ||minimal-image ||openSUSE 11.3 32-bit || 1.10.2 ||[[User:Sledz|Sledz]] [2]||testing_2011-01-28||clean ||testing_2011-02-03: do_configure libtool-native failed http://tinderbox.openembedded.net/packages/1924643/<br />
|-<br />
|hipox ||angstrom-2008.1 ||console-image ||openSUSE 11.3 32-bit || 1.10.2 ||[[User:Sledz|Sledz]] [2]||testing_2011-01-28||clean ||testing_2011-02-03: do_configure libtool-native failed<br />
|-<br />
|hipox ||angstrom-2008.1 ||angstrom-gnome-image ||openSUSE 11.3 32-bit || 1.10.2 ||[[User:Sledz|Sledz]] [2]||testing_2011-01-28||clean ||testing_2011-02-03: do_configure libtool-native failed<br />
|-<br />
|hipox ||angstrom-2008.1 ||angstrom-x-image ||openSUSE 11.3 32-bit || 1.10.2 ||[[User:Sledz|Sledz]] [2]||None||clean ||testing_2011-02-03: do_configure libtool-native failed<br>testing_2011-01-28: do_rootfs failed http://tinderbox.openembedded.net/packages/1903422/<br />
|-<br />
|neek ||minimal ||console-image ||Ubuntu 10.04 64-bit || 1.10 ||eFfeM [1] ||None ||clean || testing_2011-02-03 QA issue in gtk-doc.bb<br />
|-<br />
|nslu2le ||slugos ||slugos-image ||Ubuntu 10.04 64-bit || 1.10 ||eFfeM [1] || testing_2011-02-03 ||clean || <br />
|-0<br />
|nslu2be ||slugos ||slugos-image ||Ubuntu 10.04 64-bit || 1.10 ||eFfeM [1] || testing_2011-02-03 ||clean || <br />
|-<br />
|calamari ||minimal ||console-image ||Ubuntu 10.04 64-bit || 1.10 ||eFfeM [1] || testing_2011-02-03 ||clean || builds but has QA issues with cups, libsdl-x11, python-sqlite3, binutils<br />
|-<br />
|mpc8313e-rdb ||minimal ||console-image ||Ubuntu 10.04 64-bit || 1.10 ||eFfeM [1] || testing_2011-02-03 ||clean || builds but has QA issues with cups, libsdl-x11, python-sqlite3, binutils<br />
|-<br />
|sheevaplug ||minimal ||console-image ||Ubuntu 10.04 64-bit || 1.10 ||eFfeM [1] || testing_2011-02-03 ||clean || builds but has QA issues with cups, libsdl-x11, python-sqlite3, binutils<br />
|-<br />
|ts72xx ||angstrom-2008.1 ||minimal-image uclibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean ||<br />
|-<br />
|ts72xx ||angstrom-2008.1 ||minimal-image glibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean ||<br />
|-<br />
|ts72xx ||angstrom-2008.1 ||console-image uclibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean || x264-r2245-r7 FAILED http://tinderbox.openembedded.net/public/logs/task/10303075.txt<br />
|-<br />
|ts72xx ||angstrom-2008.1 ||console-image glibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean ||<br />
|-<br />
|ts72xx ||angstrom-2010.x ||minimal-image glibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean ||<br />
|-<br />
|ts72xx ||angstrom-2010.x ||minimal-image uclibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean || libiconv-1.13.1-r0 FAILED http://tinderbox.openembedded.net/public/logs/task/10280531.txt<br />
|-<br />
|ts72xx ||angstrom-2010.x ||console-image glibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean ||<br />
|-<br />
|ts72xx ||angstrom-2010.x ||console-image uclibc ||Ubuntu 10.04 64-bit ||master ||ynezz || testing_2010-11-12 ||clean || libiconv-1.13.1-r0 FAILED http://tinderbox.openembedded.net/packages/986368/<br />
|-<br />
|x86 ||angstrom-2008.1 ||meta-toolchain ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||<br />
|-<br />
|x86 ||angstrom-2008.1 ||console-image ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||x264-r2245-r7 FAILED http://tinderbox.openembedded.net/packages/1402599/<br />
|-<br />
|overo ||angstrom-2008.1 ||meta-toolchain ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||<br />
|-<br />
|overo ||angstrom-2008.1 ||meta-toolchain-qte ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||<br />
|-<br />
|overo ||angstrom-2008.1 ||x-load ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||<br />
|-<br />
|overo ||angstrom-2008.1 ||u-boot ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||<br />
|-<br />
|overo ||angstrom-2008.1 ||console-image ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||<br />
|-<br />
|overo ||angstrom-2008.1 ||x11-image ||Ubuntu 10.04 64-bit || 1.10.1 ||tharvey ||testing_2010-12-23||clean ||Many QA Issues<br />
|-<br />
|collie ||angstrom-2010.x, minimal ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||clean, inc ||<br />
|-<br />
|tosa, akita ||angstrom-2010.x ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||clean ||<br />
|-<br />
|tosa, akita ||angstrom-2010.x ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||inc ||udev_165.bb failed to build because of 'extras/mtd_probe/mtd_probe.h:20:26: fatal error: mtd/mtd-user.h: No such file or directory' (fixed after cleaning linux-libc-headers)<br />
|-<br />
|tosa, akita ||minimal ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||clean, inc ||<br />
|-<br />
|efikamx ||angstrom-2010.x ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||clean, inc ||<br />
|-<br />
|efikamx ||minimal ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||clean ||<br />
|-<br />
|efikamx ||minimal ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||inc ||xf86-input-mouse_1.7.0.bb failed because of old xorg-server (fixed after rebuild of virtual/xserver)<br />
|-<br />
|ben-nanonote ||angstrom-2010.x, minimal ||console-image x11-image opie-image ||Debian 6.0.1 (squeeze) /x86_64 ||master e4acd09 ||[[User:Jay7|Jay7]] ||testing-next f0652d9 ||clean,inc ||linux-kexecboot_2.6.38.bb failed to build because of no defconfig for this machine exists<br />
|-<br />
|akita ||angstrom-2008.1 ||minimal-image, x11-image ||Debian Lenny 64-bit ||1.10.1 ||[[User:Koan|mckoan]] [3] ||none ||clean ||<br />
|-<br />
|ronetix-pm9263 ||kaeilos-2010 ||minimal-image, <del>x11-image</del> ||Debian Lenny 64-bit ||1.10.1 ||[[User:Koan|mckoan]] [3] ||none ||clean ||<br />
|-<br />
|mc355 ||kaeilos-2010 ||minimal-image ||Debian Lenny 64-bit ||1.10.1 ||[[User:Koan|mckoan]] [3] ||none ||clean ||<br />
|-<br />
|akita ||kaeilos ||minimal-image, x11-image ||Debian Lenny 64-bit ||1.10.1 ||[[User:Koan|mckoan]] [3] ||none ||clean ||<br />
|-<br />
|ronetix-pm9263 ||kaeilos ||minimal-image, x11-image ||Debian Lenny 64-bit ||1.10.1 ||[[User:Koan|mckoan]] [3] ||none ||clean ||<br />
|-<br />
|palmpre ||shr ||shr-lite-image ||Debian Sid 64-bit || 1.11 ||[[User:morphis|morphis]] ||release-2010.12 8733e77 ||clean || <br />
|-<br />
|at91sam9m10g45ek ||angstrom-2010.x ||console-image x11-image x11-gpe-image ||Red Hat Enterprise Linux Client release 5.2 64-bit || 1.10.1 ||[[User:noglitch|noglitch]] ||release-2010.12 a643fb8 ||clean ||<br />
|-<br />
|at91sam9g20ek ||angstrom-2010.x ||console-image ||Red Hat Enterprise Linux Client release 5.2 64-bit || 1.10.1 ||[[User:noglitch|noglitch]] ||release-2010.12 a643fb8 ||clean ||<br />
<br />
|-<br />
!'''machine''' !!'''distro''' !!'''target''' !!'''workstation''' !!'''bitbake''' !!'''tester''' !!'''last successful build''' !!'''build type''' !!'''Current issues'''<br />
|}<br />
<br />
[1] Testing done by eFfeM. Resources kindly provided by [http://www.axon.tv/ Axon Digital Design]<br /><br />
[2] Testing done by [[User:Sledz|Sledz]]. Resources kindly provided by [http://www.dresearch.de/ DResearch Digital Media Systems GmbH]<br /><br />
[3] Testing done by [[User:Koan|mckoan]]. Resources kindly provided by [http://www.koansoftware.com/ Koan sas]<br /><br />
[4] Testing done by [[User:trini|Tom Rini]]. Resources kindly provided by [http://mentor.com/linux Mentor Graphics]<br /><br />
[5] Testing done by [[User:cbrake|Cliff Brake]]. Resources kindly provided by [http://bec-systems.com BEC Systems]<br /><br />
<br />
= Testing Procedure =<br />
<br />
The general process for managing the testing branch is:<br />
# Starting at approximately 9PM GMT on Thursday of every week, the master branch is merged to the '''testing-next''' branch. This is automatically done by a [http://cgit.openembedded.org/cgit.cgi/openembedded/tree/contrib/testing/update-testing-branch.sh script] running in a cron job on [[User:Cbrake|Cliff's]] workstation. The goal is to have the testing-branch in place so that all testers can starting building on Friday and build over the weekend when computers are more likely free.<br />
# The above script sends an email to the oe-devel list with a subject of "testing branch YYYY-MM-DD". All volunteers preferably do an incremental build (from last weeks snapshot), then clean tmp and do a clean build of the combinations they test. If time or resources are not available, then incremental builds are not required. After builds are complete, update the above chart, and report status/issues as replies to the above email.<br />
# If most combinations build by following Thursday, the testing-next branch is merged to the '''testing''' branch. Regardless, the repository is tagged with the tested_YYYY-MM-DD tag. An annotated tag is used with a message that includes a text copy of the above table with variations that have been tested building for this cycle. The reason we tag after testing is complete is so that we can include status in the annotated tag. This way information about what was tested with each tagged version is captured in the repository. A link is added for easy reference to the log below.<br />
# If a build fails, then issues are reported, and we try to get issues fixed before the next weeks testing cycle.<br />
# Not every combination is tested on every cycle, due to availability of testers, so we list the last known built version in the above chart. Testers are responsible for updating the above chart.<br />
# All testers are encouraged to use [[Tinderbox]] so problems are automatically reported and logged, and issues in the above chart can be linked to Tinderbox.<br />
<br />
We strongly encourage chip and SBC/Module vendors to become involved in this effort to ensure OE works for your platforms.<br />
<br />
= Useful software =<br />
* Hudson http://hudson-ci.org/<br />
* BuildBot http://buildbot.net/trac<br />
* [[Testing:TestBuilder|TestBuilder]] by [[User:Jay7|Jay7]]<br />
* [[TestingScript]] by [[User:EFfeM|EFfeM]]<br />
<br />
= Testing Log =<br />
<br />
For a list of available test tags and results, see: http://cgit.openembedded.org/cgit.cgi/openembedded/refs/tags<br />
<br />
[[Category:Quality Assurance]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OEDEM_2015&diff=7867OEDEM 20152015-09-07T09:26:35Z<p>PaulEggleton: Add myself to the list</p>
<hr />
<div>The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.<br />
<br />
== Location and Time ==<br />
<br />
[http://www.thegibsonhotel.ie/ The Gibson Hotel]<br><br />
Point Village<br><br />
Dublin 1, Ireland<br><br />
+353 1 681 5000<br />
<br />
9am - 5pm (note: times may change)<br />
<br />
== OpenEmbedded eV General Assembly ==<br />
<br />
We have a short administrative meeting before starting the Developer meeting. All are welcome for this.<br />
<br />
* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.<br />
* Define a method for identifying lapsed memberships.<br />
* Proxy form [[File:Proxy_instructions-oe.pdf]]<br />
<br />
== Agenda ==<br />
<br />
* Standards for BSP behavior. (Crofton)<br />
* Tentative: User/group definitions. Distribution wide (uid/gid) vs layer wide (primary group, path, description, etc for users). (Saur)<br />
* LayerIndex feature requests (tlwoerner)<br />
** build feedback (autobuilders and off-site)<br />
** master branch parsability<br />
* Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)<br />
* meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)<br />
* OVERRIDE syntax: is it time to reconsider _?<br />
<br />
== Attendees ==<br />
<br />
If you plan to attend, please list your name below.<br />
<br />
# Jeff Osier-Mixon (jefro)<br />
# Philip Balister (Crofton)<br />
# Trevor Woerner (tlwoerner)<br />
# Anders Darander (andersd)<br />
# Marco Cavallini (mckoan)<br />
# Koen Kooi (koen)<br />
# Alexandre Belloni (abelloni)<br />
# Armin Kuster (armpit)<br />
# Belén Barros Pena (belen) (tentative)<br />
# Peter Kjellerstedt (Saur)<br />
# Alejandro del Castillo (adelcast)<br />
# Denys Dmytriyenko (denix)<br />
# Sean Hudson (darknighte)<br />
# Nathan Rossi (nrossi)<br />
# Mark Hatle (fray)<br />
# Nicolas Dechesne (ndec)<br />
# Paul Eggleton (bluelightning)</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Migrating_metadata_to_OE-Core&diff=7857Migrating metadata to OE-Core2015-08-20T09:10:02Z<p>PaulEggleton: Update for changes up to fido</p>
<hr />
<div>The classes and BitBake configuration used in [[OpenEmbedded-Core]] require a few changes for recipes brought over from OE-Classic (and for new recipes written by developers used to working with OE-Classic).<br />
<br />
== Recipes ==<br />
<br />
The following section lists changes applicable to recipes (.bb files).<br />
<br />
=== Mandatory changes ===<br />
<br />
For recipes the following changes are required in order to build successfully:<br />
<br />
* '''Add LIC_FILES_CHKSUM''': this specifies one or more files or sections of files from the source that can be used to detect if the license of the software has been changed in a newer version. It is mandatory and checked at the end of do_configure. See [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-specifying-LIC_FILES_CHKSUM Specifying LIC_FILES_CHKSUM] for more details.<br />
* '''Remove legacy staging''': legacy staging (do_stage) is no longer supported and BitBake will error out on parse of recipes that use it. Items previously in do_stage should be moved to do_install as appropriate; however they should actually install the files to somewhere under ${D} and ''not'' copy them into the staging directory directly or things will break later on. See [[Legacy staging]] for more information.<br />
* '''Ensure LICENSE is present''': the LICENSE field, whilst usually included in most recipes in the past anyway, is now mandatory. It should be as specific and as correct as possible (e.g. "GPLv2", not just "GPL") and try to be consistent with other recipes.<br />
* '''Ensure SRC_URI checksums are present''': for entries in SRC_URI pointing to sources other than SCMs or local files, i.e. http, ftp, etc., at least one SRC_URI checksum (md5sum/sha256sum) must be provided. If these are not present for an entry where it is required you will get an error which gives you the appropriate values to be added to the recipe. You can use the "name=" parameter within SRC_URI to distinguish between multiple entries. (This used to be optional, now it is mandatory.)<br />
* '''Remove comments in string values''': recent versions of BitBake no longer allow comments in multi-line strings, so the tradition of being able to comment out lines within a multi-line SRC_URI or when setting configure flags etc. is no longer allowed. Remove the commented out lines or move them to beyond where the string terminates.<br />
* '''Ensure values are quoted''': current versions of BitBake require that values are quoted; this was optional in the past. Single or double quotes are allowed but all values must now be quoted. (This does not affect how numeric values are interpreted, these have always been treated as strings.)<br />
* '''Use package name override with packaging variables''': the runtime package specific variables (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RCONFLICTS, RREPLACES, FILES, ALLOW_EMPTY, and the pre/post install/uninstall script functions pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm) should always have a package name override. For example, to set a runtime dependency for the main package use RDEPENDS_${PN}.<br />
* '''Replace oe* logging commands''': Any calls to oenote, oewarn, oefatal etc. in shell scripts need to be replaced with the "bb" equivalent, i.e. bbnote, bbwarn, bbfatal etc.<br />
* '''Use FILESEXTRAPATHS to extend file search path''': Modifications to FILESPATHPKG and/or FILESPATH (or FILESDIR which is deprecated) should be replaced by prepending to FILESEXTRAPATHS; in addition, you no longer need to define THISDIR (and should not do so). For example, to add a directory to be searched for patches and other files which is named with PN, do the following (note the immediate evaluation operator := and trailing colon, these are important):<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
Changes applicable to the "danny" release and later:<br />
* '''Python functions should always use four spaces for indentation''' and not tabs - a warning will be produced if tabs are found. Previously four spaces was the convention but many python functions used tabs. This has been fixed in OE-Core and other layers, and since python uses indentation for statement blocks, is very important that you make the same changes to python functions in your recipes.<br />
* '''Change proto= to protocol= in SRC_URI''' - all fetchers have been changed to be consistent. Previously, some fetchers used proto and some protocol.<br />
* '''Change tasks to package groups''' - for custom task recipes, rename them from task-*.bb to packagegroup-*.bb, inherit packagegroup instead of inheriting task and remove anything that is now handled by meta/classes/packagegroup.bbclass. Also change any references to task-* to packagegroup-*.<br />
* '''Change any assumptions that libexecdir is /usr/libexec''': we now set libexecdir to ${libdir}/${BPN} to match with the Filesystem Hierarchy Standard (FHS).<br />
Changes applicable to the "dylan" release and later:<br />
* '''Fix continuation on last line of a comment''': if a comment ends in a line continuation (\) then the next line must also be a comment; any instance where this is not the case will now trigger a warning. Either remove the continuation character or make the next line a comment as well.<br />
* '''Remove use of BROKEN''' - use EXCLUDE_FROM_WORLD instead; ideally fix up the cause of the recipe being marked as BROKEN.<br />
Changes applicable to the "dora" release and later:<br />
* '''Rename functions/variables that currently contain "_remove_" or end with "_remove"''' - _remove is now a BitBake operator, so referencing it when you aren't intending to remove a value from a list variable will result in unexpected behaviour.<br />
Changes applicable to the "daisy" release and later:<br />
* '''Git SRCREV must match up with the branch''': if you are specifying a SRCREV value then it must now be on the branch specified in the URL entry (with the <tt>branch=</tt> parameter, or the master branch if none is specified). Alternatively if you wish to fetch a revision which isn't on any branch, specify <tt>nobranch=1</tt> in the URL.<br />
Changes applicable to the "dizzy" release and later:<br />
* '''Handle B != S in autotools recipes''': if the software being built is capable of building in a separate directory to the source, you don't need to do anything. Otherwise, either patch it so that it does, or inherit <tt>autotools-brokensep</tt> instead of <tt>autotools</tt>.<br />
* '''Handle the --foreign option in autotools recipes''': some older autotooled software does not follow the GNU standards in distributing certain files such as ChangeLog, AUTHORS, etc. Most upstream software packages that need to already tell automake to enable foreign mode themselves, but some recipes will need patches for this change. You can easily make the change by patching configure.ac so that it passes "foreign" to AM_INIT_AUTOMAKE() - see [http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2 this example].<br />
* '''Use pkg-config instead of standalone configuration scripts''': configuration scripts such as xml2-config, pcre-config, freetype-config etc. were being mangled in the past in order to have them return the correct paths within the sysroot, but this is no longer being done - instead of running these scripts, use pkg-config which has proper sysroot support. These scripts will now return an exit code and an invalid option for those calling scripts that don't pay attention to the exit code.<br />
* '''Do not stage the same files in multiple recipes''': overwriting files in the sysroot now triggers an error instead of a warning. Recipes should not be staging files to the sysroot (as a result of installing files within do_install) that are also staged by other recipes; allowing this in the past led to nasty situations that were often difficult to debug.<br />
Changes applicable to the "fido" release and later:<br />
* '''Set CLEANBROKEN if make clean doesn't work''': if a Makefile exists, do_configure runs <tt>make clean</tt> when re-executing in order to clean out generated files. If this isn't expected to work for the software a recipe builds, set CLEANBROKEN = "1" in the recipe.<br />
<br />
=== Best practices ===<br />
<br />
The following practices are required for patch submission to layers such as OE-Core and meta-oe, and recommended for recipes in your own layers:<br />
<br />
* Machine and distro-specific overrides should be removed from recipes for generic layers (especially meta-oe and OE-Core). These can be moved to bbappends in the appropriate machine / distro layer respectively. (Note however that architecture-specific overrides are allowed if necessary.)<br />
* Fix any QA issues reported during packaging.<br />
* Avoid hardcoding system paths such as /etc, /usr/bin, /usr/share and so on. Instead the values of the appropriate variables should be used (e.g. ${libdir}, ${bindir}, ${datadir} ...). If there are scripts or other files provided by the application such as initscripts you can fix the paths in them within do_install using sed. See bitbake.conf for a list of standard path variables and their default values (which may be - and often are - overridden by the distro configuration).<br />
* Initscripts should have the standard [http://wiki.debian.org/LSBInitScripts LSB header] (especially if no systemd unit file is being provided, since systemd relies upon information in the header when handling an initscript.)<br />
* In-tree patches to be applied to the source should have a proper header explaining what the patch does, a valid Signed-off-by, an [http://lists.yoctoproject.org/pipermail/yocto/2011-April/003446.html Upstream-Status] indicator.<br />
* Reset PR to "r0" by removing it. PR is still used, but new recipes being migrated should start again from r0 (the default value if not specified), and if you need it to increment on recipe changes you should use the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service PR service].<br />
* Use ${BPN} instead of ${PN} where you just want the recipe name without any prefixes/suffixes added by things like multilib and nativesdk (e.g. installation paths)<br />
* Use the <code>useradd</code> class instead of running useradd/groupadd directly to add users/groups.<br />
* NATIVE_INSTALL_WORKS for native recipes is no longer used and should be removed.<br />
* PRIORITY is no longer used and should be removed.<br />
* ENTERPRISE_DISTRO is no longer used. We now have LICENSE_FLAGS to support the uses that ENTERPRISE_DISTRO covered - see the [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes Yocto Project Reference Manual].<br />
* Use d.getVar()/d.setVar() instead of bb.data.getVar()/bb.data.setVar() in python functions. The latter will still work, but are deprecated.<br />
* For class overrides (other than multilib) use class-xxx instead of virtclass-xxx. The latter will still work, but is deprecated.<br />
* "[http://mywiki.wooledge.org/Bashism Bashisms]" in shell scripts (particularly those that will be executed on the host) should be avoided. This allows compatibility with alternative shells e.g. Ubuntu's default (dash).<br />
* Pre/postinstall scripts (pkg_preinst / pkg_postinst) should ideally be written such that they can run on the host during do_rootfs instead of only on the target. In practice this means that you need to use ${D} before all paths, and anything that is architecture-specific will need to be run under qemu (although the latter is not very common).<br />
* For readability, the variables/functions within a recipe should be ordered in the same order in which they are used - i.e. "meta" information above (DESCRIPTION, SUMMARY, DEPENDS, LICENSE etc.), followed by information needed for do_fetch (SRC_URI, etc.), then anything for do_patch, do_compile, do_install, and then do_package (e.g. PACKAGES, FILES, RDEPENDS, RRECOMMENDS...).<br />
* Shell functions in OE-Core are using tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell task, python tasks and for indentation of multi-line variables)<br />
<br />
== Machine configuration ==<br />
<br />
The following section lists changes applicable to machine configuration files (conf/machine/*).<br />
<br />
* '''Ensure you are using the correct tune files''': the tune files in OE-Core have been reorganised and updated; see conf/machine/include/ and check that you are including the appropriate file(s).<br />
* '''Remove variable settings already handled by the tune files''': check if any values you are setting are already set by the tune files; if they are, you don't need to set them again. Of course if you wish to override one of the settings for your machine that is fine.<br />
* '''Update to a newer Linux kernel''': current versions of kernel-sensitive userspace components (e.g. udev) expect a modern kernel; older kernels may not allow the system to boot. If you're not able to do this you may need to provide downgraded versions of these components that are compatible with the kernel you are building. Note that all support for the 2.4 kernel has been removed.<br />
* '''Check MACHINE_FEATURES value''': check the list you are setting against the currently available features (see [http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine here], or you can do "git grep MACHINE_FEATURES" in the layers containing recipes you are using.) In particular, the "kernel26" feature can be removed as we no longer support the 2.4 kernel which necessitated having a flag to say the machine is using a 2.6 kernel instead.<br />
* '''Remove unused variables''': the following variables are no longer used:<br />
** KERNEL<br />
** PCMCIA_MANAGER<br />
** MACHINE_KERNEL_VERSION<br />
** ROOT_FLASH_SIZE<br />
* '''Use =+ to set IMAGE_FSTYPES''': this interacts best when adding/overriding from other configuration files.<br />
* '''Remove MACHINE_KERNEL_PR''': this is no longer needed when BB_SIGNATURE_HANDLER is OEBasicHash (now the default) and the PR service is being used (in the dylan branch and newer); any changes to underlying metadata or dependencies of the kernel will automatically rebuild the kernel so there is no need to force it by hand.<br />
<br />
== Distro configuration ==<br />
<br />
* '''Build on top of defaultsetup.conf''': OE-Core provides a very basic distro config in meta/conf/distro/defaultsetup.conf which is included automatically by bitbake.conf, thus you only need to include bits of this config file that you want to change.<br />
* '''Replace references to glibc with eglibc''': set TCMODE and TCLIBC to select the toolchain mode and libc variant if you are not using the defaults.<br />
* '''Check DISTRO_FEATURES value''': if you are setting DISTRO_FEATURES, check the list you have against the currently available features (look at the default value in conf/distro/include/default-distrovars.inc in OE-Core; you can also do "git grep DISTRO_FEATURES" in the layers containing recipes you are using.)<br />
* '''Avoid setting machine configuration variables''': machine configuration should almost always be handled in each machine configuration file and not in the distro configuration.<br />
* '''Update blacklisting''': Replace ANGSTROM_BLACKLIST_pn-somerecipe = "message" with BLACKLIST[somerecipe] = "message" (assuming the recipe still exists and the blacklisting is still needed)<br />
* '''Replace references to ONLINE_PACKAGE_MANAGEMENT''': this variable has been replaced by checking for package-management within IMAGE_FEATURES.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OpenEmbedded-Core&diff=7855OpenEmbedded-Core2015-08-20T08:42:51Z<p>PaulEggleton: DISTRO has been set to "nodistro" rather than "" by default for a while now</p>
<hr />
<div>== OpenEmbedded-Core ==<br />
<br />
<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev --><br />
<br />
=== Introduction ===<br />
<br />
Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.<br />
<br />
The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") grew organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout was very difficult, and near to impossible to support commercially. Like many other OE forks that were created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.<br />
<br />
OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.<br />
<br />
=== Differences to OE-classic ===<br />
<br />
The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.<br />
<br />
Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.<br />
<br />
Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.<br />
<br />
=== OpenEmbedded-Core scope ===<br />
<br />
The scope of OE-Core itself is as follows:<br />
<br />
* Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)<br />
* Only QEMU emulated machines<br />
* Distro-less (DISTRO = "nodistro" and default values are used)<br />
* Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)<br />
* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core<br />
* Attempt to keep only one version of each recipe except for GPLv2 / v3 versions<br />
<br />
Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.<br />
<br />
=== meta-openembedded ===<br />
<br />
For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://cgit.openembedded.org/cgit.cgi/meta-openembedded meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.<br />
<br />
== Getting Started ==<br />
<br />
See [[Getting started]].<br />
<br />
== Available Layers ==<br />
<br />
OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].<br />
<br />
== Creating Layers ==<br />
<br />
See [[Creating a new Layer]].<br />
<br />
== Required changes for existing metadata ==<br />
<br />
See [[Migrating metadata to OE-Core]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Mailing_lists&diff=7733Mailing lists2015-04-30T13:32:24Z<p>PaulEggleton: Put OE-core list at top, remove OE-Classic mention, make items uniform</p>
<hr />
<div>{| class="wikitable" border="2"<br />
|| '''Email address of list''' || '''Purpose''' || '''Subscribe''' || '''Advanced archive'''* || '''Simple archive'''<br />
|-<br />
||openembedded-core@lists.openembedded.org || General discussion & [[How_to_submit_a_patch_to_OpenEmbedded|patch submission]] for [[OpenEmbedded-Core|OE-Core]] || [http://lists.openembedded.org/mailman/listinfo/openembedded-core subscribe] || [http://thread.gmane.org/gmane.comp.handhelds.openembedded.core archive] || [http://lists.openembedded.org/pipermail/openembedded-core/ archive]<br />
|-<br />
||openembedded-devel@lists.openembedded.org || General discussion & patch submission for other meta layers || [http://lists.openembedded.org/mailman/listinfo/openembedded-devel subscribe] || [http://thread.gmane.org/gmane.comp.handhelds.openembedded archive] || [http://lists.openembedded.org/pipermail/openembedded-devel/ archive]<br />
|-<br />
||openembedded-commits@lists.openembedded.org || Git commits || [http://lists.openembedded.org/mailman/listinfo/openembedded-commits subscribe] || [http://thread.gmane.org/gmane.comp.handhelds.openembedded.scm archive] || [http://lists.openembedded.org/pipermail/openembedded-commits/ archive]<br />
|-<br />
||bitbake-devel@lists.openembedded.org || Bitbake developers mailing list || [http://lists.openembedded.org/mailman/listinfo/bitbake-devel subscribe] || || [http://lists.openembedded.org/pipermail/bitbake-devel/ archive]<br />
|-<br />
||<strike>openembedded-users@lists.openembedded.org</strike>|| User discussion (defunct - use openembedded-devel) || || [http://thread.gmane.org/gmane.comp.handhelds.openembedded.user archive] || [http://lists.openembedded.org/pipermail/openembedded-users/ archive]<br />
|-<br />
||<strike>openembedded-issues@lists.openembedded.org</strike>|| Bug tracker status updates (defunct) || || || [http://lists.openembedded.org/pipermail/openembedded-issues/ archive]<br />
|-<br />
||<strike>openembedded-stablebranch@lists.openembedded.org</strike> || Discussion about the stable branch (defunct) || || [http://thread.gmane.org/gmane.comp.handhelds.openembedded.stable archive] ||<br />
|}<br />
<br />
<nowiki><br />
* denotes a searchable archive including an interactive tree view for threads (might not work with all types of browsers)<br />
</nowiki><br />
<br />
[[Category:Community]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=How_to_submit_a_patch_to_OpenEmbedded&diff=7731How to submit a patch to OpenEmbedded2015-04-30T13:29:12Z<p>PaulEggleton: Minor grammar fix</p>
<hr />
<div>OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.<br />
<br />
== Finding the right place for your patch ==<br />
<br />
OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. For further information specific to the layer you're working on, please see the README file in the layer.<br />
<br />
New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].<br />
<br />
== A task-oriented guide to creating a patch ==<br />
<br />
Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.<br />
<br />
=== Set up git ===<br />
<br />
Properly configuring git (using tekkub@gmail.com as an example user)<br />
<br />
On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)<br />
<br />
sudo aptitude install git-core git-email<br />
<br />
These are important to the commit meta-data<br />
<br />
git config --global user.name "Tekkub"<br />
git config --global user.email "tekkub@gmail.com"<br />
<br />
Any Google Apps account<br />
<br />
git config --global sendemail.smtpserver smtp.gmail.com<br />
git config --global sendemail.smtpserverport 587<br />
git config --global sendemail.smtpencryption tls<br />
git config --global sendemail.smtpuser tekkupl@gmail.com<br />
<br />
You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.<br />
<br />
=== Subscribe to the mailing list ===<br />
<br />
You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.<br />
<br />
=== Committing your patch ===<br />
<br />
Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code. <br />
<br />
cd oe-core/ # or whereever you keep your clone of the repo<br />
git add meta/recipes-devtools/flex<br />
git commit -s # don't use the -m option but include my signature<br />
<br />
flex: backport Debian patches to fix generated code warnings<br />
<br />
The generated parser had warnings regarding signess and return check<br />
which makes Linux Kernel's perf tool from 3.4 release to fail without<br />
those patches.<br />
<br />
All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].<br />
<br />
Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.<br />
<br />
=== Sending patches ===<br />
<br />
There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.<br />
<br />
==== Sending using git-send-email ====<br />
<br />
To send just the top commit on your current branch (substitute mailing list address as appropriate):<br />
<br />
git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1<br />
<br />
For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.<br />
<br />
Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:<br />
--subject-prefix="meta-oe][PATCH"<br />
<br />
Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)<br />
<br />
==== Sending via a pull request ====<br />
<br />
Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:<br />
<br />
# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.<br />
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.<br />
# Push the branch to the remote.<br />
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.<br />
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.<br />
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.<br />
<br />
== Community review ==<br />
<br />
Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/<br />
<br />
If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration.<br />
<br />
If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback.<br />
<br />
== Appendix ==<br />
<br />
=== Steps for people which don't have SMTP access for git === <br />
<br />
Patches should not be sent as attachment but inline.<br />
<br />
If you do not have SMTP access to your email account you have two options:<br />
<br />
1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)<br />
<br />
2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,<br />
wrap lines etc etc).<br />
<br />
A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.<br />
<br />
=== Streamlining git-send-email with configuration ===<br />
<br />
Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.<br />
<br />
<ul><br />
<li>Always confirm sending (for all repositories):<br />
<pre>git config --global sendemail.confirm always</pre></li><br />
<li>Set send-to email address for the repository (don't forget to specify the right address!):<br />
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre><br />
</li><br />
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):<br />
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre><br />
</li><br />
</ul><br />
<br />
[[Category:FAQ]]<br />
[[Category:User]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OE-Core_Standalone_Setup&diff=7713OE-Core Standalone Setup2015-04-23T14:37:13Z<p>PaulEggleton: Update for 1.8 release</p>
<hr />
<div>[[OpenEmbedded-Core]] is a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded-derived systems and forms the basis of the new structure for OpenEmbedded. See the [[OpenEmbedded-Core]] page for more information.<br />
<br />
== Getting started ==<br />
<br />
1) Clone the repositories for OE-Core (the core metadata) and BitBake (the build tool), checking out the latest stable branches of each one in turn:<br />
<pre><br />
git clone git://git.openembedded.org/openembedded-core oe-core<br />
cd oe-core<br />
git clone git://git.openembedded.org/bitbake bitbake<br />
</pre><br />
<br />
2) Check out the latest stable branches of both OE-Core and BitBake:<br />
<pre><br />
git checkout fido<br />
cd bitbake<br />
git checkout 1.26<br />
cd ..<br />
</pre><br />
<br />
3) Set up the environment and build directory:<br />
<pre><br />
source ./oe-init-build-env [<build directory>]<br />
</pre><br />
<br />
The optional build directory may be specified, otherwise it is assumed you want to use the directory named "build".<br />
<br />
4) First time configuration<br />
<br />
The first time you run oe-init-build-env, it will setup the directory for you and create the configuration files conf/bblayers.conf and conf/local.conf. You should at least review the settings within the conf/local.conf file.<br />
<br />
5) Build something:<br />
<pre><br />
bitbake <target><br />
</pre><br />
<br />
A good simple place to start is <tt>bitbake core-image-minimal</tt>. This will do basic system sanity checks and build a small but practical image. If your system needs additional software installed, or other environment settings it will tell you what is needed.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OpenEmbedded-Core&diff=7711OpenEmbedded-Core2015-04-22T17:55:04Z<p>PaulEggleton: More updates</p>
<hr />
<div>== OpenEmbedded-Core ==<br />
<br />
<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev --><br />
<br />
=== Introduction ===<br />
<br />
Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.<br />
<br />
The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") grew organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout was very difficult, and near to impossible to support commercially. Like many other OE forks that were created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.<br />
<br />
OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.<br />
<br />
=== Differences to OE-classic ===<br />
<br />
The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.<br />
<br />
Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.<br />
<br />
Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.<br />
<br />
=== OpenEmbedded-Core scope ===<br />
<br />
The scope of OE-Core itself is as follows:<br />
<br />
* Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)<br />
* Only QEMU emulated machines<br />
* Distro-less (DISTRO = "" and default values are used)<br />
* Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)<br />
* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core<br />
* Attempt to keep only one version of each recipe except for GPLv2 / v3 versions<br />
<br />
Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.<br />
<br />
=== meta-openembedded ===<br />
<br />
For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://cgit.openembedded.org/cgit.cgi/meta-openembedded meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.<br />
<br />
== Getting Started ==<br />
<br />
See [[Getting started]].<br />
<br />
== Available Layers ==<br />
<br />
OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].<br />
<br />
== Creating Layers ==<br />
<br />
See [[Creating a new Layer]].<br />
<br />
== Required changes for existing metadata ==<br />
<br />
See [[Migrating metadata to OE-Core]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OpenEmbedded-Core&diff=7709OpenEmbedded-Core2015-04-22T17:51:48Z<p>PaulEggleton: More updates</p>
<hr />
<div>== OpenEmbedded-Core ==<br />
<br />
<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev --><br />
<br />
=== Introduction ===<br />
<br />
Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.<br />
<br />
The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") has grown organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout is very difficult, and near to impossible to support commercially. Like many other OE forks that have been created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.<br />
<br />
OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.<br />
<br />
=== Differences to OE-classic ===<br />
<br />
The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.<br />
<br />
Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.<br />
<br />
Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.<br />
<br />
=== OpenEmbedded-Core scope ===<br />
<br />
The scope of OE-Core itself is as follows:<br />
<br />
* Support for the major architectures: ARM, x86, PowerPC, MIPS (and 64-bit variants of all of these)<br />
* Only QEMU emulated machines<br />
* Distro-less (DISTRO = "" and default values are used)<br />
* Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)<br />
* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core<br />
* Attempt to keep only one version of each recipe except for GPLv2 / v3 versions<br />
<br />
Anything not in OE-Core can easily be provided by additional layers on top; other layers can also be used to e.g. support older recipe versions that have been removed from OE-Core.<br />
<br />
=== meta-openembedded ===<br />
<br />
For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://cgit.openembedded.org/cgit.cgi/meta-openembedded meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.<br />
<br />
== Getting Started ==<br />
<br />
See [[Getting started]].<br />
<br />
== Available Layers ==<br />
<br />
OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].<br />
<br />
== Creating Layers ==<br />
<br />
See [[Creating a new Layer]].<br />
<br />
== Required changes for existing metadata ==<br />
<br />
See [[Migrating metadata to OE-Core]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OpenEmbedded-Core&diff=7707OpenEmbedded-Core2015-04-22T17:48:44Z<p>PaulEggleton: Update to be a bit more current</p>
<hr />
<div>== OpenEmbedded-Core ==<br />
<br />
<!-- keywords: oe core OE-Core meta-oe meta-openembedded classic oe-classic dev oe-dev --><br />
<br />
=== Introduction ===<br />
<br />
Current versions of OpenEmbedded are based on OpenEmbedded-Core (OE-Core). OE-Core has evolved from collaboration efforts with the Yocto Project as well as a recognition that the model previously being used in OpenEmbedded was unsustainable.<br />
<br />
The original OpenEmbedded repository (also known as "OE-Classic" or "oe-dev") has grown organically over the years to more than 7500 recipes, covering approximately 300 machines and 20 distros. Trying to maintain this amount of metadata with machine and distro overrides scattered throughout is very difficult, and near to impossible to support commercially. Like many other OE forks that have been created to solve the same kinds of issues, Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation. OE-Core was split out from Poky in 2011 to allow collaboration around a relatively small and easily supportable base, with real machines, distros and other items removed - more on this below.<br />
<br />
OE-Classic is no longer maintained. New efforts should be built on top of OE-Core. The new OE layer ecosystem provides full support for building typical embedded Linux systems, support for many target machines and additional software packages. There are still some recipes and machine support that have yet to be ported over from OE classic, however recipes and configuration can be easily brought over, tidied up and placed into the appropriate layer over time.<br />
<br />
=== Differences to OE-classic ===<br />
<br />
The most significant change is that metadata is now split into multiple layers rather than being in one repository. OE-Core sits at the bottom, and machine / application / distro layers are added on top. Users are free to select support for whatever applications or platforms they wish in their configuration simply by including the appropriate layer in their bblayers.conf file.<br />
<br />
Machine and distro-specific overrides should no longer be spread over the entire set of recipes - instead they should be concentrated in appropriate machine support layers (often referred to as BSP (Board Support Package) layers) and distro layers respectively. BitBake's .bbappend feature allows overriding almost any element of a recipe without too much duplication across multiple layers.<br />
<br />
Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic - instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer. Other layers may choose to use either the push or pull model for contributions.<br />
<br />
=== OpenEmbedded-Core scope ===<br />
<br />
The scope of OE-Core is as follows:<br />
<br />
* Support for five architectures: ARM, x86, x86-64, PowerPC and MIPS<br />
* Only QEMU emulated machines<br />
* Distro-less (DISTRO = "" and default values are used)<br />
* Only one X-based GUI environment (Sato) intended for testing purposes. (This may be substituted out in future if a suitable replacement testing framework can be created.)<br />
* Only the recipes that are needed by almost everyone, needed for LSB support (optional) or are needed for testing other parts of OE-Core<br />
* Attempt to keep only one version of each recipe except for GPLv2 / v3 versions<br />
<br />
Anything not in OE-Core can easily be provided by another layer; other layers can also be used to support older versions that have been removed from OE-Core.<br />
<br />
=== meta-openembedded ===<br />
<br />
For items shared amongst multiple layers that do not fit into OE-Core or any other existing layer, there is the meta-oe layer. This exists in a repository, also called [http://cgit.openembedded.org/cgit.cgi/meta-openembedded meta-openembedded], which contains a number of other more focused layers (meta-efl, meta-gnome, etc.). This layer will need to be managed carefully over time to avoid it turning into just a newer version of OE-classic.<br />
<br />
== Getting Started ==<br />
<br />
See [[Getting started]].<br />
<br />
== Available Layers ==<br />
<br />
OpenEmbedded maintains an list of layers that can be used with OE-Core - see the [http://layers.openembedded.org layer index].<br />
<br />
== Creating Layers ==<br />
<br />
See [[Creating a new Layer]].<br />
<br />
== Required changes for existing metadata ==<br />
<br />
See [[Migrating metadata to OE-Core]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Which_devices_does_OE_support&diff=7657Which devices does OE support2015-03-20T09:16:41Z<p>PaulEggleton: Created page with "The structure of OpenEmbedded is such that support for machines is added through additional layers (BSP layers) on top of OpenEmbedded-Core. Out of the box, OE-Core supports o..."</p>
<hr />
<div>The structure of OpenEmbedded is such that support for machines is added through additional layers (BSP layers) on top of OpenEmbedded-Core. Out of the box, OE-Core supports only emulated machines, but there are a number of BSP layers adding support for various machines.<br />
<br />
To see a list of the available BSP layers, see the [http://layers.openembedded.org/layerindex/branch/master/machines/ layer index] (you can either search by name or click Search with no keyword to browse the list).<br />
<br />
[[Category:Machine]]<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OEDAM_2015&diff=7655OEDAM 20152015-03-20T09:11:18Z<p>PaulEggleton: Add security processes to agenda</p>
<hr />
<div><br />
== Location and Time ==<br />
<br />
March 27-28 (after ELC and Yocto Project Developer Day)<br />
<br />
2315 North 1st Street, San Jose, CA 95131 <br />
<br />
https://goo.gl/maps/1pRGR<br />
<br />
Now that people are already claiming to attend by Google Hangout, I will announce our intention to also webcast via Google Hangout ;)<br />
<br />
== Attendees ==<br />
<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Armin Kuster (Armpit)<br />
* Martin Jansa (JaMa) - 50%<br />
* Michael Halstead (halstead) - Friday only<br />
* Jeff Osier-Mixon (jefro)<br />
* Paul Eggleton (bluelightning)<br />
* Steve Arnold (nerdboy/mr_science)<br />
* Stephanie Lockwood-Childs (wormo/sjl) - via hangout<br />
* Ron Lockwood-Childs (speedy1) - via hangout<br />
* Herb Kuta<br />
* Tim Orling (moto-timo)<br />
* Sean Hudson (darknighte)<br />
* Bruce Ashfield (zedd) - probably<br />
* Mark Hatle (fray) - probably<br />
* Sona Sarmadi<br />
* Changhyeok Bae<br />
<br />
== Agenda Items ==<br />
<br />
* Progress on items identified during OEDAM 2014<br />
* Development cycle<br />
* Patch review tools<br />
* Tests<br />
* Removing the oe-core and meta-oe repos on github. These repos are now called openembedded-core and meta-openembedded/<br />
* People still use OE-classic from time to time. Should we remove the repo?<br />
* Security processes<br />
* Community Development / Team Building (please add more examples/ideas... almond flour cake is always good...)<br />
** Intro / crash course events<br />
** Coordinated bug day sprints<br />
** Other group/meetup activities</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OEDAM_2015&diff=7651OEDAM 20152015-03-16T12:20:23Z<p>PaulEggleton: Add Sona at her request</p>
<hr />
<div><br />
== Location and Time ==<br />
<br />
March 27-28 (after ELC and Yocto Project Developer Day)<br />
<br />
2315 North 1st Street, San Jose, CA 95131 <br />
<br />
https://goo.gl/maps/1pRGR<br />
<br />
Now that people are already claiming to attend by Google Hangout, I will announce our intention to also webcast via Google Hangout ;)<br />
<br />
== Attendees ==<br />
<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Armin Kuster (Armpit)<br />
* Martin Jansa (JaMa) - 50%<br />
* Michael Halstead (halstead) - Friday only<br />
* Jeff Osier-Mixon (jefro)<br />
* Paul Eggleton (bluelightning)<br />
* Steve Arnold (nerdboy/mr_science)<br />
* Stephanie Lockwood-Childs (wormo/sjl) - via hangout<br />
* Ron Lockwood-Childs (speedy1) - via hangout<br />
* Herb Kuta<br />
* Tim Orling (moto-timo)<br />
* Sean Hudson (darknighte)<br />
* Bruce Ashfield (zedd) - probably<br />
* Mark Hatle (fray) - probably<br />
* Sona Sarmadi<br />
<br />
== Agenda Items ==<br />
<br />
* Progress on items identified during OEDAM 2014<br />
* Development cycle<br />
* Patch review tools<br />
* Tests<br />
* Removing the oe-core and meta-oe repos on github. These repos are now called openembedded-core and meta-openembedded/<br />
* People still use OE-classic from time to time. Should we remove the repo?<br />
* Community Development / Team Building (please add more examples/ideas... almond flour cake is always good...)<br />
** Intro / crash course events<br />
** Coordinated bug day sprints<br />
** Other group/meetup activities</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OEDAM_2015&diff=7649OEDAM 20152015-03-16T12:19:36Z<p>PaulEggleton: Add some agenda items, clarify one existing one</p>
<hr />
<div><br />
== Location and Time ==<br />
<br />
March 27-28 (after ELC and Yocto Project Developer Day)<br />
<br />
2315 North 1st Street, San Jose, CA 95131 <br />
<br />
https://goo.gl/maps/1pRGR<br />
<br />
Now that people are already claiming to attend by Google Hangout, I will announce our intention to also webcast via Google Hangout ;)<br />
<br />
== Attendees ==<br />
<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Armin Kuster (Armpit)<br />
* Martin Jansa (JaMa) - 50%<br />
* Michael Halstead (halstead) - Friday only<br />
* Jeff Osier-Mixon (jefro)<br />
* Paul Eggleton (bluelightning)<br />
* Steve Arnold (nerdboy/mr_science)<br />
* Stephanie Lockwood-Childs (wormo/sjl) - via hangout<br />
* Ron Lockwood-Childs (speedy1) - via hangout<br />
* Herb Kuta<br />
* Tim Orling (moto-timo)<br />
* Sean Hudson (darknighte)<br />
* Bruce Ashfield (zedd) - probably<br />
* Mark Hatle (fray) - probably<br />
<br />
== Agenda Items ==<br />
<br />
* Progress on items identified during OEDAM 2014<br />
* Development cycle<br />
* Patch review tools<br />
* Tests<br />
* Removing the oe-core and meta-oe repos on github. These repos are now called openembedded-core and meta-openembedded/<br />
* People still use OE-classic from time to time. Should we remove the repo?<br />
* Community Development / Team Building (please add more examples/ideas... almond flour cake is always good...)<br />
** Intro / crash course events<br />
** Coordinated bug day sprints<br />
** Other group/meetup activities</div>PaulEggletonhttps://www.openembedded.org/index.php?title=OEDAM_2015&diff=7603OEDAM 20152015-02-25T00:04:08Z<p>PaulEggleton: Add myself and some agenda items</p>
<hr />
<div><br />
== Location and Time ==<br />
<br />
March 27-28 (after ELC and Yocto Project Developer Day)<br />
<br />
2315 North 1st Street, San Jose, CA 95131 <br />
<br />
https://goo.gl/maps/1pRGR<br />
<br />
== Attendees ==<br />
<br />
* Philip Balister (Crofton)<br />
* Denys Dmytriyenko (denix)<br />
* Armin Kuster (Armpit)<br />
* Martin Jansa (JaMa) - 50%<br />
* Michael Halstead (halstead) - Friday only<br />
* Jeff Osier-Mixon (jefro)<br />
* Paul Eggleton (bluelightning)<br />
<br />
== Agenda Items ==<br />
<br />
* Progress on items identified during OEDAM 2014<br />
* Development cycle</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Layers_FAQ&diff=7597Layers FAQ2015-02-19T11:28:57Z<p>PaulEggleton: /* Can I overlay/append an inc file from another layer in my layer? */ extend possible solutions</p>
<hr />
<div>== General layer questions ==<br />
<br />
=== What is a layer? ===<br />
<br />
In OpenEmbedded, a layer is just a collection of recipes and/or configuration that can be used on top of [[OpenEmbedded-Core|OE-Core]]. Typically each layer is organised around a specific theme, e.g. adding recipes for building web browser software.<br />
<br />
=== Where do I find existing layers? ===<br />
<br />
See [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I make use of a layer? ===<br />
<br />
Clone / extract it somewhere (typically next to or within your OE-Core base directory, but the exact location is not critical) and then add the full path to it to the value of <code>BBLAYERS</code> in your <code>conf/bblayers.conf</code> in your build directory. Note that some layers depend on other layers; it is recommended that you consult the README file within the layer if one is included. Additionally, note that some layer repositories contain multiple layers - in this case there will be subdirectories in the repository corresponding to each layer.<br />
<br />
=== How do I create a new layer? ===<br />
<br />
See [[Creating a new Layer]].<br />
<br />
=== Is there any other documentation on layers? ===<br />
<br />
Yes - the Yocto Project provides a set of manuals that cover layers in some detail. <br />
* For general information see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers "Understanding and Creating Layers"] in the Yocto Project Development Manual.<br />
* For creating a layer for supporting a machine, see the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project BSP Developer's Guide].<br />
<br />
=== How do I include an inc file from another layer? ===<br />
<br />
You need to specify the path from the base of the other layer to where the inc file is located; e.g:<br />
<br />
require recipes-graphics/xorg-driver/xorg-driver-input.inc<br />
<br />
=== I've bbappended a recipe in my layer to replace a file with my own version but it's not being picked up - why not? ===<br />
<br />
Assuming your bbappend is extending FILESEXTRAPATHS (which it must do), the probable cause is that the directory you have added to FILESEXTRAPATHS and the directory in which you have placed the file aren't the same. For example, if you have the following in your bbappend:<br />
<br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
<br />
then your file must be placed in a directory named ${PN} - i.e. if your recipe file is called "magicrecipe_1.0.bb" then the directory would need to be named "magicrecipe". If you prefer, you can adjust the directory name added to FILESEXTRAPATHS as shown above to something else.<br />
<br />
=== I've added a layer to my bblayers.conf and now the system is building an older version of some recipe - why? ===<br />
<br />
The added layer likely contains an older version of the recipe and has a higher layer priority than the layer that contains the existing newer recipe. You can use PREFERRED_VERSION_recipename in your distro or local configuration to override the default selection and select the newer recipe.<br />
<br />
=== Can I overlay/append an inc file from another layer in my layer? ===<br />
<br />
There is no mechanism for this, no - inc files aren't handled in the same manner as .bb and .bbappend files. The possible solutions if you find you need to do this:<br />
* bbappend each recipe that includes the inc file (and you can use % as a wildcard, for example <code>meta-yocto/recipes-core/busybox/busybox_%.bbappend</code>)<br />
* Get an appropriate fix into the inc file itself - which may be adding a variable so that you can select the behaviour you want externally<br />
<br />
=== I've just created a new layer and would like to publish it for the community. What should I do? ===<br />
<br />
There are a few important steps you should take in order to publish a layer for the community:<br />
<br />
# '''Existing layers:''' Ideally, ensure your layer does not overlap with other layers. If there must be an overlap and it is not practical to resolve it with the maintainer of the existing layer(s), document what the overlap is and why it is there.<br />
# '''Maintainer:''' If you are publishing the layer as a repository, ensure there is a commitment from at least one person to be the maintainer for the layer. The maintainer's role is to accept, review and (if satisfactory) merge patches from the community.<br />
# '''README:''' Ensure the layer has a README text file in the root which describes briefly what the layer is for, how to use it (if there are any special instructions), the other layers it depends upon, who it is maintained by, and most importantly where and how people should submit patches for it.<br />
# '''Publish:''' Publish the layer in a place where it can be easily accessed. [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] and [http://cgit.openembedded.org/cgit.cgi/ openembedded.org] can provide hosting, otherwise it is common to host layers on sites such as [http://github.org github] or [http://gitorious.org gitorious].<br />
# '''Index:''' Submit the layer to the [http://layers.openembedded.org OpenEmbedded layer index].<br />
# '''Announcement:''' Send an announcement to both of the following mailing lists telling people about the new layer:<br />
#* yocto@yoctoproject.org ([http://lists.yoctoproject.org/listinfo/yocto list info])<br />
#* openembedded-devel@lists.openembedded.org ([http://lists.linuxtogo.org/pipermail/openembedded-devel/ list info])<br />
<br />
== Layer index ==<br />
<br />
Questions relating to the layer index at [http://layers.openembedded.org layers.openembedded.org].<br />
<br />
=== How do I submit a new layer to the index? ===<br />
<br />
Click on "Submit layer" at the right of the top bar of the page, fill in the fields and then click on Submit.<br />
<br />
=== How can I edit the entry for my layer? ===<br />
<br />
If you're already listed as one of the maintainers for the layer, you can create an account using the same email address as the maintainer entry, and once you log in you'll automatically be able to edit the entry (using the "Edit layer" button in the top right hand corner of the layer details page for the layer).<br />
<br />
Alternatively if you're not able to do this, please send an email to paul.eggleton@linux.intel.com with your request.<br />
<br />
=== How do I choose the appropriate "layer type" for my layer? ===<br />
<br />
* Base: this is really only for oe-core and meta-oe, i.e. the base metadata for the build system.<br />
* Machine (BSP): if your layer primarily exists to add support for additional machine(s), use this type.<br />
* Software: if your layer primarily provides recipes for building additional software, use this type.<br />
* Distribution: if your layer primarily provides policy configuration for a distribution (conf/distro/*), which may include customised/additional recipes for the distribution, then choose this type.<br />
* Miscellaneous: if your layer doesn't fall into any other category you can choose this type; however there shouldn't be too many miscellaneous layers and it may be an indication that the purpose isn't well defined or that you should consider splitting the layer.<br />
<br />
=== I can't find a recipe I'm looking for. What can I do? ===<br />
<br />
Assuming you have searched the [http://layers.openembedded.org layer index] and haven't found anything, there are a few different avenues you can explore:<br />
<br />
* You may be able to find an older version of the recipe in the [http://cgit.openembedded.org/cgit.cgi/openembedded OE-Classic git repository] which you can bring up-to-date by following [[Migrating metadata to OE-Core]].<br />
* Try the <code>create-recipe</code> tool (scripts/create-recipe). It's not particularly sophisticated but at the very least it can give you a skeleton you can start from.<br />
* Create your own recipe - it's usually not too difficult. See [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Writing a New Recipe] in the Yocto Project Development Manual for some instructions and examples. You may also find it useful to start by copying another recipe.<br />
* Ask the community on the mailing list if anyone has/is planning on writing the recipe.<br />
<br />
=== How often is the recipe/machine information updated in the index? ===<br />
<br />
Currently, the update script runs once every three hours, fetching the latest version of every repository and updating the index for any changes.<br />
<br />
=== A recipe in my layer has blank values for some fields even though they are specified in the recipe, why is this? ===<br />
<br />
This is usually because the recipe failed to parse correctly when the layer index tried to process it. Note that the layer index update script will not set MACHINE or DISTRO to special values depending on the layer being parsed, so if parts of your layer fail to parse when these are set to other values then this will be a problem - ideally layers should still parse correctly no matter what the value of MACHINE or DISTRO is. Another cause of parse failures can be missing layer dependencies - ensure that all of the appropriate dependencies are listed against the layer in the index.<br />
<br />
[[Category:FAQ]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=How_to_submit_a_patch_to_OpenEmbedded&diff=7559How to submit a patch to OpenEmbedded2015-01-27T10:53:04Z<p>PaulEggleton: Turn "creating a new layer" into a link to the wiki page for that</p>
<hr />
<div>OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.<br />
<br />
== Finding the right place for your patch ==<br />
<br />
OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. Further information specific to the layer you're working on please see the README file in the layer.<br />
<br />
New recipes in particular should be added to the appropriate layer. See the [http://layers.openembedded.org layer index] for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider [[Creating a new Layer|creating a new layer]].<br />
<br />
== A task-oriented guide to creating a patch ==<br />
<br />
Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.<br />
<br />
=== Set up git ===<br />
<br />
Properly configuring git (using tekkub@gmail.com as an example user)<br />
<br />
On Debian / Ubuntu (Note: Fedora uses `yum` OpenSuse uses zypper or yast)<br />
<br />
sudo aptitude install git-core git-email<br />
<br />
These are important to the commit meta-data<br />
<br />
git config --global user.name "Tekkub"<br />
git config --global user.email "tekkub@gmail.com"<br />
<br />
Any Google Apps account<br />
<br />
git config --global sendemail.smtpserver smtp.gmail.com<br />
git config --global sendemail.smtpserverport 587<br />
git config --global sendemail.smtpencryption tls<br />
git config --global sendemail.smtpuser tekkupl@gmail.com<br />
<br />
You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.<br />
<br />
=== Subscribe to the mailing list ===<br />
<br />
You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is '''openembedded-core@lists.openembedded.org''' and for patches against meta-oe and many other layers the list is '''openembedded-devel@lists.openembedded.org'''. See [[Mailing lists]] for subscription and further details.<br />
<br />
=== Committing your patch ===<br />
<br />
Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code. <br />
<br />
cd oe-core/ # or whereever you keep your clone of the repo<br />
git add meta/recipes-devtools/flex<br />
git commit -s # don't use the -m option but include my signature<br />
<br />
flex: backport Debian patches to fix generated code warnings<br />
<br />
The generated parser had warnings regarding signess and return check<br />
which makes Linux Kernel's perf tool from 3.4 release to fail without<br />
those patches.<br />
<br />
All commit messages must include Signed-off-by (-s option to commit as above). For more guidelines on messages please see [[Commit Patch Message Guidelines]].<br />
<br />
Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.<br />
<br />
=== Sending patches ===<br />
<br />
There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.<br />
<br />
==== Sending using git-send-email ====<br />
<br />
To send just the top commit on your current branch (substitute mailing list address as appropriate):<br />
<br />
git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1<br />
<br />
For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.<br />
<br />
Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:<br />
--subject-prefix="meta-oe][PATCH"<br />
<br />
Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)<br />
<br />
==== Sending via a pull request ====<br />
<br />
Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the <code>create-pull-request</code> and <code>send-pull-request</code> scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:<br />
<br />
# Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding <code>-contrib</code> repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.<br />
# Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.<br />
# Push the branch to the remote.<br />
# Run <code>scripts/create-pull-request -u remote-name</code> (where <code>remote-name</code> is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add <code>-p "layername][PATCH"</code> replacing layername with the name of the layer so that it is clear which layer the patches are intended for.<br />
# The script will report that it has created a <code>pull-XXXXX</code> directory has been created. Edit the <code>pull-XXXXX/0000-cover-letter.patch</code> with your favourite text editor and change the title and top of the body as appropriate.<br />
# Run <code>scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org</code> (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add <code>-C maintainer@example.com</code>.<br />
<br />
== Community review ==<br />
<br />
Your patch will be sent to the mailing list and for some layers should be immediately visible on http://patches.openembedded.org/<br />
<br />
If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration.<br />
<br />
If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback.<br />
<br />
== Appendix ==<br />
<br />
=== Steps for people which don't have SMTP access for git === <br />
<br />
Patches should not be sent as attachment but inline.<br />
<br />
If you do not have SMTP access to your email account you have two options:<br />
<br />
1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)<br />
<br />
2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,<br />
wrap lines etc etc).<br />
<br />
A good mail client to do so is '''pine''' (or '''alpine''') or '''mutt'''. For more information refer to [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Documentation/email-clients.txt] in linux kernel sources.<br />
<br />
=== Streamlining git-send-email with configuration ===<br />
<br />
Don't want to have to remember to specify the right options when using git-send-email (or the pull request script)? You can actually set these in git's configuration and save yourself a lot of hassle.<br />
<br />
<ul><br />
<li>Always confirm sending (for all repositories):<br />
<pre>git config --global sendemail.confirm always</pre></li><br />
<li>Set send-to email address for the repository (don't forget to specify the right address!):<br />
<pre>git config --local sendemail.to openembedded-devel@lists.openembedded.org</pre><br />
</li><br />
<li>If the mailing list requires a subject prefix for the layer (only works when the repository only contains one layer; set layer name as appropriate):<br />
<pre>git config --local format.subjectprefix "meta-something][PATCH"</pre><br />
</li><br />
</ul><br />
<br />
[[Category:FAQ]]<br />
[[Category:User]]</div>PaulEggletonhttps://www.openembedded.org/index.php?title=NewsArchive&diff=7553NewsArchive2015-01-19T16:29:58Z<p>PaulEggleton: Move in old news</p>
<hr />
<div>'''Older News:'''<br />
* '''''2014-05-02:''''' OpenEmbedded will host [[OEDAM]] in Santa Clara. See you there!<br />
* '''''2014-01-06:''''' OpenEmbedded will have a stand at [[FOSDEM 2014]] in Brussels. See you there!<br />
* '''''2013-05-21:''''' OpenEmbedded will have a stand at [http://www.linuxtag.org/2013/ LinuxTag] in Berlin. See you there!<br />
* '''''2013-01-22:''''' OpenEmbedded will have a stand at Europe's largest free software conference - [[FOSDEM 2013]] in Brussels. See you there!<br />
* '''''2012-08-31:''''' Meta-webos added<br />
* '''''2012-07-16:''''' Meta-systemd moved from meta-oe <br />
* '''''2012-02-07:''''' OpenEmbedded attended europe's largest free software conference FOSDEM '12 in Brussels. Thanks for all the helpers and guests at our [http://www.flickr.com/photos/32615155@N00/6822271361/in/photostream booth]. See you soon at a F/OSS event near you!<br />
* '''''2011-04-18:''''' OpenEmbedded has Stand # 7.2b 112 @ [http://www.linuxtag.org LinuxTag] 11th to 14 May 2011 the Berlin Exhibition Grounds<br />
* '''''2011-03-02:''''' [http://www.linuxfoundation.org/news-media/announcements/2011/03/yocto-project-aligns-technology-openembedded-and-gains-corporate-co Yocto Project Aligns Technology with OpenEmbedded and Gains Corporate Collaborators]<br />
* '''''2011-03-01:''''' OpenEmbedded participates at this years CeBIT (March 1st-5th 2011) with a stand in the CeBIT OpenSource event. You'll find us in hall 2 as part of the larger linuxnewmedia booth along with other interesting open-source projects.<br />
* '''''2011-02-25:''''' OpenEmbedded has a stand at SCALE (Southern California Linux Expo) (February 25-27, 2011).<br />
* '''''2011-02-05:''''' OpenEmbedded at [http://fosdem.org FOSDEM'11] - We have a booth at Europe's finest F/OSS event. [[Fosdem 2011|See you in Brussels]]!<br />
* '''''2010-12-03:''''' OpenEmbedded 2010.12 [http://lists.linuxtogo.org/pipermail/openembedded-users/2010-December/001157.html released]<br />
* '''''2010-09-20:''''' [[Oedem/2010|OEDEM and eV General Assembly]]<br />
* '''''2010-06-09:''''' OpenEmbedded in Berlin! Meet us at our booth at [http://www.linuxtag.org LinuxTag 2010].<br />
* '''''2009-11-07:''''' [[Oedem/2009|Openembedded Developer Meeting 2009]] in Cambridge, UK<br />
* '''''2009-08-12:''''' Openembedded gains ability to create [http://docs.openembedded.org/usermanual/html/ch05s08.html Qt Embedded Linux SDK]<br />
* '''''2009-05-27:''''' Palm is using Openembedded to build Palm [http://developer.palm.com/ webOS]<br />
* '''''2009-05-27:''''' MontaVista is using OpenEmbedded in their [http://mvista.com/product_detail_mvl6.php MontaVista Linux 6 product]<br />
* '''''2009-03-31:''''' OpenEmbedded opens the stable/2009 [[Stable]] branch. Special procedure is applied to it which results in better support for our downstream users.<br />
* '''''2009-03-24:''''' [http://www.foss-aalborg.dk/ FOSS Aalborg] in Aalborg, Denmark, with a focus on embedded software. [[User:Mickey|Mickey]] gives a talk about OpenEmbedded.<br />
* '''''2009-03-06:''''' [http://www.alwaysinnovating.com Always Innovating] is using OE to build software for their Touch Book.<br />
* '''''2009-02-19:''''' [http://koansoftware.com/index_en.php KOAN Software] company [http://thread.gmane.org/gmane.comp.handhelds.openembedded/21188 announces] it's [http://kaeilos.com/ KaeilOS] distribution will join the OpenEmbedded project.<br />
* '''''2009-02-10:''''' OE has a new Logo -- Many thanks to [http://buglabs.com Bug Labs] who funded the logo development, and [http://mateozlatar.com/ Mateo Zlatar] for designing the logo.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=Template:Main_page/news&diff=7551Template:Main page/news2015-01-19T16:29:21Z<p>PaulEggleton: Add FOSDEM 2015, trim old news</p>
<hr />
<div><!-- Please use ISO date format (YYYY-MM-DD) --><br />
<!-- Please only three entries of recent news, if there are more, move the oldest one to the top of the NewsArchive page --><br />
<br />
'''Recent News:'''.<br />
* '''''2015-01-19:''''' OpenEmbedded will have a stand at [[FOSDEM 2015]] in Brussels. See you there!<br />
* '''''2014-10-14:''''' OpenEmbedded e.V. will have the annual meeting at the [[Dusseldorf,_2014 | ELCE]] in Düsseldorf<br />
<br />
See [[NewsArchive|News Archive]] for older news.</div>PaulEggletonhttps://www.openembedded.org/index.php?title=FOSDEM_2015&diff=7543FOSDEM 20152015-01-13T16:03:32Z<p>PaulEggleton: Add Fathi</p>
<hr />
<div>[[Category:Conferences]]<br />
<br />
= OpenEmbedded booth =<br />
== Manning ==<br />
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.<br />
<br />
* Paul Eggleton (Saturday, Sunday)<br />
* Philip Balister (Saturday)<br />
* Fathi Boudra (Sunday morning)<br />
<br />
== Tasks ==<br />
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.<br />
<br />
=== Event box ===<br />
<br />
* TBA<br />
<br />
=== Device Tags ===<br />
<br />
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.<br />
<br />
Volunteer: ?<br />
<br />
== Devices ==<br />
<br />
<br />
<br />
== Flyers and posters ==<br />
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.<br />
<br />
<br />
== Power extensions, adapters and other stand material ==<br />
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.<br />
* Presentation file for use on the display - Paul<br />
* Machine to connect for displaying the presentation (hopefully with the ability to show off Toaster) - Paul <br />
<br />
= General attendance =<br />
<br />
Attending FOSDEM 2015? Add your name to this page so that other developers can look out for you!<br />
<br />
* Paul Eggleton (bluelightning)<br />
* Philip Balister (Crofton)<br />
* Fathi Boudra (fabo)<br />
<br />
<br />
== Hotels ==<br />
<br />
Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.<br />
<br />
The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others. Recently, most of us stay at the Saint Nicolas due to the free breakfast and wifi.<br />
<br />
Scandic Grand Place.<br />
Rue d'Arenberg 18<br />
Close to beer event (300 m) and Central Station.<br />
Tram to Fosdem around the corner.<br />
Bus to FOSDEM<br />
Train + Bus to FOSDEM<br />
Free WiFi<br />
<br />
Saint Nicolas<br />
Hôtel Saint Nicolas *** <br />
Rue Marché aux Poulets 32 <br />
1000 Bruxelles Tél. +32/2-219.04.40 <br />
Fax +32/2-219.17.21 <br />
http://www.st-nicolas.be<br />
close to beer event, bus to Fosdem few minutes by walk from hotel.<br />
<br />
IBIS Brussels off Grand' Place<br />
Grasmarkt 100<br />
Rue du Marché aux Herbes 100<br />
1000 BRUSSELS<br />
<br />
Be Manos Hotel<br />
23-27, Square de LAviation<br />
1070 Brussels<br />
close to Midi station</div>PaulEggleton