Yocto Project - User contributions [en]

LTS Background

2020-08-09T12:09:01Z

Rpjday: /* Please see Realase and LTS process */

= This is background info only =
=Please see [https://wiki.yoctoproject.org/wiki/LTS Release and LTS process] =

In Fall 2019, the YP TSC put together a proposal about how the project could move forward with an LTS. The document is that proposal which is retained here as it answers some of the questions about how and why the project needs an LTS. There were amendments made after discussion and the main LTS is definitive in that regard, this page is here to provide some of the background.

= Yocto Project Long Term Support (LTS) plan proposal=

== Current Position ==
The Yocto Project is very much in favour of having some form of extended support for certain releases. The main reason this has not happened so has is due to resource constraints. We currently struggle to keep stable releases maintained for their 1-2 year lifespan, the project is therefore reluctant to committing to more work without resources to do it.

== Background ==
Yocto project releases cadence is every six months (twice a year), as covered on the wiki https://wiki.yoctoproject.org/wiki/Releases. Every release consists of:

* Major component upgrades
** Includes ABI/API changes
** Include major version upgrades
** New features
* Bug fixes reported to yocto project
* New yocto project tooling features
** Test infrastructure changes
** Automation changes
* New architectures added/removed

This works great for keeping a tighter integration loop with upstream.

== Current Stable Releases ==
The project maintains stable releases for 1 year and then it moves to community support, see
https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance which receives no testing on AB and occasional patches for really breaking things but no regular bug fixes and security updates. No major ABI breaking patches are applied to stable releases. Occasional bug fix only version bumps for packages are accepted after review. The current stable policy says that there are acceptable and unacceptable changes:

Acceptable:
* Security and CVE fixes
* Fixes for bugs
* Fixes so codebase works with newly released distros
* Bug fix only version upgrades (especially where follows upstream policy)

Unacceptable:
* General version upgrades
* New Features

== Long Term Stable (LTS) for Yocto Project ==
There has been rising requirement and interest amongst the project’s members and its end-users for supporting a given release for longer than what a stable release is maintained. The following is a proposal for what the project could do with some thoughts on the specific decisions the project would have to make to allow this to happen. There are specific choices which would have to be made. Maintaining such an LTS will require resourcing and its likely that the people providing the resourcing will have influence over the final choices.
Term
The term is not yet determined but in principle could be anywhere between 3-5 years, maybe even longer, it ultimately depends on people being available to do the work. There are downstream projects which are relying on Yocto project releases and has a longer life cycle but are not using commercial OS Vendor solutions e.g. AGL, Microsoft Azure, RDK etc. They all are following their own cadence of deploying a given version of Yocto project release and do not join efforts since its completely driven by their own requirements. This would be an opportunity for the project to converge these projects onto a LTS release and create a large enough developer community to support a given LTS release.
;Proposal:
:We start with a 3 year plan but this could extend if there was demand and support for maintaining it. Would need dedicated commitment of resources at the start and later a commitment to extend.

== Picking an LTS ==
This is hard with many different viewpoints. The first decision is whether to choose an LTS in advance or afterwards, elevating an existing stable release to LTS status. There are pros and cons to both. As a point of reference, the kernel has tried both but settled on deciding in advance.
;Proposal:
:We pick and announce an LTS in advance as this stands a better chance of people being able to align on it. This also allows the release to have focus on ensuring component choices have better long term support where possible. This implies 3.1 is the first viable candidate.

== Policies within LTS ==

A key question is whether the LTS follows the usual stable policies. In particular, how to handle the kernel versions in the LTS is a key question and could conflict with the “no upgrades” rule usually applied to a stable series. Certainly, an LTS release will likely only maintain LTS kernels. There is a possibility that multiple LTS kernels could exist in the project LTS release. For general recipe upgrades we’d follow stable policy which allows them in limited circumstances where upstream have a stable series or stable support model.
Whilst a “master first” policy is essential, for practicality not all stable intermediate releases may receive updates the LTS gets.
Proposal: We initially support the LTS the original release shipped with. We’d evaluate other similar vintage LTS kernels on a case by case basis depending on the status of upstream support. We need to be aware of the impact on test matrix if additional kernel versions were added and it would need to be resourced. The version of linux-libc-headers would not change to avoid user-space problems.

== How often would there be an LTS ==

;Proposal:
:Initially aim for an LTS every 2 years as otherwise there would be too many LTS in parallel. Ultimately it would depend on resourcing.

== Components to be covered ==

The project components to be covered would need to match those included in our standard release process and should be clearly defined. Those components would be:
* Bitbake
* OE-Core
* Meta-yocto
* yocto-docs
* (no meta-mingw or meta-gplv2)
* (no vendor layers)

== Who makes the final decision ==

;Proposal:
:The TSC is the ultimate decision making body but it would make a decision based on community feedback, people committing resources and input from the member organisations.

== LTS Maintainership ==

A LTS Maintainer is selected in the same manner as the Stable releases, i.e. the repo owner has the call. There could be more than one person who has ownership of the LTS branch but one may be identified as the point person. The Point person would be the one who handles bugzilla ownership/queries, build, QA and backporting concerns.

The Yocto TSC would retain the QA test result review and release go/nogo decision for any releases.

The LTS maintainer will be responsible in starting and monitoring builds. The Maintainer may have assistance from the community in resolving new issues identified during build and or the QA run.

Backport reviews will be sent to the mailing list for community review.
A merge request will be sent to the appropriate repo owner once all issues found during the review have been addressed.

== Infrastructure Needed ==

Whilst not immediately obvious and whilst well suited to testing current development, the current autobuilder is not suited to building, maintaining and testing an LTS release. In particular the autobuilder workers are multiple different distros (to get wide test coverage) running “bare-metal” for performance. For security reasons we only have workers which are in current support and have upgrade feeds available. We already struggle with the stable branches in this area.

In order to support an LTS release for the project, we’d propose that new autobuilder software infrastructure needs to be developed to support it. This could run on the same autobuilder hardware but we’d propose that for LTS, only one host distro be used for testing, probably an Ubuntu LTS because its easily available and has a long lifetime. This would most likely be in the form of a container based worker and the specific distro used would be used throughout the lifetime of the project LTS release. This would imply a worker/container combination per LTS release.

Building such software infrastructure is definitely possible but also non-trivial and as such, the work in setting it up needs to be included in any LTS plan.

An alternative could be to have a larger number of nodes running the chosen LTS distro and limiting the LTS builds to those workers. This could have implications for the build/testing time of the release. It could also have an impact on the availability of specialist processing workers such as the native ARM one. Performance testing is another area which would have to be carefully considered as the build time performance testing workers may not run the supported LTS distro.

For simplicity, it is also proposed that only automated testing be used for testing the LTS and that any current manual QA is not performed. The main reason for this is to streamline and simplify the testing and release process to allow regular and frequent updates to the LTS release without dependencies on external factors. Anyone can obviously perform their own testing of the LTS releases in addition to this core automated testing.

;Proposal:
:* Follow the same testing process as the original release
:* Only run virtualized tests
:* Only support one host distro, an Ubuntu LTS as it has right lifespan
:* Start by aiming to share the infrastructure meaning multiple LTS workers or LTS worker containers depending on funding and implementation
:* To share infrastructure this implies one autobuilder controller covering both potentially complicating configuration changes for master (likely manageable)

== Resource Requirements/Summary ==

The infrastructure requirements are easier to quantify and would likely consist of 2-3 additional additional worker machines over time for the above proposal as the minimum cost.

The human resource element to track, test (using automation) and merge patches is harder to quantify but at a rough guess, is probably 50% of a person’s time for the lifespan of the LTS.

This assumes that patches for various issues are forthcoming from others as its not realistic to expect one maintainer to handle creation of the various patches needed. The quality of the LTS will be directly related to the number of people working on the patches and them having the time to be able to ensure the patches are of the needed quality.

== Other Considerations ==

* Migration from one LTS to another
* Package compatibility from one LTS to another
* Should support subset of machines? Architectures?
* Prior Art Ubuntu: normal releases every six months (April and October), LTS every two years (every other April). Details and cadence chart at https://ubuntu.com/about/release-cycle.
* How we identify LTS releases (os-release, tags, wiki), pros and cons to changing
* If dynamic components such as go or rust are in core we may need a way to allow them to change at a higher rate of change due to the nature of the languages. Likely this can be done through an additional layer alongside the LTS to have the newer versions which users can collaborate on together. LTS “mixin” layers?

Stable branch maintenance

2020-08-08T22:08:17Z

Rpjday: /* Stable branch maintainers */

The Yocto Project maintains stable branches of Poky (OE-Core and BitBake). Typically, alongside the latest release the previous two releases are also maintained.

== Stable branch maintainers ==

{| class="wikitable"
! Major version
! Current Version
! Branch name
! BitBake version
! Maintainer
|-
| 3.2
| Dev
| Gatesgarth
| 1.48
| Richard Purdie <richard.purdie@linuxfoundation.org>
|-
| 3.1
| 3.1.1
| Dunfell
| 1.46
| Steve Sakoman <steve@sakoman.com>
|-
| 3.0
| 3.0.2
| Zeus
| 1.44
| Anuj/Armin
|-style="color: slategray;"
| 2.7
| 2.7.3
| Warrior
| 1.42
| Armin Kuster <akuster808@gmail.com>
|-style="color: slategray;"
| 2.6
| 2.6.4
| Thud
| 1.40
| Armin Kuster <akuster808@gmail.com>
|-style="color: slategray;"
| 2.5
| 2.5.3
| sumo
| 1.38
| Armin Kuster <akuster808@gmail.com>
|- style="color: slategray;"
| 2.4
| 2.4.4
| rocko
| 1.36
| Armin Kuster <akuster808@gmail.com>
|- style="color: slategray;"
|2.3
|2.3.4
|pyro
|1.34
|Armin Kuster <akuster808@gmail.com>
|- style="color: slategray;"
|2.2
|2.2.4
|morty
|1.32
|Armin Kuster <akuster808@gmail.com>
|- style="color: slategray;"
|2.1
|2.1.3
|krogoth
|1.30
|Armin Kuster <akuster808@gmail.com>
|- style="color: slategray;"
|2.0
|2.0.3
|jethro
|1.28
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.8
|1.8.2
|fido
|1.26
|Joshua Lock <joshua.g.lock@intel.com>
|- style="color: slategray;"
|1.7
|1.7.3
|dizzy
|1.24
|Armin Kuster <akuster808@gmail.com>
|- style="color: slategray;"
|1.6
|1.6.3
|daisy
|1.22
|Saul Wold <sgw@linux.intel.com>
|- style="color: slategray;"
|1.5
|1.5.4
|dora
|1.20
|Robert Yang <liezhi.yang@windriver.com>
|- style="color: slategray;"
|1.4
|1.4.3[http://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
|dylan
|1.18
|Paul Eggleton <paul.eggleton@linux.intel.com>
|- style="color: slategray;"
|1.3
|1.3.2
|danny
|1.16
|Ross Burton <ross.burton@intel.com>
|- style="color: slategray;"
|}

(Versions in grey above are no longer actively maintained, but well-tested patches may still be accepted for them.)

== Policies ==
See [[Stable Release and LTS]].

Transcript: creating one generic Atom BSP from another

2015-01-05T11:59:29Z

Rpjday: Use a bulleted list for easier reading.

Note: Though much of this page is still valid and can be useful in many cases, it should be noted that there are now tools that can help with the task of creating new BSPs and managing kernel patches and configuration settings for those BSPs, which you may want to consider first. Detailed documentation and walk-throughs using those tools are available at the following pages:

* [https://wiki.yoctoproject.org/wiki/Yocto_BSP_Tools_Documentation Yocto BSP Tools Documentation]
* [https://wiki.yoctoproject.org/wiki/Transcript:_Using_the_Yocto_BSP_tools_to_manage_kernel_patches_and_config_items Transcript: Using the Yocto BSP tools to manage kernel patches and config items]
* [https://wiki.yoctoproject.org/wiki/Transcript:_Using_the_Yocto_BSP_tools_to_create_a_qemu_BSP Transcript: Using the Yocto BSP tools to create a qemu BSP]
* [https://wiki.yoctoproject.org/wiki/Transcript:_Using_the_Yocto_BSP_tools_to_create_a_meta-intel_BSP Transcript: Using the Yocto BSP tools to create a meta-intel BSP].

Starting from scratch, we'll take a relatively generic Atom-based BSP and create another Atom-based BSP from that, that stands a good chance of booting and even booting into graphics, to serve as a starting point for a new BSP.

First set up poky:

trz@elmorro:/usr/local/test/yocto$ git init
Initialized empty Git repository in /usr/local/test/yocto/.git/
trz@elmorro:/usr/local/test/yocto$ git remote add poky git://git.yoctoproject.org/poky.git
trz@elmorro:/usr/local/test/yocto$ git remote update
Fetching poky
remote: Counting objects: 106111, done.
remote: Compressing objects: 100% (36106/36106), done.
remote: Total 106111 (delta 72275), reused 99193 (delta 66808)
Receiving objects: 100% (106111/106111), 69.51 MiB | 518 KiB/s, done.
Resolving deltas: 100% (72275/72275), done.
From git://git.yoctoproject.org/poky
* [new branch] 1.1_M1 -> poky/1.1_M1
* [new branch] 1.1_M2 -> poky/1.1_M2
* [new branch] bernard -> poky/bernard
* [new branch] blinky -> poky/blinky
* [new branch] clyde -> poky/clyde
* [new branch] elroy -> poky/elroy
* [new branch] green -> poky/green
* [new branch] laverne -> poky/laverne
* [new branch] master -> poky/master
* [new branch] pinky -> poky/pinky
* [new branch] purple -> poky/purple
* [new tag] 1.1_M1.final -> 1.1_M1.final
* [new tag] 1.1_M2.rc1 -> 1.1_M2.rc1
* [new tag] bernard-5.0.1 -> bernard-5.0.1
* [new tag] pinky-3.1.2 -> pinky-3.1.2
From git://git.yoctoproject.org/poky
* [new tag] 1.1_M1.rc1 -> 1.1_M1.rc1
* [new tag] 1.1_M1.rc2 -> 1.1_M1.rc2
* [new tag] bernard-1.0rc1 -> bernard-1.0rc1
* [new tag] bernard-5.0 -> bernard-5.0
* [new tag] bernard-5.0-alpha -> bernard-5.0-alpha
* [new tag] bernard-5.0rc1 -> bernard-5.0rc1
* [new tag] bernard-5.0rc2 -> bernard-5.0rc2
* [new tag] laverne-4.0 -> laverne-4.0
* [new tag] laverne-4.0.1 -> laverne-4.0.1
* [new tag] m4 -> m4
* [new tag] purple-3.2 -> purple-3.2
* [new tag] purple-3.2.1 -> purple-3.2.1

trz@elmorro:/usr/local/test/yocto$ git checkout -b bernard0 poky/bernard
Branch bernard0 set up to track remote branch bernard from poky.
Switched to a new branch 'bernard0'
trz@elmorro:/usr/local/test/yocto$ git checkout -f

Now check out meta-intel:

trz@elmorro:/usr/local/test/yocto$ mkdir meta-intel
trz@elmorro:/usr/local/test/yocto$ cd meta-intel
trz@elmorro:/usr/local/test/yocto/meta-intel$ git init
Initialized empty Git repository in /usr/local/test/yocto/meta-intel/.git/

trz@elmorro:/usr/local/test/yocto/meta-intel$ git remote add meta-intel git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/test/yocto/meta-intel$ git remote update
Fetching meta-intel
remote: Counting objects: 1240, done.
remote: Compressing objects: 100% (1008/1008), done.
remote: Total 1240 (delta 513), reused 85 (delta 27)
Receiving objects: 100% (1240/1240), 1.55 MiB | 510 KiB/s, done.
Resolving deltas: 100% (513/513), done.
From git://git.yoctoproject.org/meta-intel
* [new branch] 1.1_M1 -> meta-intel/1.1_M1
* [new branch] 1.1_M2 -> meta-intel/1.1_M2
* [new branch] bernard -> meta-intel/bernard
* [new branch] dvhart/n450 -> meta-intel/dvhart/n450
* [new branch] laverne -> meta-intel/laverne
* [new branch] master -> meta-intel/master

trz@elmorro:/usr/local/test/yocto/meta-intel$ git checkout -b bernard0 meta-intel/bernard
Branch bernard0 set up to track remote branch bernard from meta-intel.
Switched to a new branch 'bernard0'
trz@elmorro:/usr/local/test/yocto/meta-intel$ git checkout -f

The crownbay-noemgd is the closest thing we have to generic for Atom-based BSPs, so let's start with that:

trz@elmorro:/usr/local/test/yocto/meta-intel$ cp -a meta-crownbay/ meta-mymachine

We want to get rid of anything crownbay, but keep and rename anything crownbay-noemgd. So:

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/test/yocto/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf meta-mymachine/conf/machine/mymachine.conf

Next, let's look at mymachine.conf and see which, if any, changes we need there. Aside from the obvious comment changes (lines starting with '#'), there's nothing to change except for the SRCREV lines at the end, which basically tell the recipe which kernel commits to use.

First, we need to figure out which kernel we're using. For our bernard checkout, we see from the line in the mymachine.conf we copied that it's linux-yocto-stable:

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"

At the bottom of mymachine.conf, we see:

SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "56fe215d3f1a2cc3a5a26482ac9809ba44495695"
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "e1f85a470934a0cf6abde5d95533e74501822c6b"

SRCREV_machine_pn-linux-yocto-stable_crownbay-noemgd ?= "56fe215d3f1a2cc3a5a26482ac9809ba44495695"
SRCREV_meta_pn-linux-yocto-stable_crownbay-noemgd ?= "e1f85a470934a0cf6abde5d95533e74501822c6b"

Since we're only interested in linux-yocto-stable, we can remove the linux-yocto SRCREVS, but we need to update the SRCREVs for linux-yocto-stable. So we'll change the linux-yocto-stable lines above to point to the machine and meta branches we'll use for our new BSP.

For the initial version of the BSP, we'll use the "atom-pc-standard" machine branch, since we don't yet have our own, which is something to do in future iterations (not covered by this transcript - see the other tutorials for further steps).

We can find the atom-pc-standard commit id to use by looking in the linux-yocto-2.6.34 kernel repo at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34/commit/?h=atom-pc-standard for the machine branch and http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34/commit/?h=wrs_meta for the meta branch (note that branch names have changed in later repos e.g. linux-yocto, so keep that in mind if upgrading your kernel later. So the final SRCREVS for our new kernel are:

SRCREV_machine_pn-linux-yocto-stable_mymachine ?= "72ca49ab08b8eb475cec82a10049503602325791"
SRCREV_meta_pn-linux-yocto-stable_mymachine ?= "ec26387cb168e9e0976999b528b5a9dd62e3157a"

You also need to edit the meta-intel/meta-mymachine/conf/layer.conf to remove the crownbay lines and change the crownbay-noemgd lines from:

BBFILE_COLLECTIONS_crownbay-noemgd += "crownbay-noemgd"
BBFILE_PATTERN_crownbay-noemgd := "^${LAYERDIR}/"
BBFILE_PRIORITY_crownbay-noemgd = "6"

to:

BBFILE_COLLECTIONS_mymachine += "mymachine"
BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
BBFILE_PRIORITY_mymachine = "6"

Next, moving to recipes-bsp, we need to remove the crownbay formfactor and rename the crownbay-noemgd formfactor to mymachine:

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
trz@elmorro:/usr/local/test/yocto/meta-intel$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine

Next, moving to recipes-graphics, remove anything with emgd in it - that's for crownbay and we don't care about it.

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*

We also need to remove the crownbay xorg.conf and rename the crownbay-noemgd xorg.conf:

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
trz@elmorro:/usr/local/test/yocto/meta-intel$ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine

This will leave us with a VESA xconfig.

Next, moving to recipes-kernel, we need to make a couple changes to meta-intel/meta-mymachine/recipes-kernel/linux/linux-yocto-stable_git.bbappend. Again, remove the crownbay lines and change the crownbay-noemgd lines from:

COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
KMACHINE_crownbay-noemgd = "crownbay"

to

COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "mymachine"

Finally, don't forget to update the top-level README to reflect the capabilities of your new BSP.

You should now be able to build and boot a live image. Before running the bitbake command, however, be sure to source the environment setup script:

trz@elmorro:/usr/local/test/yocto$ source poky-init-build-env yocto-build
trz@elmorro:/usr/local/test/yocto/yocto-build$ bitbake poky-image-sato-live

If it doesn't build, you typed in something wrong.

If it doesn't boot, you have work to do that no transcript will help you with.

And remember, this transcript was based on bernard, which for this BSP was based on the 2.6.34 'stable' kernel. You probably don't want to base a new BSP on 2.6.34. The BSP this transcript was based on switched to 2.6.34 soon after bernard, so you should be able to look at later version of it or other BSPs for hints on how to switch to a more recent kernel. This BSP was chosen because the -noemgd branch was the most generic otherwise, and choosing something else would have caused more confusion than the simple text editing done here.

You might be further ahead to try a more recent 'milestone' branch of 1.1 to base your new BSP on, which would give you a more up-to-date system, but we used the bernard branch instead because that's more stable.

Distribution Support

2015-01-02T10:43:23Z

Rpjday: /* Distribution Support */ Whoops, fix a few minor typos while I'm here.

==Distribution Support ==
===Distribution Support ===
This page is to maintain a list of distributions validated to work with Yocto Project. Everyone is welcome to add distribution support information into this page.

'''NOTE: This list is outdated'''. Please refer to the documentation for the release you are using for a list of supported distributions. For example [http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#detailed-supported-distros http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#detailed-supported-distros].

{|border="1"
|| '''OS version''' || '''Host Arch''' || '''Status'''
|-
|| openSUSE 11.2 "Emerald" || -- || align="center" style="color:green;" | PASS
|-
||[[Distro/centos5.7|CentOS 5.7]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/centos6.2|CentOS 6.2]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/ubuntu7.04|Ubuntu 7.04]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/ubuntu8.04|Ubuntu 8.04 LTS]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/ubuntu10.04_32b|Ubuntu10.04]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/ubuntu11.04_64b|Ubuntu11.04]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora13_32b|Fedora 13]] || 32bit || align="center" style="color:green;" | PASS
|-
|| Fedora 14 || -- || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora15_32b|Fedora 15]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora15_64b|Fedora 15]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora16_64b|Fedora 16]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora17_64b|Fedora 17]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora18_64b|Fedora 18]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/opensuse11.3_32b|OpenSUSE 11.3]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/opensuse11.4_64b|OpenSUSE 11.4]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/rhel6.2_64b|Red Hat Enterprise Linux Server 6.2]] || 64bit || align="center" style="color:green;" | PASS
|-
|[[Distro/DebianWheezy | Debian Wheezy]] || 64bit || align="center" style="color:red;" | FAIL
|}

 

=== How to add a new entry or additional distro information ===
* Check if there is already a distribution listed on this page
* If there is no such distribution, you could add a new entry in above matrix for the distribution and add following information in the sub-page of this entry:

* Distribution (Fedora15/Ubuntu10.04/Opensuse11.4... etc):
* Arch (32/64):
* MACHINE (qemux86/qemuarm/qemuppc... etc):
* TARGET (core-image-sato/core-image-sato-sdk... etc):
* Commit/Release (7eea637db0.../master, 1.0.1 release):
* Validated by/DATE (user@email.com - 2011-09-14):
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)

* If there is already a distribution in above matrix, it's better for you to check if your test result is consistent with the old result in matrix. You could update the "Status" field and add additional information with above format into sub-page of the distribution.
 

== Distro Testing ==
=== Distro test coverage ===
Distro Testing is intended to catch bugs that are distribution specific using the yocto-autobuilder. The tests are all run on identical hardware and with all OS-es updated. The distributions used will be Fedora, Ubuntu, CentOS, OpenSuse with their latest update.
 
This is the list of the builds that are performed on Distro testing:
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"
|-
! scope="col"|Build-set
! scope="col"|Images Built
! scope="col"|Target machine
|-
|nightly-world
|world
|qemux86
|-
|buildtools
|buildtools-tarball
|qemux86-64
|-
| colspan="1" rowspan="5"|nightly-arm
|core-image-sato
| colspan="1" rowspan="5"|qemuarm
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
| colspan="1" rowspan="4"|nightly-multilib
|lib32-core-image-minimal
| colspan="1" rowspan="2"|qemux86-64
|-
|lib32-core-image-sato
|-
|lib64-core-image-minimal
| colspan="1" rowspan="2"|qemux86
|-
|lib64-core-image-sato
|-
|nightly-qa-systemd
|core-image-sato
|qemux86-64
|-
| colspan="1" rowspan="10"|nightly-x86
|core-image-sato
| colspan="1" rowspan="5"|qemux86
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
|core-image-sato
| colspan="1" rowspan="5"|qemux86-64
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
| colspan="1" rowspan="10"|nightly-x86-64
|core-image-sato
| colspan="1" rowspan="5"|qemux86
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
|core-image-sato
| colspan="1" rowspan="5"|qemux86-64
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|}

 
=== Distro Machines for 1.7 ===
Here is the list of the machines that Distro testing is being run against for 1.7
 

{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"
|-
! scope="col"|OS Version
! scope="col"|Host Arch
! scope="col"|Status
|-
|Ubuntu 14.04 LTS
|64 bit
|Pass
|-
|Fedora 20
|64 bit
|Pass
|-
|OpenSuse 13.1
|64 bit
|Pass
|-
|CentOS 6.5
|64 bit
|Pass
|}

Distribution Support

2015-01-02T10:41:29Z

Rpjday: /* Distribution Support */ Might as well link to the latest web page.

==Distribution Support ==
===Distribution Support ===
This page is to maintain a list of distributions validated work with Yocto. Everyone is welcomed to add distribution support information into this page.

NOTE: This list is out dated. Please refer to the documentation for the release your using for a list of supported distributions. For example [http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#detailed-supported-distros http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#detailed-supported-distros].

{|border="1"
|| '''OS version''' || '''Host Arch''' || '''Status'''
|-
|| openSUSE 11.2 "Emerald" || -- || align="center" style="color:green;" | PASS
|-
||[[Distro/centos5.7|CentOS 5.7]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/centos6.2|CentOS 6.2]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/ubuntu7.04|Ubuntu 7.04]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/ubuntu8.04|Ubuntu 8.04 LTS]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/ubuntu10.04_32b|Ubuntu10.04]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/ubuntu11.04_64b|Ubuntu11.04]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora13_32b|Fedora 13]] || 32bit || align="center" style="color:green;" | PASS
|-
|| Fedora 14 || -- || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora15_32b|Fedora 15]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora15_64b|Fedora 15]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora16_64b|Fedora 16]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora17_64b|Fedora 17]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/fedora18_64b|Fedora 18]] || 64bit || align="center" style="color:green;" | PASS
|-
||[[Distro/opensuse11.3_32b|OpenSUSE 11.3]] || 32bit || align="center" style="color:green;" | PASS
|-
||[[Distro/opensuse11.4_64b|OpenSUSE 11.4]] || 64bit || align="center" style="color:red;" | FAIL
|-
||[[Distro/rhel6.2_64b|Red Hat Enterprise Linux Server 6.2]] || 64bit || align="center" style="color:green;" | PASS
|-
|[[Distro/DebianWheezy | Debian Wheezy]] || 64bit || align="center" style="color:red;" | FAIL
|}

 

=== How to add a new entry or additional distro information ===
* Check if there is already a distribution listed on this page
* If there is no such distribution, you could add a new entry in above matrix for the distribution and add following information in the sub-page of this entry:

* Distribution (Fedora15/Ubuntu10.04/Opensuse11.4... etc):
* Arch (32/64):
* MACHINE (qemux86/qemuarm/qemuppc... etc):
* TARGET (core-image-sato/core-image-sato-sdk... etc):
* Commit/Release (7eea637db0.../master, 1.0.1 release):
* Validated by/DATE (user@email.com - 2011-09-14):
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)

* If there is already a distribution in above matrix, it's better for you to check if your test result is consistent with the old result in matrix. You could update the "Status" field and add additional information with above format into sub-page of the distribution.
 

== Distro Testing ==
=== Distro test coverage ===
Distro Testing is intended to catch bugs that are distribution specific using the yocto-autobuilder. The tests are all run on identical hardware and with all OS-es updated. The distributions used will be Fedora, Ubuntu, CentOS, OpenSuse with their latest update.
 
This is the list of the builds that are performed on Distro testing:
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"
|-
! scope="col"|Build-set
! scope="col"|Images Built
! scope="col"|Target machine
|-
|nightly-world
|world
|qemux86
|-
|buildtools
|buildtools-tarball
|qemux86-64
|-
| colspan="1" rowspan="5"|nightly-arm
|core-image-sato
| colspan="1" rowspan="5"|qemuarm
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
| colspan="1" rowspan="4"|nightly-multilib
|lib32-core-image-minimal
| colspan="1" rowspan="2"|qemux86-64
|-
|lib32-core-image-sato
|-
|lib64-core-image-minimal
| colspan="1" rowspan="2"|qemux86
|-
|lib64-core-image-sato
|-
|nightly-qa-systemd
|core-image-sato
|qemux86-64
|-
| colspan="1" rowspan="10"|nightly-x86
|core-image-sato
| colspan="1" rowspan="5"|qemux86
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
|core-image-sato
| colspan="1" rowspan="5"|qemux86-64
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
| colspan="1" rowspan="10"|nightly-x86-64
|core-image-sato
| colspan="1" rowspan="5"|qemux86
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|-
|core-image-sato
| colspan="1" rowspan="5"|qemux86-64
|-
|core-image-sato-dev
|-
|core-image-sato-sdk
|-
|core-image-minimal
|-
|core-image-minimal-dev
|}

 
=== Distro Machines for 1.7 ===
Here is the list of the machines that Distro testing is being run against for 1.7
 

{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"
|-
! scope="col"|OS Version
! scope="col"|Host Arch
! scope="col"|Status
|-
|Ubuntu 14.04 LTS
|64 bit
|Pass
|-
|Fedora 20
|64 bit
|Pass
|-
|OpenSuse 13.1
|64 bit
|Pass
|-
|CentOS 6.5
|64 bit
|Pass
|}

BitBake/UserManual

2013-01-09T12:31:10Z

Rpjday: /* Random observations by rday */

== Introduction ==

The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to bring the User Manual up to date.

== Current TOC ==

The chapter layout of the BitBake User Manual is currently:

# Introduction
# Metadata
# File Download Support
# The bitbake command

== What to Include? ==

* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?

* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.

== Lessons to Include ==

* The Bitbaked Hello World
** Build on the work by [http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ Eren Turkey] and the original tutorial at the [http://www.openembedded.org/wiki/BitBake_(dev) OpenEmbedded wiki].

* Using the Bitbake Env Utility

== Random observations by rday ==

* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching [http://www.crashcourse.ca/wiki/index.php/BitBake_fetching_and_patching here].

* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply [http://lists.linuxtogo.org/pipermail/bitbake-devel/2013-January/003984.html broken and unused]. I would ignore it. The other form, "VAR_append_<override>" is, of course, used massively and should be documented.

* Variables that probably deserve more coverage:
** <tt>BB_DANGLINGAPPENDS_WARNONLY = "1"</tt>

== Deprecated/weird/dead stuff ==

* All "proto=" should now be replaced with "protocol=" in SRC_URI, although the old form is still allowed but deprecated.
* All "pnum=" should now be replaced with "striplevel=" in SRC_URI for patches.
* Current BitBake manual shows a "this=ignored" parm for patches; total mystery what that means, nothing uses it, Chris Larson has no idea what it's for. Ignore it.

== Add Hob Documentation ==

With Hob getting better and better, it would seem appropriate to include a chapter in the Bitbake User Manual documenting it.

BitBake/UserManual

2013-01-02T13:32:45Z

Rpjday: /* Deprecated/weird/dead stuff */

== Introduction ==

The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to the bring the User Manual up to date.

== Current TOC ==

The chapter layout of the BitBake User Manual is currently:

# Introduction
# Metadata
# File Download Support
# The bitbake command

== What to Include? ==

* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?

* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.

== Lessons to Include ==

* The Bitbaked Hello World
** Build on the work by [http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ Eren Turkey] and the original tutorial at the [http://www.openembedded.org/wiki/BitBake_(dev) OpenEmbedded wiki].

* Using the Bitbake Env Utility

== Random observations by rday ==

* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching [http://www.crashcourse.ca/wiki/index.php/BitBake_fetching_and_patching here].

* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply [http://lists.linuxtogo.org/pipermail/bitbake-devel/2013-January/003984.html broken and unused]. I would ignore it. The other form, "VAR_append_<override>" is, of course, used massively and should be documented.

== Deprecated/weird/dead stuff ==

* All "proto=" should now be replaced with "protocol=" in SRC_URI, although the old form is still allowed but deprecated.
* All "pnum=" should now be replaced with "striplevel=" in SRC_URI for patches.
* Current BitBake manual shows a "this=ignored" parm for patches; total mystery what that means, nothing uses it, Chris Larson has no idea what it's for. Ignore it.

BitBake/UserManual

2013-01-02T13:08:28Z

Rpjday: /* Random observations by rday */

== Introduction ==

The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to the bring the User Manual up to date.

== Current TOC ==

The chapter layout of the BitBake User Manual is currently:

# Introduction
# Metadata
# File Download Support
# The bitbake command

== What to Include? ==

* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?

* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.

== Lessons to Include ==

* The Bitbaked Hello World
** Build on the work by [http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ Eren Turkey] and the original tutorial at the [http://www.openembedded.org/wiki/BitBake_(dev) OpenEmbedded wiki].

* Using the Bitbake Env Utility

== Random observations by rday ==

* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching [http://www.crashcourse.ca/wiki/index.php/BitBake_fetching_and_patching here].

* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply [http://lists.linuxtogo.org/pipermail/bitbake-devel/2013-January/003984.html broken and unused]. I would ignore it. The other form, "VAR_append_<override>" is, of course, used massively and should be documented.

== Deprecated/weird/dead stuff ==

* All "proto=" should now be replaced with "protocol=", although the old form is still allowed but deprecated.
* All "pnum=" should now be replaced with "striplevel=" for patches.
* Current BitBake manual shows a "this=ignored" parm for patches; total mystery what that means, nothing uses it.

BitBake/UserManual

2013-01-02T13:07:53Z

Rpjday: /* Deprecated/weird/dead stuff */

== Introduction ==

The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to the bring the User Manual up to date.

== Current TOC ==

The chapter layout of the BitBake User Manual is currently:

# Introduction
# Metadata
# File Download Support
# The bitbake command

== What to Include? ==

* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?

* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.

== Lessons to Include ==

* The Bitbaked Hello World
** Build on the work by [http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ Eren Turkey] and the original tutorial at the [http://www.openembedded.org/wiki/BitBake_(dev) OpenEmbedded wiki].

* Using the Bitbake Env Utility

== Random observations by rday ==

* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching [http://www.crashcourse.ca/wiki/index.php/BitBake_fetching_and_patching here].

* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply [http://lists.linuxtogo.org/pipermail/bitbake-devel/2013-January/003984.html broken and unused]. I would ignore it. The other form, "VAR_append_<override>", is used massively, of course and should be documented.

== Deprecated/weird/dead stuff ==

* All "proto=" should now be replaced with "protocol=", although the old form is still allowed but deprecated.
* All "pnum=" should now be replaced with "striplevel=" for patches.
* Current BitBake manual shows a "this=ignored" parm for patches; total mystery what that means, nothing uses it.

BitBake/UserManual

2013-01-02T13:06:50Z

Rpjday: /* Random observations by rday */

== Introduction ==

The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to the bring the User Manual up to date.

== Current TOC ==

The chapter layout of the BitBake User Manual is currently:

# Introduction
# Metadata
# File Download Support
# The bitbake command

== What to Include? ==

* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?

* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.

== Lessons to Include ==

* The Bitbaked Hello World
** Build on the work by [http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ Eren Turkey] and the original tutorial at the [http://www.openembedded.org/wiki/BitBake_(dev) OpenEmbedded wiki].

* Using the Bitbake Env Utility

== Random observations by rday ==

* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching [http://www.crashcourse.ca/wiki/index.php/BitBake_fetching_and_patching here].

* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply [http://lists.linuxtogo.org/pipermail/bitbake-devel/2013-January/003984.html broken and unused]. I would ignore it. The other form, "VAR_append_<override>", is used massively, of course and should be documented.

== Deprecated/weird/dead stuff ==

* All "proto=" should now be replaced with "protocol=", although the old form is still allowed but deprecated.
* All "pnum=" should now be replaced with "striplevel=" for patches.

BitBake/UserManual

2013-01-02T13:05:28Z

Rpjday: /* Random observations by rday */

== Introduction ==

The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to the bring the User Manual up to date.

== Current TOC ==

The chapter layout of the BitBake User Manual is currently:

# Introduction
# Metadata
# File Download Support
# The bitbake command

== What to Include? ==

* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?

* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.

== Lessons to Include ==

* The Bitbaked Hello World
** Build on the work by [http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ Eren Turkey] and the original tutorial at the [http://www.openembedded.org/wiki/BitBake_(dev) OpenEmbedded wiki].

* Using the Bitbake Env Utility

== Random observations by rday ==

* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching [http://www.crashcourse.ca/wiki/index.php/BitBake_fetching_and_patching here].

* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply [http://lists.linuxtogo.org/pipermail/bitbake-devel/2013-January/003984.html broken and unused]. I would ignore it. The other form, "VAR_append_<override>", is used massively, of course and should be documented.

BitBake/UserManual

2013-01-02T12:59:22Z

Rpjday: /* Random observations by rday */

BitBake/UserManual

2013-01-02T12:59:08Z

Rpjday: /* Random observations by rday */

BitBake/UserManual

2013-01-02T12:57:33Z

Rpjday: /* Lessons to Include */

Documentation

2012-12-15T11:37:23Z

Rpjday: Fix link.

See the http://yoctoproject.org/documentation page on the website for more information on this project.

Recipe & Patch Style Guide

2012-12-13T13:36:19Z

Rpjday: "LIC_FILE_CHKSUM" -> "LIC_FILES_CHKSUM"

= Motivation =

As with most style guides, the idea here is to have a consistent format and look
so that when someone new comes to the scene they can learn quickly and get involved.
This will also help the reviewers and maintainers understand what changes are being
made by contributors.

= Recipes file format and style =

As a brief summary:

* Consistent whitespace throughout the file
* File follows a roughly standard variable order
* Patches are all documented
* No legacy staging
* Use BBCLASSEXTEND where possible instead of -native versions
* No -sdk or -nativesdk packages, use BBCLASSEXTEND
* pkgconfig .pc files are correct and don't need manual mangling
* No custom do_configure for autotooled projects
* Uses "make install" where at all possible
** if recipe installs can we patch make install and push upstream

==== Additional MetaData ====

All recipes should aim to specify the following fields where possible:

* DESCRIPTION
* SUMMARY
* HOMEPAGE
* BUGTRACKER
* LICENSE
* LIC_FILES_CHKSUM
* DISTRO_PN_ALIAS

The DESCRIPTION should give an extended (possibly multi-line) description of what
recipe provides.

SUMMARY should give an 80 character/one line maximum short summary of the description.
Note that by default, DESCRIPTION is set to the value of SUMMARY, so if you only have
a short description to use, just set SUMMARY.

== White Space Management ==

* The correct spacing for a variable is FOO = "BAR".
* Use quotes on the right hand side of assignments: FOO = "BAR"
* Indentation of multiline variables such as SRC_URI is desirable.
* Most variables such as SRC_URI should use spaces.
* For multiple-line continuations, use spaces for indenting as developers tend to use different amount of spaces per tab.
* Shell functions should use tabs
* Python functions must use spaces (4 spaces per indent).
* No spaces are allowed after the line continuation symbol
* Comments inside bb files are allowed using the '#' character at the beginning of a line, but you cannot use a comment within a continuation.

== File Naming Convention ==

[[Versioning Policy|Use $packagename_$version.bb]]

== Guidelines for task functions ==

* Put the ''inherit'' declaration after the initial variables are set up and before any custom ''do_'' routines. This is flexible as ordering is often important.
* If you define custom ''do_'' routines, keep them in the order of the tasks being executed, that is:
** do_fetch
** do_unpack
** do_patch
** do_configure
** do_compile
** do_install
** do_populate_sysroot
** do_package

* Don't use ''cp'' to put files into staging or destination directories, use ''install'' instead.
* Don't use ''mkdir'' to create destination directories, use ''install -d'' instead.

== Preferred variable ordering ==

* There is a standard set of variables often found in a .bb file and the preferred order to make the file easily readable to seasoned developers is
** DESCRIPTION
** AUTHOR
** HOMEPAGE
** SECTION
** PRIORITY
** LICENSE
** DEPENDS
** SRCDATE
** SRCREV
** PV
** PR
** SRC_URI
** S
** inherit ...
** build class specific variables, i.e. EXTRA_QMAKEVARS_POST
** task overrides, i.e. do_configure
** PACKAGE_ARCH
** PACKAGES
** FILES
** RDEPENDS
** RRECOMMENDS
** RSUGGESTS
** PROVIDES
** RPROVIDES
** RCONFLICTS

* Variables related to the same package (*_{PN} and similar) should be kept together and after any PACKAGES definition
* Variables operating on packages (R* ones so RDEPENDS, RRECOMMENDS, RPROVIDES and so on as well as variables like ALLOW_EMPTY) should always specify the package they apply to, e.g. RDEPENDS_${PN} = "x", not RDEPENDS = "x"
* Recipes are sensitive to variable order so the above is a guideline, not an absolute rule.

== Example Recipe ==

<pre>
SUMMARY = "X11 Code Viewer"
DESCRIPTION = "Allow viewing of X11 code in a fancy way which allows easier \
and more productive X11 programming"
AUTHOR = "John Bazz <john.bazz@example.org>"
HOMEPAGE = "http://www.example.org/xcv/"
SECTION = "x11/applications"
PRIORITY = "optional"
LICENSE = "GPLv2"
DEPENDS = "libsm libx11 libxext libxaw"
SRCDATE = "20600815"
PV = "0.0+cvs${SRCDATE}"
PR = "r5"

# upstream does not yet publish any release so we have to fetch last working version from CVS
SRC_URI = "cvs://anonymous@xcv.example.org/cvsroot/xcv;module=xcv \
file://toolbar-resize-fix.patch;patch=1"

S = "${WORKDIR}/xcv/"

inherit autotools

do_configure_prepend() {
rm ${S}/aclocal.m4
}

do_install() {
install -d ${D}${bindir}
install -d ${D}${mandir}/man1

install -m 0755 xcv ${D}${bindir}/
install -m 0644 xcv.1.gz ${D}${mandir}/man1/
}

RDEPENDS_${PN} = "shared-mime-info"
RRECOMMENDS_${PN} = "ctags"
RCONFLICTS_${PN} = "xcv2"

</pre>

= Patches =

Patches (i.e. patch files within the metadata, which are referred to in SRC_URI) should contain information about where they came from and why they are required, as the project moves forward, we want to increase the quality of the data that is made available to the community. This can be done in the recipes and also in the patch files in order to understand why the patch exists and to help future maintainer to understand why it is required. The following information covers how to incorporate and manage patches within the meta-data.

For details on how to format newly created patches or properly submit existing patches for incorporation, please refer to the '''[[Contribution_Guidelines]]'''.

== New style patch application ==

The patch and pnum parameters have been renamed to the more logical apply and striplevel. The apply parameter takes either "yes" or "no" and the striplevel parameter takes an integer (0, 1, etc).

Both parameters are now optional with "sane" defaults.

The apply parameter is optional for SRC_URI lines with patch or diff extensions, which will default to being applied.

The striplevel parameter is also optional with a default striplevel of 1.

Old style parameters (patch and pnum) will continue to work for some time but it would be useful to move to the new style syntax as people are updating other parts of their recipes.

Therefore a patch line would be changed from:

file://some.patch;patch=1;pnum=2

to:

file://some.patch;striplevel=2

and a patch line:

file://another.diff;patch=1;pnum=1

could be changed to:

file://another.diff

= License Fields =

== LICENSE Metadata ==

* The LICENSE information in the .bb file needs to be practical.
* if there's "or any later version" in GPL related copyright, append "+" then which effectively means below:
GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv2.1, LGPLv2.1+, LGPLv3, LGPLv3+
* Scripts generated by autotools are not counted for licensing (they are always under GPL)
* Dual license: GPLv2 | BSD
* Multiple licenses: GPLv3+ & LGPLv2.1+
* GPLv3 (correction may be required!)
anti-tivoization in GPLv3 only applies to User Products, which per definition is “either
(1) a “consumer product”, which means any tangible personal property which is normally
used for personal, family, or household purposes, or (2) anything designed or sold for
incorporation into a dwelling."
* For package changing its license, better to keep new license in .inc file with old license in corresponding .bb file. Take readline for example:
readline.inc: LICENSE = "GPLv3+"
readline_5.2.bb: LICENSE = "GPLv2"
* we can treat MIT-style license as "MIT", meaning that any lawyer can tell it derivatives from standard form, such as below one:

Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting documentation, and
that the name of the copyright holders not be used in advertising or
publicity pertaining to distribution of the software without specific,
written prior permission. The copyright holders make no representations
about the suitability of this software for any purpose. It is provided "as
is" without express or implied warranty.
* some package may have complex license, such as wireless-tool:
most of files are GPLv2;
one part in file is GPLv2+;
some of them are dual licensed, such as sample_enc.c under LGPL | MPL | BSD.
In such case, first ignore the GPLv2+ bit since there is no way you could ever ship the package under say GPLv3 due to many headers being v2 only.
Since there are files that are GPLv2 only, the answer is no. The LICENSE field is therefore primarily GPLv2 and we can ignore the 2+ bits.
If they're a key part, the recipe becomes "GPLv2 & (LGPL | MPL | BSD)"
* automake may generate COPYING automatically if there's no such one existing (e.g. Xsettings-client-0.10). A short answer is to add a MIT-style COPYING in poky and then install it before autotools work. See last section for detail description
* all .bb files require LICENSE fields, even for those Poky specific (which are MIT).
* ask on the ML for license information for those local files we don't know their origins
* Name Sub-Packages with different Licenses
** LICENSE = "LGPLv2.1 & GPLv3+"
** LICENSE_libidn = "LGPLv2.1"
** LICENSE_libidn-tests = "GPLv3+"
* when listing sub-package license, remember to use names included in PACKAGES instead of source directories, e.g:
LICENSE = "GPLv2 & LGPLv2 & BSD & MIT"
LICENSE_lib/ext2fs = "LGPLv2"

Better to use:
LICENSE_e2fsprogs-mke2fs = "LGPLv2"
because mke2fs is a package name
----
* Two variants of the license, the New BSD License/Modified BSD License, and the Simplified BSD License/FreeBSD License have been verified as GPL-compatible free software licenses by the Free Software Foundation, while the original has not been accepted as an open source license(http://en.wikipedia.org/wiki/Original_BSD_license#4-clause)
* The original BSD license also includes a clause requiring all advertising of the software to display a notice crediting its authors. This "advertising clause" (since disavowed by UC Berkeley) is present in the modified MIT License used by XFree86 (http://en.wikipedia.org/wiki/MIT_License)
* http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses
* http://www.opensource.org/licenses/alphabetical
* http://www.gnu.org/licenses/license-list.html

=== Autotools adds wrong COPYING ===

Autotools add the wrong COPYING license to source code with out COPYING, to ensure that we have the correct and consistent license, add the correct license file to the SRC_URI List and a do_config_prepend().

SRC_URI = "... \
...
file://XXX-license"

do_configure_prepend() {
# This package doesn't ship with its own COPYING file and
# autotools will install a GPLv2 one instead of MIT. Add the
# correct license here to avoid confusion.
cp ${WORKDIR}/MIT-style-license ${S}/COPYING
}

== License Updates ==

There are 2 parts to the licensing update that needs to happen in the recipe files, first is the LICENSE metadata, and the second is the License Verification with LIC_FILES_CHKSUM

=== LICENSE ===

* GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2,
* LGPLv2+, LGPLv2.1, LGPLv2.1+, LGPLv3, LGPLv3+
* Dual license: GPLv2 | BSD
* Multiple licenses: GPLv3+ & LGPLv2.1+
* Name Sub-Packages with different Licenses
** LICENSE = "LGPLv2.1 & GPLv3+"
** LICENSE_libidn = "LGPLv2.1"
** LICENSE_libidn-tests = "GPLv3+"

=== LIC_FILES_CHKSUM ===
If a LICENSE or COPYING file exists, use it along with the license text from one source (header file preferred), if there is inconsistencies (multi versions, different licenses) report this information and then we can determine what the next steps should be to reconcile. Next steps include internal review and working with upstream community to reconcile licenses.

* How to specify the LIC_FILES_CHKSUM variable:
LIC_FILES_CHKSUM = “file://COPYING;md5=xxxx \
file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
file://licfile2.txt;endline=50;md5=zzzz \
...“

* Explanation:
This file lists all the files with the text of licenses for the source code. It is also possible to specify on which line the license text starts and on which line it ends within that file using the “beginline” & “endline” parameters. If the “beginline” parameter is not specified then license text begins from the 1st line is assumed. Similarly if “endline” parameter is not specified then the license text ends at the last line in the file is assumed. So if a file contains only licensing information, then there is no need to specify “beginline” & “endline” parameters.

The “md5” parameter stores the md5 checksum of the license text. So if the license text changes in any way, it’s md5 sum will differ and will not match with the previously stored md5 checksum. This mismatch will trigger build failure, notifying developer about the license text md5 mismatch, and allowing the developer to review the license text changes. Also note that if md5 checksum is not matched while building, the correct md5 checksum is printed in the build log.

There is no limit on how many files can be specified. But generally every project would need specifying of just one or two files for license tracking. Many projects would have a “COPYING” file which will store all the license information for all the source code files. If the “COPYING” file is valid then tracking only that file would be enough.

* Tips on using the LIC_FILES_CHKSUM variable:
1. if you specify empty or invalid “md5” parameter; then while building the package, bitbake will give md5 not matched error, and also show the correct “md5” parameter value in the build log

2. If the whole file contains only license text, then there is no need to specify “beginline” and “endline” parameters.

FAQ

2012-08-21T16:51:06Z

Rpjday:

'''Yocto Project Public Messages and FAQ'''

Last edited: 29 June, 2012

Note: technical FAQs are being added to the end of this document

'''Q: What is the Yocto Project?'''

'''A:''' The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''

'''A:''' This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

'''Q: How does the Yocto Project help Linux reach a wider embedded audience?'''

'''A:''' This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''

'''A:''' No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of producing an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''

'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates how source is fetched from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic - supporting both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipk format. The Yocto Project is also architecturally agnostic - supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.

The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is less steep. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it can be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''

'''A:''' Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.

'''Q: Does the Yocto Project have a special governance model, or is it managed as an open source project?'''

'''A:''' The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.

'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''

'''A:''' The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

Poky is a reference system for the Yocto Project, showing how the tools work together. It includes BitBake, openembedded-core, and several other components that anyone can use to start developing with embedded Linux. Poky as a build system is tested by the Yocto Project teams before each release. When you download and use the Yocto Project build system, you are actually downloading Poky and using it to create a distribution that by default is also named Poky. (You can, of course, name your distribution anything you like.)

'''Q: What is the difference between OpenEmbedded and the Yocto Project?'''

'''A:''' The Yocto Project and OpenEmbedded share a core collection of metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, interoperable, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

'''Q: Who defines the root filesystem and metadata?'''

'''A:''' Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

'''Q: What are the criteria for baseline metadata?'''

'''A:''' The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

'''Q: What tool sets are included in the Yocto Project? When will they be available?'''

'''A:''' The development toolchain is based on GCC. However, if a project contributor wished to add metadata that uses another toolchain, the project would be happy to consider it.

'''Q: What about graphics drivers? Will they be validated and integrated?'''

'''A:''' Yes.

'''Q: How will graphics IP in GPL drivers be handled?'''

'''A:''' The Board Support Packages (BSPs) supplied in the open source project are generally focused on open source code.

'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''

'''A:''' A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.

'''Q: Are there tools that allow the removal of a package from the build?'''

'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.

'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''

'''A:''' There are tools within BitBake that enable this level of examination.

“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

In addition, the Hob is a new graphical user interface for BitBake that makes these tools much easier to use.

'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''

'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release.

'''Q: How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release?'''

'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.

'''Q: Is the kernel included in the Yocto Project?'''

'''A:''' Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a Git branch.

'''Q: What are some possible debugging targets?'''

'''A:''' QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.

'''Q: What is the overall support plan for the Yocto Project?'''

'''A:''' Security patches and critical bug fixes are supplied one release back. No toolchain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

'''Q: What is meant by automated test capability?'''

'''A:''' The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.

'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''

'''A:''' Yes, all major commercial OSVs currently participate in the Yocto Project.

'''Q: For which software development boards is the Yocto Project validated?'''

'''A:''' Version 1.1 was validated against:
* ARM Beagleboard C4 and xM
* Several Intel Atom SoCs
* PowerPC - fsl-mpc8315e-rdb
* MIPS - Ubiquity Networks Router Station Pro

'''Q: Is user interface development possible with the Yocto Project?'''

'''A:''' User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks such as Qt, Clutter, or GTK+, all of which are included.

'''Q: Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project?'''

'''A:''' The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

== Usage FAQs ==

'''Q: How can I add a package to my project?'''

'''A:''' As with any complex system, the real answer is ''it depends'', but of course that is not very helpful. The simplest method for adding a single package to your build is to add a line like this to <code>conf/local.conf</code>:

IMAGE_INSTALL_append = " package"

Use your own package name in place of '''package'''. Note the leading space before the package name. If you want to add multiple packages, you can
use multiple lines like the above, or list all packages on a single line with:

IMAGE_INSTALL_append = " package1 package2 package3"

For more information, read [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-addpkg this chapter in the Yocto Project Development Manual].

'''Q: How can I use my own kernel with my project?'''

'''A:''' If you just want to change the kernel configuration, you can follow [http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html#kernel-configuration these instructions] to edit the stock kernel's configuration using <code>make menuconfig</code>.

If you have a separate kernel you wish to use, the simplest method for adding a new kernel to your build is to create a recipe for it and then add a line like this to <code>conf/local.conf</code>:

PREFERRED_PROVIDER_virtual/kernel= "your-recipe-for-kernel"

You can find several kernel examples in the Yocto Project file's meta/recipes-kernel/linux directory that you can use as references. [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-newmachine-kernel Look here] for more information.

'''Q: Who may I contact for further questions regarding the Yocto Project?'''

'''A:''' For any additional questions, please contact [mailto:jeffrey.osier-mixon@intel.com Jeff Osier-Mixon], the Yocto Project Community Manager.

How do I

2012-03-21T09:46:23Z

Rpjday: /* Q: How create my own source download mirror ? */

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your local.conf.

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all _files_(not symlinks) in your download directory to the desired source mirror directory
Test by setting variables below in local.conf
SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

BB_NO_NETWORK = "1"

== Q: How do I put yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.