Yocto Project - User contributions [en]

File:Research output.pdf

2016-09-12T18:38:35Z

Belenbarrospena:

Contribute to Toaster

2016-08-31T10:03:23Z

Belenbarrospena: /* Submitting patch sets for integration into Bitbake */

[[Category:Toaster]]
This page summarises the Toaster development process. We hope this will help you start contributing to the project.

== What can I do? ==

The [https://bugzilla.yoctoproject.org/buglist.cgi?product=Toaster Yocto Project Bugzilla instance] lists all the things that need to be done:

* If the issue says <strong>GUI design available</strong> in the Whiteboard field, there is a design specification document attached to the issue that you should follow. Send questions / comments about it to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list]
* If the issue says <strong>GUI design pending</strong> in the Whiteboard field, there is some design work still to be done. Feel free to take the issue and send an email to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list] to find out why the design work is not done yet

== Set up the local repository ==

For development of Toaster we recommend setting up a local install of Toaster. Installation instructions are available in the main [http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-manual-start Toaster documentation]

== Submitting patches ==

Publishing your patches to Toaster is a two step process.
# Sending patches to the [https://lists.yoctoproject.org/listinfo/toaster/| Toaster mailing list] for review
# Submitting the patches that you reviewed to the upstream repository

By submitting your patches first to the Toaster mailing list, you can be sure the patches are reviewed by the people in the community who are familiar with the Toaster source code, and who have experience developing web applications.

That also means that, by the time the patches are submitted to the upstream mailing lists, they are in pretty good shape. That helps the project maintainers, and hopefully also helps you.

Toaster code lives in Bitbake repository at [http://git.openembedded.org/bitbake/|http://git.openembedded.org/bitbake/].
All contributions must be upstreamed to the Bitbake repository in order to make it to the "master" branch of the poky/ repository.

=== Workflow ===
We are now supporting a [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib] toaster-next branch. The purpose of this branch is to speed up our work so that we can base patches on top of patches that are waiting for upstream inclusion but have not yet made it into master. To facilitate this we have some extra rebasing actions needed.

To contribute to toaster you will also need authorization to write to the upstream yocto project repository. Contact a member of the toaster team for details.

1) Download master branch of the yocto project
<code> git clone git://git.yoctoproject.org/poky && cd poky </code>

2) Add poky-contrib to the local repository you set up above
<code> git remote add poky-contrib ssh://git@git.yoctoproject.org/poky-contrib </code>

3) Fetch the poky-contrib branches
<code> git fetch --all </code>

4) Start your feature branch off of toaster-next
<code> git checkout -b the/target/branch poky-contrib/toaster-next </code>

5) Do Work

6) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them. This assumes you have phantomjs installed. This can usually be done from the distribution <code> apt-get install phantomjs</code>, for example. If you want to test against Chrome or Firefox, see the README in bitbake/lib/toaster/tests/browser.
<code> pip3 install selenium </code>
<code>TOASTER_TESTS_BROWSER=phantomjs bitbake/lib/toaster/manage.py test orm toastergui tests.browser </code>

7) Rebase on toaster-next. It has probably changed while you were working (unless you are really really fast!)
<code> git rebase poky-contrib/toaster-next </code>

8) Send to the toaster-mailing list using one of the methods outlined below.

=== Sending patches to Toaster Project ===

<strong>NOTE:</strong> The format of the commit message should be like this

<pre>
toaster: <short one line summary>

long(er) description

[YOCTO #0000]

Signed-off-by: First Last <name@domain.com>
</pre>

Where YOCTO #0000 is the related bug number if there is one. Signed off by with your git commit -s credentials.

We accept patches on the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] ( toaster@yoctoproject.org ) by "git send-email".

e.g.
<code>
$ git send-email HEAD^
</code>

Alternatively, you can use the utilities in the script directory to prepare your patch

1) Use the create-pull-request script (from poky) to create a pull request while on your feature branch
<code>./scripts/create-pull-request -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>

2) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

3)When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code> -t toaster@yoctoproject.org

A comprehensive document about commit messages is available on the [http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines openembedded wiki]

More help learning git is available on [https://try.github.io github] and [http://git-scm.com/documentation/ the official documentation]

=== Sending branches to Toaster Project ===

If you wish to submit whole branches please use the poky-contrib repository see [[Poky Contributions#Poky_Contrib_Branch]] for setup guide.

Once you have pushed a branch please then send an email to the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] with the subject in the following format:

<code>
[review-request] my_branch_name
</code>

In the body of the email it's useful to describe your branch's functionality, which commits and a link to the git web.

If you need any assistance please post on the mailing list.

=== Submitting patch sets for integration into Bitbake ===

Toaster patches are normally submitted upstream to the BitBake repository by the reviewer (not the author). This tells the upstream maintainers that the patches have been reviewed by the people who are familiar with the Toaster source code, and makes their busy lives a bit easier.

Since development happens on the poky-contrib repository, but the patches need to be merged to the Bitbake repository, the following process should be executed.

1) Bring toaster-next up to date with master
<code> git fetch poky-contrib toaster-next&& git fetch origin master</code>
<code> git checkout -b toaster-next poky-contrib/toaster-next </code>
<code> git rebase origin/master </code>

2) Checkout the target branch
<code>git checkout the/target/branch</code>

3) Create a new branch for submission
<code> git checkout -b yourname/submit/the/target/branch </code>

4) Make sure the branch is rebased on current poky-contrib toaster-next.
<code>git rebase poky-contrib/toaster-next</code>

5) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them. his assumes you have phantomjs installed. This can usually be done from the distribution <code> apt-get install phantomjs</code>, for example. If you want to test against Chrome or Firefox, see the README in bitbake/lib/toaster/tests/browser.
<code> pip3 install selenium </code>
<code>TOASTER_TESTS_BROWSER=phantomjs bitbake/lib/toaster/manage.py test orm toastergui tests.browser </code>

6) Add signed off by to the commit messages
<code>git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' toaster-next..HEAD</code>

7) Push the modified commit messages and rebased version to poky-contrib
<code>git push -u poky-contrib yourname/submit/the/target/branch </code>

8) Use the create-pull-request script (from poky) to create a pull request
<code>./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>
<br>
<strong>Note: If the patch creates any NEW files, the integration scripts that pull it into bitbake will fail. So, if new files are created as part of this patch set, you need to explicitly point that out in the body of the email for the patch set or do it as a PR rather than as a patch set.
</strong>

9) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

10) Push the branch you just signed off on and sent upstream to toaster-next
<code> git push -f -u poky-contrib yourname/submit/the/target/branch:toaster-next </code>

When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code> -t bitbake-devel@lists.openembedded.org

==== Submitting patches for prior releases ====

The procedure is the same, but using the prior release as the base branch instead of the "master" branch in bitbake.

Also, make sure that you add the name of the prior release for which the patchset is intended in the prefix of the patchset, as parameter to the "create-pull-request" command, e.g. '''-p 1.26''' for the 1.26 branch.

==== Gotchas ====
===== Too Big =====
Sometimes the mailer will refuse to send patches, especially on binary or long-line files. The proper way to go around that is to reply to the patchset you've submitted to the mailing list, asking for a git pull directly from the poky-contrib branch.
===== Different Lists =====

The toasterconf.json files live in the meta and meta-yocto layer. Patches to the meta-yocto/conf/toasterconf.json go to poky@yoctoproject.org. Patches to meta/conf/toasterjson.conf go to openembedded-core@lists.openembedded.org. Patches for toaster.bbclass also go to the openembedded--core list. If you have a branch that spans both (let's say you made coupled changes to meta/classes/toaster.bbclass and bitbake/lib/bb/ui/buildinfohelper.py. then your branch needs to be split into 2 different patch set submissions. Let's assume there are 5 commits, 2 to meta and 3 to bitbake. Currently, you can do this suboptimal workaround:
<code>
./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
./scripts/create-pull-request -d meta -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
</code>
This will create 2 pull-XXXX directories, one for openembedded and one for bitbake-devel. Unfortunately, the meta pull-XXXX dir will have patches numbered 1-5 with 3 0 byte files and the bitbake pull-XXXX dir will have patches numbered 1-5 with 2 0 byte files. You delete the 0 byte files and use a text editor to do the renumbering. At some point it would be nice to have the create-pull-request do this for us but this level of file modification would probably mean moving it out of a shell script and into python. Once the files have been renumbered (in the subject line and the cover letter) the send-pull-request can be used as referenced above.
<br><p>
A different workaround that may work better for you is to create two branches which lets you use the create-pull-request and send-pull-request scripts normally on each branch. Just make sure to target them correctly
</p>
<code>
git checkout -b yourname/submit/the/target/branch-ForBitbake yourname/submit/the/target/branch
git rebase -i
# delete all the commits that are OE specific in the set you wish to submit
git push -u poky-contrib yourname/submit/the/target/branchForBitbake:yourname/submit/the/target/branchForBitbake
./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
git checkout -b yourname/submit/the/target/branch-ForOE yourname/submit/the/target/branch
git rebase -i
# delete all the commits that are bitbake specific in the set you wish to submit
git push -u poky-contrib yourname/submit/the/target/branchForOE:yourname/submit/the/target/branchForOE
./scripts/create-pull-request -d meta -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
</code>

===== One Patch of a Long Patch Set Needs Resubmission =====
Suppose you upstream a 10 commit patch set to the bitbake-devel list and someone finds an issue with patch #3. Regenerating the whole series is silly so how do you address this? First, follow the bitbake submission steps until you end up on the yourname/submit/the/target/branch branch. Then you can (note <strong>the reset --hard will wipe any local changes in your working dir so commit or stash first</strong>):<br>
<code>
git checkout -b yourname/submit/the/target/branch-newHEAD
git reset --hard <commit of resubmission issue>
git commit --amend --signoff
git send-email --in-reply-to="longNumber.git.me@mycomp.com" --subject-prefix="bitbake-devel] [PATCHVX 03/10" --to=bitbake-devel@lists.openembedded.org --no-chain-reply-to --suppress-cc=all -M -1 --relative=bitbake
</code><br>
The longNumber.git.me@mycomp.com comes from the email message id for the particular patch #3 so that the email threading works. In gmail, you can click on the dropdown button on the right side of the screen and choose "Show Original". This will have a field in the header like Message-Id: <4551b56f132497c055f39567946a5d3be347d770.1468363530.git.myemailusername@mycompany.com> The entire string except the '<>' are used. for example:<br>
<code>
--in-reply-to="4551b56f132497c055f39567946a5d3be347d770.1468363530.git.myemailusername@mycompany.com"
</code><br>

Don't forget to switch back to the yourname/submit/the/target/branch and push that to poky-contrib/toaster-next! This is a little harder since you will have previously pushed a different version of the patch to poky-contrib/toaster-next. You can do a rebase/merge by hand but that can be prone to error. Here's the working sequence assuming it's been a few days between the first poky-contrib/toaster-next push and the one you are working on now (meaning both poky-contrib/toaster-next and origin/master have changes).<br>
The first issue you are likely to face is that the git filter-branch command in the standard instructions may sign off on too many commits. If you know you just want to sign off on the last 7 commits on the yourname/submit/the/target/branch you can:
<code>
git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' HEAD~7..HEAD
</code>
Once your signoff is copacetic, updating poky-contrib/toaster-next can be done as follows:
<code>
git fetch poky-contrib toaster-next&& git fetch origin master
git checkout -b toaster-next poky-contrib/toaster-next
git rebase origin/master
git checkout yourname/submit/the/target/branch
git rebase --strategy recursive -X theirs -X patience toaster-next
git push -fu poky-contrib poky-contrib yourname/submit/the/target/branch:toaster-next
</code>

=== Submitting patches for documentation ===

Documentation patches should be sent to [https://lists.yoctoproject.org/listinfo/yocto Yocto mailing list] with [yocto-docs] in the subject, CC Scott Rifenbark (and make sure you send it to his gmail, not his defunct Intel address). For his email address, look at [http://lists.openembedded.org/pipermail/bitbake-devel/2015-October/006632.html this post].

== Code syle guide ==

=== Templates ===

Django has a template language which allows us to render pages based on the data (context). We use the template language to setup the initial state of the page and to create re-usable components that can be included in other pages.

The recommend template code style is as follows

'''Yes please:'''

<pre>
{{var}}

<div>
{# Maintaining indentation #}
{% if %}
<p>this</p>
{% else %}
<p>that</p>
{% endif %}
</div>

{% comment %}
This is a longer comment that describes all the things
that are below in quite a bit of detail because they're
a little more difficult to understand.
{% endcomment %}

{% for layer in layers_list %}
{{layer}}
{% endfor %}

</pre>

'''No thank you:'''
<pre>
{{var}}
<div>
{# Maintaining indentation #}
{%if%}<p>this</p>{%else%}<p>that</p>{%endif%}
</div>

{#This is a longer comment that describes all the things that are below in quite a bit of detail because they're a little more difficult to understand. #}
{%for o in layers_list%}{{o}}{%endfor%}
</pre>

Note:
* Maintain indentation as you would with other languages
* White space after '%'
* Comment blocks for longer comments

=== Javascript ===

'''Yes please:'''
<pre>

"use strict";

/* These hold some numbers */
var oneVar = 1;
var twoVar = 2;

var cheesesTypes = {
cheddar : 1,
stilton : 2,
emmental : 3,
};

function doThingsHere(){
return 1;
}

/* If one equals two do some other things and make sure that
* if the the click handler is setup correctly.
*/
if (one === two) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function (event){
alert("Hello");
});
}

$("#little-mouse").focusout(function(){
alert("bye")
});

if (oneVar)
noThingHere();
else
doThingHere();
</pre>

'''No thank you:'''
<pre>
// These hold some numbers
oneVar = 1
twoVar = 2

var cheesesTypes = { cheddar : 1, stilton : 2, emmental : 3, }

function doThingsHere ()
{
return 1;
}

//If one equals two do some other things and make sure that if the the click handler is setup correctly.
if( one === two ) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function(event){ alert("Hello"); });
}

document.getElementById("little-mouse").addEventListener("focusout", function(){
alert("bye")
});

if (oneVar)
{
noThingHere();
} else { doThingHere(); }
</pre>

Note:
* Variables should be marked with "var"
* Semicolons should be used
* Keep as close to 80 cols as possible
* Use 2 space per indentation
* Open curly braces after parenthesis for functions and close on a new line
* Use camelCase for function names and variable names

Make use of running your Javascript through jshint we have a .jshint configuration file in that js directory (toastergui/static/js)

e.g. install jshint and add to your current PATH, then run:
<code>
$ npm install jshint; export PATH=$PATH:$PWD/node_modules/.bin/
$ jshint ./toastergui/static/js/base.js
</code>

=== HTML ===

'''Yes please:'''
<pre>
<div id="something-area">
<p class="important">This is some text</p>
</div>

<div>
<p id="important-text>This is some text</p>
</div>

</pre>

'''No thank you:'''
<pre>
<div id="somethingarea">
<p class="Important">This is some text</p></div>
<div id="somethingarea">
<p id="ImportantText">This is
some text
</p>

</div>
</pre>

Note:
* 2 space indentation
* Lower case, ids hyphenated when multiple words
* No duplicate ids

* Run your HTML through a [http://validator.w3.org/#validate_by_input HTML validator] available for [http://validator.w3.org/source/ local install]. The w3c validator it's self doesn't currently validate html5, it uses as a back end [https://validator.github.io/validator/ Nu Html Checker] which can be installed as a standalone service, full instructions in the readme.

Quick install instructions:
<pre>
$ mkdir html5-validator && cd html5-validator
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
$ git clone https://github.com/validator/validator.git
$ python build/build.py all
$ python build/build.py all
</pre>

HTML can be indented quickly using tidy, for example:
<pre>
tidy -xml --indent auto --indent-spaces 2 --quiet yes -w -1 --show-body-only yes ./index.html
</pre>

=== Python ===

Lenient [https://www.python.org/dev/peps/pep-0008 pep8]
Ignoring most of the whitespace around character issues (E124,E203,E201,E265,E303,E302,E231) see toaster/.pep8 and [http://pep8.readthedocs.org/en/latest/intro.html#error-codes error code list]

Fix all issues identified by running code through pep8. We have a fairly lenient config file (toaster/.pep8).

e.g.
<code>
$ pep8 ./toastergui/urls.py
</code>

Run code through pylint and fix identified issues - Some can be reasonably ignored such as doc strings for every function or star-args. No pylintrc config provided here as most issues identified are highly contextual and should be ignored on a case by case basis.

<code>
$ pylint --load-plugins pylint_django toastergui/tests.py
</code>

== Working with design ==

Yes, the Yocto Project is one of those lucky projects with designers around to help in UI matters. We have a document explaining how to work with the design contributors: [[File:Working_with_design.pdf]]

Contribute to Toaster

2016-08-31T10:02:44Z

Belenbarrospena: /* Workflow */

[[Category:Toaster]]
This page summarises the Toaster development process. We hope this will help you start contributing to the project.

== What can I do? ==

The [https://bugzilla.yoctoproject.org/buglist.cgi?product=Toaster Yocto Project Bugzilla instance] lists all the things that need to be done:

* If the issue says <strong>GUI design available</strong> in the Whiteboard field, there is a design specification document attached to the issue that you should follow. Send questions / comments about it to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list]
* If the issue says <strong>GUI design pending</strong> in the Whiteboard field, there is some design work still to be done. Feel free to take the issue and send an email to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list] to find out why the design work is not done yet

== Set up the local repository ==

For development of Toaster we recommend setting up a local install of Toaster. Installation instructions are available in the main [http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-manual-start Toaster documentation]

== Submitting patches ==

Publishing your patches to Toaster is a two step process.
# Sending patches to the [https://lists.yoctoproject.org/listinfo/toaster/| Toaster mailing list] for review
# Submitting the patches that you reviewed to the upstream repository

By submitting your patches first to the Toaster mailing list, you can be sure the patches are reviewed by the people in the community who are familiar with the Toaster source code, and who have experience developing web applications.

That also means that, by the time the patches are submitted to the upstream mailing lists, they are in pretty good shape. That helps the project maintainers, and hopefully also helps you.

Toaster code lives in Bitbake repository at [http://git.openembedded.org/bitbake/|http://git.openembedded.org/bitbake/].
All contributions must be upstreamed to the Bitbake repository in order to make it to the "master" branch of the poky/ repository.

=== Workflow ===
We are now supporting a [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib] toaster-next branch. The purpose of this branch is to speed up our work so that we can base patches on top of patches that are waiting for upstream inclusion but have not yet made it into master. To facilitate this we have some extra rebasing actions needed.

To contribute to toaster you will also need authorization to write to the upstream yocto project repository. Contact a member of the toaster team for details.

1) Download master branch of the yocto project
<code> git clone git://git.yoctoproject.org/poky && cd poky </code>

2) Add poky-contrib to the local repository you set up above
<code> git remote add poky-contrib ssh://git@git.yoctoproject.org/poky-contrib </code>

3) Fetch the poky-contrib branches
<code> git fetch --all </code>

4) Start your feature branch off of toaster-next
<code> git checkout -b the/target/branch poky-contrib/toaster-next </code>

5) Do Work

6) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them. This assumes you have phantomjs installed. This can usually be done from the distribution <code> apt-get install phantomjs</code>, for example. If you want to test against Chrome or Firefox, see the README in bitbake/lib/toaster/tests/browser.
<code> pip3 install selenium </code>
<code>TOASTER_TESTS_BROWSER=phantomjs bitbake/lib/toaster/manage.py test orm toastergui tests.browser </code>

7) Rebase on toaster-next. It has probably changed while you were working (unless you are really really fast!)
<code> git rebase poky-contrib/toaster-next </code>

8) Send to the toaster-mailing list using one of the methods outlined below.

=== Sending patches to Toaster Project ===

<strong>NOTE:</strong> The format of the commit message should be like this

<pre>
toaster: <short one line summary>

long(er) description

[YOCTO #0000]

Signed-off-by: First Last <name@domain.com>
</pre>

Where YOCTO #0000 is the related bug number if there is one. Signed off by with your git commit -s credentials.

We accept patches on the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] ( toaster@yoctoproject.org ) by "git send-email".

e.g.
<code>
$ git send-email HEAD^
</code>

Alternatively, you can use the utilities in the script directory to prepare your patch

1) Use the create-pull-request script (from poky) to create a pull request while on your feature branch
<code>./scripts/create-pull-request -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>

2) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

3)When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code> -t toaster@yoctoproject.org

A comprehensive document about commit messages is available on the [http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines openembedded wiki]

More help learning git is available on [https://try.github.io github] and [http://git-scm.com/documentation/ the official documentation]

=== Sending branches to Toaster Project ===

If you wish to submit whole branches please use the poky-contrib repository see [[Poky Contributions#Poky_Contrib_Branch]] for setup guide.

Once you have pushed a branch please then send an email to the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] with the subject in the following format:

<code>
[review-request] my_branch_name
</code>

In the body of the email it's useful to describe your branch's functionality, which commits and a link to the git web.

If you need any assistance please post on the mailing list.

=== Submitting patch sets for integration into Bitbake ===

Toaster patches are normally submitted upstream to the BitBake repository by the reviewer (not the author). This tells the upstream maintainers that the patches have been reviewed by the people who are familiar with the Toaster source code, and makes their busy lives a bit easier.

Since development happens on the poky-contrib repository, but the patches need to be merged to the Bitbake repository, the following process should be executed.

1) Bring toaster-next up to date with master
<code> git fetch poky-contrib toaster-next&& git fetch origin master</code>
<code> git checkout -b toaster-next poky-contrib/toaster-next </code>
<code> git rebase origin/master </code>

2) Checkout the target branch
<code>git checkout the/target/branch</code>

3) Create a new branch for submission
<code> git checkout -b yourname/submit/the/target/branch </code>

4) Make sure the branch is rebased on current poky-contrib toaster-next.
<code>git rebase poky-contrib/toaster-next</code>

5) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them. his assumes you have phantomjs installed. This can usually be done from the distribution <code> apt-get install phantomjs</code>, for example. If you want to test against Chrome or Firefox, see the README in bitbake/lib/toaster/tests/browser.
<code> pip install selenium </code>
<code>TOASTER_TESTS_BROWSER=phantomjs bitbake/lib/toaster/manage.py test orm toastergui tests.browser </code>

6) Add signed off by to the commit messages
<code>git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' toaster-next..HEAD</code>

7) Push the modified commit messages and rebased version to poky-contrib
<code>git push -u poky-contrib yourname/submit/the/target/branch </code>

8) Use the create-pull-request script (from poky) to create a pull request
<code>./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>
<br>
<strong>Note: If the patch creates any NEW files, the integration scripts that pull it into bitbake will fail. So, if new files are created as part of this patch set, you need to explicitly point that out in the body of the email for the patch set or do it as a PR rather than as a patch set.
</strong>

9) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

10) Push the branch you just signed off on and sent upstream to toaster-next
<code> git push -f -u poky-contrib yourname/submit/the/target/branch:toaster-next </code>

When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code> -t bitbake-devel@lists.openembedded.org

==== Submitting patches for prior releases ====

The procedure is the same, but using the prior release as the base branch instead of the "master" branch in bitbake.

Also, make sure that you add the name of the prior release for which the patchset is intended in the prefix of the patchset, as parameter to the "create-pull-request" command, e.g. '''-p 1.26''' for the 1.26 branch.

==== Gotchas ====
===== Too Big =====
Sometimes the mailer will refuse to send patches, especially on binary or long-line files. The proper way to go around that is to reply to the patchset you've submitted to the mailing list, asking for a git pull directly from the poky-contrib branch.
===== Different Lists =====

The toasterconf.json files live in the meta and meta-yocto layer. Patches to the meta-yocto/conf/toasterconf.json go to poky@yoctoproject.org. Patches to meta/conf/toasterjson.conf go to openembedded-core@lists.openembedded.org. Patches for toaster.bbclass also go to the openembedded--core list. If you have a branch that spans both (let's say you made coupled changes to meta/classes/toaster.bbclass and bitbake/lib/bb/ui/buildinfohelper.py. then your branch needs to be split into 2 different patch set submissions. Let's assume there are 5 commits, 2 to meta and 3 to bitbake. Currently, you can do this suboptimal workaround:
<code>
./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
./scripts/create-pull-request -d meta -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
</code>
This will create 2 pull-XXXX directories, one for openembedded and one for bitbake-devel. Unfortunately, the meta pull-XXXX dir will have patches numbered 1-5 with 3 0 byte files and the bitbake pull-XXXX dir will have patches numbered 1-5 with 2 0 byte files. You delete the 0 byte files and use a text editor to do the renumbering. At some point it would be nice to have the create-pull-request do this for us but this level of file modification would probably mean moving it out of a shell script and into python. Once the files have been renumbered (in the subject line and the cover letter) the send-pull-request can be used as referenced above.
<br><p>
A different workaround that may work better for you is to create two branches which lets you use the create-pull-request and send-pull-request scripts normally on each branch. Just make sure to target them correctly
</p>
<code>
git checkout -b yourname/submit/the/target/branch-ForBitbake yourname/submit/the/target/branch
git rebase -i
# delete all the commits that are OE specific in the set you wish to submit
git push -u poky-contrib yourname/submit/the/target/branchForBitbake:yourname/submit/the/target/branchForBitbake
./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
git checkout -b yourname/submit/the/target/branch-ForOE yourname/submit/the/target/branch
git rebase -i
# delete all the commits that are bitbake specific in the set you wish to submit
git push -u poky-contrib yourname/submit/the/target/branchForOE:yourname/submit/the/target/branchForOE
./scripts/create-pull-request -d meta -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next
</code>

===== One Patch of a Long Patch Set Needs Resubmission =====
Suppose you upstream a 10 commit patch set to the bitbake-devel list and someone finds an issue with patch #3. Regenerating the whole series is silly so how do you address this? First, follow the bitbake submission steps until you end up on the yourname/submit/the/target/branch branch. Then you can (note <strong>the reset --hard will wipe any local changes in your working dir so commit or stash first</strong>):<br>
<code>
git checkout -b yourname/submit/the/target/branch-newHEAD
git reset --hard <commit of resubmission issue>
git commit --amend --signoff
git send-email --in-reply-to="longNumber.git.me@mycomp.com" --subject-prefix="bitbake-devel] [PATCHVX 03/10" --to=bitbake-devel@lists.openembedded.org --no-chain-reply-to --suppress-cc=all -M -1 --relative=bitbake
</code><br>
The longNumber.git.me@mycomp.com comes from the email message id for the particular patch #3 so that the email threading works. In gmail, you can click on the dropdown button on the right side of the screen and choose "Show Original". This will have a field in the header like Message-Id: <4551b56f132497c055f39567946a5d3be347d770.1468363530.git.myemailusername@mycompany.com> The entire string except the '<>' are used. for example:<br>
<code>
--in-reply-to="4551b56f132497c055f39567946a5d3be347d770.1468363530.git.myemailusername@mycompany.com"
</code><br>

Don't forget to switch back to the yourname/submit/the/target/branch and push that to poky-contrib/toaster-next! This is a little harder since you will have previously pushed a different version of the patch to poky-contrib/toaster-next. You can do a rebase/merge by hand but that can be prone to error. Here's the working sequence assuming it's been a few days between the first poky-contrib/toaster-next push and the one you are working on now (meaning both poky-contrib/toaster-next and origin/master have changes).<br>
The first issue you are likely to face is that the git filter-branch command in the standard instructions may sign off on too many commits. If you know you just want to sign off on the last 7 commits on the yourname/submit/the/target/branch you can:
<code>
git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' HEAD~7..HEAD
</code>
Once your signoff is copacetic, updating poky-contrib/toaster-next can be done as follows:
<code>
git fetch poky-contrib toaster-next&& git fetch origin master
git checkout -b toaster-next poky-contrib/toaster-next
git rebase origin/master
git checkout yourname/submit/the/target/branch
git rebase --strategy recursive -X theirs -X patience toaster-next
git push -fu poky-contrib poky-contrib yourname/submit/the/target/branch:toaster-next
</code>

=== Submitting patches for documentation ===

Documentation patches should be sent to [https://lists.yoctoproject.org/listinfo/yocto Yocto mailing list] with [yocto-docs] in the subject, CC Scott Rifenbark (and make sure you send it to his gmail, not his defunct Intel address). For his email address, look at [http://lists.openembedded.org/pipermail/bitbake-devel/2015-October/006632.html this post].

== Code syle guide ==

=== Templates ===

Django has a template language which allows us to render pages based on the data (context). We use the template language to setup the initial state of the page and to create re-usable components that can be included in other pages.

The recommend template code style is as follows

'''Yes please:'''

<pre>
{{var}}

<div>
{# Maintaining indentation #}
{% if %}
<p>this</p>
{% else %}
<p>that</p>
{% endif %}
</div>

{% comment %}
This is a longer comment that describes all the things
that are below in quite a bit of detail because they're
a little more difficult to understand.
{% endcomment %}

{% for layer in layers_list %}
{{layer}}
{% endfor %}

</pre>

'''No thank you:'''
<pre>
{{var}}
<div>
{# Maintaining indentation #}
{%if%}<p>this</p>{%else%}<p>that</p>{%endif%}
</div>

{#This is a longer comment that describes all the things that are below in quite a bit of detail because they're a little more difficult to understand. #}
{%for o in layers_list%}{{o}}{%endfor%}
</pre>

Note:
* Maintain indentation as you would with other languages
* White space after '%'
* Comment blocks for longer comments

=== Javascript ===

'''Yes please:'''
<pre>

"use strict";

/* These hold some numbers */
var oneVar = 1;
var twoVar = 2;

var cheesesTypes = {
cheddar : 1,
stilton : 2,
emmental : 3,
};

function doThingsHere(){
return 1;
}

/* If one equals two do some other things and make sure that
* if the the click handler is setup correctly.
*/
if (one === two) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function (event){
alert("Hello");
});
}

$("#little-mouse").focusout(function(){
alert("bye")
});

if (oneVar)
noThingHere();
else
doThingHere();
</pre>

'''No thank you:'''
<pre>
// These hold some numbers
oneVar = 1
twoVar = 2

var cheesesTypes = { cheddar : 1, stilton : 2, emmental : 3, }

function doThingsHere ()
{
return 1;
}

//If one equals two do some other things and make sure that if the the click handler is setup correctly.
if( one === two ) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function(event){ alert("Hello"); });
}

document.getElementById("little-mouse").addEventListener("focusout", function(){
alert("bye")
});

if (oneVar)
{
noThingHere();
} else { doThingHere(); }
</pre>

Note:
* Variables should be marked with "var"
* Semicolons should be used
* Keep as close to 80 cols as possible
* Use 2 space per indentation
* Open curly braces after parenthesis for functions and close on a new line
* Use camelCase for function names and variable names

Make use of running your Javascript through jshint we have a .jshint configuration file in that js directory (toastergui/static/js)

e.g. install jshint and add to your current PATH, then run:
<code>
$ npm install jshint; export PATH=$PATH:$PWD/node_modules/.bin/
$ jshint ./toastergui/static/js/base.js
</code>

=== HTML ===

'''Yes please:'''
<pre>
<div id="something-area">
<p class="important">This is some text</p>
</div>

<div>
<p id="important-text>This is some text</p>
</div>

</pre>

'''No thank you:'''
<pre>
<div id="somethingarea">
<p class="Important">This is some text</p></div>
<div id="somethingarea">
<p id="ImportantText">This is
some text
</p>

</div>
</pre>

Note:
* 2 space indentation
* Lower case, ids hyphenated when multiple words
* No duplicate ids

* Run your HTML through a [http://validator.w3.org/#validate_by_input HTML validator] available for [http://validator.w3.org/source/ local install]. The w3c validator it's self doesn't currently validate html5, it uses as a back end [https://validator.github.io/validator/ Nu Html Checker] which can be installed as a standalone service, full instructions in the readme.

Quick install instructions:
<pre>
$ mkdir html5-validator && cd html5-validator
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
$ git clone https://github.com/validator/validator.git
$ python build/build.py all
$ python build/build.py all
</pre>

HTML can be indented quickly using tidy, for example:
<pre>
tidy -xml --indent auto --indent-spaces 2 --quiet yes -w -1 --show-body-only yes ./index.html
</pre>

=== Python ===

Lenient [https://www.python.org/dev/peps/pep-0008 pep8]
Ignoring most of the whitespace around character issues (E124,E203,E201,E265,E303,E302,E231) see toaster/.pep8 and [http://pep8.readthedocs.org/en/latest/intro.html#error-codes error code list]

Fix all issues identified by running code through pep8. We have a fairly lenient config file (toaster/.pep8).

e.g.
<code>
$ pep8 ./toastergui/urls.py
</code>

Run code through pylint and fix identified issues - Some can be reasonably ignored such as doc strings for every function or star-args. No pylintrc config provided here as most issues identified are highly contextual and should be ignored on a case by case basis.

<code>
$ pylint --load-plugins pylint_django toastergui/tests.py
</code>

== Working with design ==

Yes, the Yocto Project is one of those lucky projects with designers around to help in UI matters. We have a document explaining how to work with the design contributors: [[File:Working_with_design.pdf]]

File:Dashboard.png

2016-08-16T16:33:51Z

Belenbarrospena: Belenbarrospena uploaded a new version of "File:Dashboard.png"

File:Dashboard.png

2016-08-16T16:32:37Z

Belenbarrospena:

File:Design review outcome.pdf

2016-07-08T16:12:59Z

Belenbarrospena:

What's New In 2.1

2016-05-06T13:53:13Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:
* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.
<gallery>
File:Image_customisation.png|Image customisation
File:Separate_build_dirs.png|Isolated project configurations
File:Build_cancellation.png|Cancel builds from the Toaster web interface
File:Multiple-release-support.png|Support for building two stable releases
File:Improved_build_stats.png|Improved build statistics data
File:Filter_by_date.png|Date filers for builds
File:Provides_info.png|PROVIDES information for recipe dependencies
</gallery>

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:52:43Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:
<gallery>
File:Image_customisation.png|Image customisation
File:Separate_build_dirs.png|Isolated project configurations
File:Build_cancellation.png|Cancel builds from the Toaster web interface
File:Multiple-release-support.png|Support for building two stable releases
File:Improved_build_stats.png|Improved build statistics data
File:Filter_by_date.png|Date filers for builds
File:Provides_info.png|PROVIDES information for recipe dependencies
</gallery>
* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

File:Provides info.png

2016-05-06T13:52:15Z

Belenbarrospena:

File:Filter by date.png

2016-05-06T13:48:34Z

Belenbarrospena:

File:Improved build stats.png

2016-05-06T13:47:48Z

Belenbarrospena:

What's New In 2.1

2016-05-06T13:47:17Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.
<gallery>
File:Image_customisation.png|Image customisation
File:Separate_build_dirs.png|Isolated project configurations
File:Build_cancellation.png|Cancel builds from the Toaster web interface
File:Multiple-release-support.png|Support for building two stable releases
</gallery>

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

File:Multiple-release-support.png

2016-05-06T13:46:25Z

Belenbarrospena: Belenbarrospena uploaded a new version of "File:Multiple-release-support.png"

File:Multiple-release-support.png

2016-05-06T13:45:50Z

Belenbarrospena:

What's New In 2.1

2016-05-06T13:42:30Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.
<gallery>
File:Image_customisation.png|Image customisation
File:Separate_build_dirs.png|Isolated project configurations
File:Build_cancellation.png|Cancel builds from the Toaster web interface
</gallery>

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

File:Build cancellation.png

2016-05-06T13:41:38Z

Belenbarrospena:

What's New In 2.1

2016-05-06T13:40:16Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.
<gallery>
File:Image_customisation.png|Image customisation
File:Separate_build_dirs.png|Isolated project configurations
</gallery>

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:39:40Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|frameless|thumb|right|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
[[File:Separate_build_dirs.png|frameless|thumb|right|Separate build directories per project]]
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.
<gallery>
File:Image_customisation.png|Image customisation
File:Separate_build_dirs.png|Separate build directories per project
</gallery>

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:38:52Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|frameless|thumb|right|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
[[File:Separate_build_dirs.png|frameless|thumb|right|Separate build directories per project]]
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.
<gallery>
File:Image_customisation.png|caption|Image customisation
File:file_name.ext|caption|Separate build directories per project
</gallery>

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:37:35Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|frameless|thumb|right|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
[[File:Separate_build_dirs.png|frameless|thumb|right|Separate build directories per project]]
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

File:Separate build dirs.png

2016-05-06T13:36:34Z

Belenbarrospena:

What's New In 2.1

2016-05-06T13:35:36Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|frameless|thumb|right|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:34:21Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|none|50px|frameless|right|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:33:30Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|none|600px|frameless|left|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:32:44Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|none|600px|thumb|left|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

What's New In 2.1

2016-05-06T13:29:22Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
[[File:Image_customisation.png|600px|thumb|left|Image customisation in Toaster]]
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

File:Image customisation.png

2016-05-06T13:27:24Z

Belenbarrospena:

What's New In 2.1

2016-05-06T11:10:30Z

Belenbarrospena: /* Toaster */

{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"
|This page is a draft - needs more screenshots and possibly copy-editing.'''
|}

= What's new in the Yocto Project 2.1 release =

As with most Yocto Project releases, the Yocto Project 2.1 "krogoth" release comes with a large number of changes in different areas. If one were to try to extract a general theme for 2.1 however it would probably be cleaning out the dusty corners of the system, as well as finishing off some functionality that has been a long time in the making. This guide doesn't cover all changes (in fact, it doesn't cover the hundreds of bugfixes and minor tweaks made since the last release) but attempts to give an overview of the most visible improvements.

== General ==

There was the usual crop of recipe upgrades (~240 recipes upgraded), headed with an upgrade of the Linux kernel to 4.4 (plus 4.1 for the stable LTSI kernel), gcc 5.3 and glibc 2.3. While we are on the topic of C libraries, the musl size-optimised C library has been upgraded and fully integrated in this release - whilst there was some earlier support via the addition of an extra layer in previous releases, musl can now be built out of the box and in fact is now used in the reference "poky-tiny" distribution, replacing the earlier pared down glibc configuration.

'''Full GObject introspection support''' replaces the stub support available in previous releases. This enables better support for building applications that make use of GObject introspection (e.g. anything implemented using language bindings for GTK+3, which includes parts of the GNOME stack). The caveat is that QEMU system emulation must be supported for the target architecture in order to support this.

The '''uninative''' feature which allows shared state to be used across different host distributions more effectively has been extended and enabled by default in the Poky reference distribution. An inc file (meta/conf/distro/include/yocto-uninative.inc) has been created to make this easier to incorporate into your custom distro configuration if desired.

'''Static library generation is now disabled for most recipes''' by default in the Poky reference distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Static libraries are disabled through an inc file (meta/conf/distro/include/no-static-libs.inc) making this easier to incorporate into your custom distro configuration if desired.

'''.debug directories are now automatically packaged''' in the -dbg package - now it no longer matters where you install binaries, their split out debug symbols will always go into the -dbg package instead of triggering a QA error/warning that you needed to resolve. Additionally, build sysroot paths are now excluded from debug symbol files as part of a wider effort to remove build path dependent binary output.

Added optional support for '''signing ipk packages as well as shared state artifacts'''.

Added an '''npm module fetcher''' to BitBake and corresponding support class in OE-Core (requires separate nodejs recipe). Because of the way npm fetches dependencies as part of its operation, it was previously difficult to write reliable recipes for npm recipes - modules were fetched on the fly and outside of the do_fetch task, leading to problems with reproducibility as well as the inability to work behind a network proxy.

'''Switching PREFERRED_PROVIDER to another virtual/* providers now results in old files being removed''' from the sysroot; earlier this would likely result in "The recipe <recipe> is trying to install files into a shared area when those files already exist" errors, requiring either explicit cleanup or simply deleting TMPDIR and restarting the build.

The runqemu script for more easily starting the QEMU system emulator gained support for qcow2 and vdi images, as well as images produced by the wic tool.

Dependencies on busybox can now be replaced relatively easily with another provider (e.g. toybox).

'''bash-completion''' has been imported from the meta-oe layer, providing optional support for extensible auto-completion when the bash shell is installed. Bash completion support has been added to individual recipes; this is placed in a separate -bash-completion package so that it can be installed separately if desired.

'''swupd (The SoftWare UPDater)''' from Clear Linux provides a new way of adding functionality to and updating a Linux-based OS. swupd uses binary-delta technology to efficiently update only the files that have changed between OS updates. This means that updates are small, resulting in fast downloads, and fast to apply. swupd is made available as a separate meta-swupd layer alongside the Yocto Project 2.1 release. See https://wiki.yoctoproject.org/wiki/Meta-swupd for more information.

== Optimisation and cleanup ==

* '''The Hob UI has now been removed'''. Hob, which uses GTK+2, has been largely unmaintained for several releases. The Toaster web-based UI now provides all of the functionality of Hob, plus much more. See below for further information on Toaster.

* '''The Application Developer Toolkit (ADT) has also been removed''' for 2.1, having been functionally replaced by the standard and extensible SDKs. (The Eclipse plugin is unaffected by this change however.) More details on the extensible SDK below.

* The troublesome '''"-e MAKEFLAGS=" has finally been removed from default EXTRA_OEMAKE'''. This was a historical accident and was something which recipe writers often needed to work around. Additionally, libexecdir has been reverted to ${prefix}/libexec to be in line with other distributions.

* '''The meta-yocto layer has been renamed to meta-poky''' to better match its purpose, which is to provide the Poky reference distribution. (The meta-yocto-bsp layer retains its original name since it provides reference machines for the Yocto Project and it is otherwise unrelated to Poky.)

* '''All support for Qt 4.x has been moved out to a separate meta-qt4 layer''' since Qt 4 is no longer supported upstream. See the OpenEmbedded Layer Index for more information on [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt4/ meta-qt4]. Newer Qt-based applications can make use of the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ meta-qt5] layer, which is actively maintained by the OpenEmbedded community.

* '''libjpeg has been replaced by libjpeg-turbo''' - most of the major Linux distributions have made this move already. libjpeg-turbo retains the stable API/ABI of libjpeg 8 and also takes advantage of acceleration features available on some platforms.

* '''libav has been replaced by ffmpeg'''. Again, most of the major Linux distributions have made this move already - for some background see [https://lwn.net/Articles/650816/ this article from LWN].

* '''udev has been replaced by eudev''' - for those still using SysV init (which is still the default) an update of the standalone udev was required as part of support for the Linux kernel 4.4 upgrade. The easiest course of action here turned out to be to migrate to the latest stable version of Gentoo's [https://wiki.gentoo.org/wiki/Eudev eudev] fork.

* The first step in moving towards the changing the default of the expand parameter in '''d.getVar()''' from False to True has been made by removing the default and making the parameter mandatory. This will force specifying the value; in a future release once layer maintainers have had a chance to adapt, a default of True will be set up.

== Toaster ==

'''Toaster''', the web-based UI for interacting with BitBake and OpenEmbedded, saw significant work in this release. Improvements include:

* '''Image customization:''' Toaster now allows you to create you own custom images, by modifying the package content of existing ones. Toaster provides dependency information for easy package addition and removal, builds your custom images, and generates a recipe (.bb) file that you can download.
* '''Isolated project configurations:''' Toaster now creates a separate build directory per project, avoiding build failures caused by the reuse of intermediate build artifacts. This provides cleaner configurations that can be easily shared, and improves build reliability. Shared state artifacts and downloads are still shared by default but this can be configured per project if desired.
* '''Cancel builds from the Toaster web interface:''' you can now cancel the builds you start from the Toaster web interface with a single click, without having to switch to the command line interface.
* '''Improved interaction with BitBake:''' we have removed the need for the BitBake observer process, and we run the BitBake server only during the build, stopping it once the build is done. We have also returned to executing the BitBake server from the selected project release (Yocto Project 2.0 or 2.1), while the BitBake client runs from the same codebase used to start Toaster. This allows us to provide backward compatibility with the previous stable release of the Yocto Project (2.0), enabling the next feature in this list
* '''Support for building two stable releases:''' Yocto Project 2.1 "Krogoth" and Yocto Project 2.0 "Jethro" releases, and/or the OpenEmbedded jethro and krogoth branches. Toaster also builds the development branch (master).
* '''Upgraded to Django 1.8.x from 1.6.x''': Django 1.8 has been designated as a Long Term Support release, with extended support until at least April 2018.
* '''Improved build statistics data:''' following changes to buildstats, Toaster now provides a more accurate measure of Disk I/O per task, and displays both system and user CPU time.
* '''Fix date filters for builds:''' ensure you can retrieve a subset of builds by specifying a date range.
* '''Show PROVIDES information in recipe dependencies:''' Toaster now identifies recipe build dependencies satisfied via the PROVIDES variable.

== Extensible SDK ==

The Extensible SDK (bitbake -c populate_sdk_ext) was introduced in preview form in the previous release, and builds on top of the standard SDK functionality with additional tools allowing developers to more easily add new applications / libraries to the build, modify the source of existing components, test changes on the target and integrate them into a system image. In 2.1 it has been solidified with the following added features:

* '''Support for building a minimal (~35MB) SDK installer''' with the rest installed on-demand from shared state
* '''Ability to bring in pkgdata for world''', which improves dependency mapping when adding new components through "devtool add" as well as the ability to find recipes by keyword using "devtool search"
* '''Added the ability to produce a derivative SDK installer''' containing items in the workspace in prebuilt form

Going together with this, a '''new [http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html SDK Manual]''' has been written providing information on how to use (and build) the standard SDK, extensible SDK and also how to install and use the Eclipse plugin.

== devtool ==

The '''devtool''' command is at the heart of the aforementioned extensible SDK, but is also available as a tool alongside a standard installation of the build system. It provides subcommands to add new software (auto-generating a recipe based on a source tree), modify the source of an existing recipe, easily deploy installed output to the target device, generate patches from source changes, and more. Improvements to devtool in 2.1 include:

* '''Proper support for modifying the kernel source''' - "devtool modify virtual/kernel" will not only check out the source tree for the kernel but also now correctly set up the initial configuration specified via the recipe.
* '''New "edit-recipe" subcommand''' to quickly edit created recipes
* '''New "configure-help" subcommand''' which presents the current value of EXTRA_OECONF and the output of the configure script's --help option (if applicable) to make setting configure arguments in a recipe a bit easier
* '''New "sync" subcommand''' to synchronise a previously extracted source tree with upstream
* Improved the presentation of commands in the help text, and simplified command-line usage for the add and modify subcommands
* '''Deployment to the target has been reworked''' - deploy-target now preserves any existing files and writes the deployed files list to the target device; undeploy-target restores previously existing files and can now be directed to undeploy all deployed recipes at once.

The "devtool add" command which auto-generates a recipe for a source tree internally uses "recipetool create" to do just the recipe creation process. recipetool create has been enhanced as follows:
* Support for extracting dependencies from cmake files
* Significantly improved autotools support
* Basic support for generating custom kernel recipes based on the linux-yocto-custom template
* Support for npm fetcher/class
* Support for out-of-tree kernel modules
* Extract recipe name/version from filename, github/bitbucket URLs, build scripts so that these don't always need to be specified
* Extract SRC_URI from the remote in a local git repository if specified
* Improved license detection - new "crunching" technique to ignore formatting differences between license texts that would otherwise prevent automated matching
* Support creating native variants or standalone native/nativesdk recipes
* Support specifying a subdirectory within the fetched source - useful when adding a recipe for a subcomponent of a source tree (where the source tree structure permits this)
* Handle <nowiki>https://....git</nowiki> URLs - BitBake expects git:// so any URLs in the former form will be converted
* Allow extension of recipe creation process through additional layers - e.g. adding meta-qt5 now enables support for creating recipes for Qt5-using software

Additionally, when externalsrc is in use shortcut symlinks for the work directory and logs directory are now created during do_configure. This will be mostly visible in the context of building a recipe when using devtool modify, devtool add or devtool upgrade (all of which make use of the externalsrc class).

You can find more information on devtool in the [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Yocto Project Development Manual].

== Images ==

The following improvements have been made to building images:

* '''Image generation is now split out from filesystem generation''' - i.e. turning the filesystem into the various image file formats, e.g. tar.gz and ext3, is now done in separate tasks. This not only simplifies the code but also makes it more visible as to what part of the process is being run at a given time - instead of a long-running do_rootfs you'll see a slightly shorter do_rootfs followed by several do_image_* tasks, one per type specified in IMAGE_FSTYPES.
* '''Write out an image license manifest''', which includes other image dependencies such as bootloaders. These may not part of the actual image file (depending on the type) but are associated with it and thus this new manifest gives a complete picture of the licenses of the software shipped with the image.
* '''Support chaining compression''' (aka conversion) commands and use to allow producing checksums for images
* Allow vm and live image types to be built at the same time

The "wic" standalone image creator has seen a couple of improvements:
* Allow specifying a custom config for the bootloader
* Implement includes in wks files

The mkefidisk.sh script has seen a couple of improvements as well:

* Display boot log on console
* Added a startup script for automated boot

== BitBake ==

Unless you're familiar with the code it can sometimes be hard to determine where BitBake ends and OpenEmbedded starts, but BitBake the tool does remain independent of the OE metadata even though it is developed alongside it. Improvements to bitbake in this release include:

* Set process names to be meaningful - here's some output from pstree demonstrating the new naming:

└─bash───KnottyUI───Cooker─┬─Worker─┬─fixesproto:conf───run.do_configur───configure
│ ├─fontconfig:conf───run.do_configur───autoreconf─┬─autoheader───sh───autom4te───sh───m4
│ │ └─autom4te
│ ├─groff-native:co───run.do_configur───configure───configure───g++─┬─as
│ │ └─cc1plus
│ ├─icu-native:conf───run.do_configur───configure───sh
│ ├─libpng:configur───run.do_configur───autoreconf─┬─autom4te
│ │ └─automake───autom4te
│ ├─libusb1:configu───run.do_configur───autoreconf───autom4te
│ └─libxext:configu───run.do_configur───configure
├─pseudo───Worker (Fakeroo
├─2*[{Cooker}]
└─{ProcessEQueue}
* Messages produced from within tasks are now always prefixed with the recipe/task name, avoiding the problem of confusing warning/error messages with no context
* Added support for unpacking 7-Zip archives
* Added --setscene-only option to only run setscene tasks (i.e. in OE context this means only tasks whose output can be restored from shared state).
* Added ability to build up to but not including a task
* Provide more information with "multiple .bb files are due to be built" message
* List close matching runtime providers with close matches when invalid target specified
* Allow BBMASK to contain multiple regular expressions
* Adjust styling of graph lines for RRECOMMENDS and RDEPENDS in -g output so that the difference between these is clearer

== Further information ==

As always, the reference manual provides a section on [http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.1-release Moving to the Yocto Project 2.1 Release] which you should definitely read if you are upgrading.

The [https://lists.yoctoproject.org/pipermail/yocto-announce/2016-May/000089.html 2.1 release notes] cover the above information in slightly briefer form along with other information including a list of upgraded recipes and security fixes.

Toaster

2016-04-27T16:52:38Z

Belenbarrospena: /* About Toaster */

[[Category:Toaster]]
[[Toaster]] is a web-based interface to OpenEmbedded and BitBake.
[[File:Screenshot toaster.png|thumb|Screenshot of Toaster 2.1]]
General discussion about '''Toaster''' happens on a dedicated mailing list: [https://lists.yoctoproject.org/listinfo/toaster https://lists.yoctoproject.org/listinfo/toaster]

=== Using Toaster ===

Toaster can run in various modes and setups.

* '''Local mode''' - in this mode Toaster is setup for use as a local development tool. It can be used to configure builds or just as a receiver for builds done on the command line with bitbake. You can launch it like this:

$ source oe-init-build-env
$ source toaster start

You then navigate to the link in your browser (e.g. http://localhost:8000) and configure a project. Or start building in the normal way with bitbake via the command line. Toaster will automatically pick up the builds and you will be able to see them on the build dashboard in your browser.

* '''Production mode''' - All the same functionality as the local mode but with the web server setup as a shared service for multiple developers to use, this sets up Toaster as a wsgi application and [[Setting up a production instance of Toaster|requires additional configuration]].

=== Toaster How-to's ===

Specific pages with Toaster how-tos are available below.

* [[Contribute to Toaster]]
* [[Testing Toaster]]
* [[Setting up a local instance of Toaster]]
* [[Setting up a production instance of Toaster]] - documentation for Interactive mode
* [https://www.yoctoproject.org/documentation/toaster-manual-18 How to use the Toaster web interface]
* [[How to delete information from the Toaster database]]
* [[How to support permission management in Build Mode for Toaster]]
* [[ToasterTable]]: Toaster's internal API for adding sortable, filterable, paged tables

=== About Toaster ===
[[File:Screenshot toaster analyis.png|thumb|Analysis of builds using Toaster]]

* [[File:Working_with_design.pdf]]
* [https://bugzilla.yoctoproject.org/buglist.cgi?list_id=213820&columnlist=status_whiteboard%2Cassigned_to%2Ctarget_milestone%2Cbug_status%2Cshort_desc%2Cbug_severity%2Cpriority&classification=Build%20System%20%26%20Metadata&query_based_on=Toaster-Opens&query_format=advanced&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&component=toaster&product=Toaster&known_name=Toaster-Opens Bug list]
* [[Toaster architecture design]]
* [[Toaster and bitbake communications]]
* [[Toaster database]]
* [[Toaster testing plan]]

=== In progress documentation ===

We are currently preparing the documentation for the Toaster build functionality. The content here is just a brain dump of what we need to cover (in no particular order). Feel free to add and create content as you see fit:

*[[Using virtualenv]]
*[[Setting up a production instance of Toaster]]
*[[manage.py commands]] - this should include an explanation of lsupdates
*[[Start Toaster in managed mode]]

Toaster future release planning

2016-04-25T16:13:30Z

Belenbarrospena: /* 2.2 release */

[[Category:Toaster]]

== 2.2 Planning ==

=== Wish lists ===

==== Michael's ====
* Remove pseudo API cruft / template context to json response stuff
* Remove bldcontrol (we only need localhostbecontroller.py)
* Look at schema and rework where needed
* Consolidate used API into it's own view
* Finish toaster tables porting
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line
* Drop supporting old releases

==== Brian's ====
The Ordered Part
# Django 1.8 aka LTS
# Image Customization
# Testing and Stability
# One way to start/One code path
<br>
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

===== 2.2 release =====

* Move to Bootstrap 3 ([https://bugzilla.yoctoproject.org/show_bug.cgi?id=9517 Bugzilla entry 9517])
* Clean up all the small little bugs in the Toaster UI
* Provide a better way to build the extensible SDK from Toaster ([https://bugzilla.yoctoproject.org/show_bug.cgi?id=9297 Bugzilla entry 9297])
* Improve the variable history ([https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811 Bugzilla entry 5811])

===== 2.1 release =====

* Implement new custom theme (already in progress, aiming for end of M1: Dec 7th). Related bugs: 8417
* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

==== Sujith's ====

* Get toaster working with non-git repos. Related bugs: 8456
* minor, but would be good to have :- Once user launches toaster, it would be nice to see the progress bar updated without user refreshing the page. Related bugs: 8328
* Cancellation of build. Related bugs: 6787

Would love to take up more tasks.

==== David's ====

* Finish the effort around Toaster "extensions", started by Farrell. This will enable Toaster customization for commercial partners, as per branding and
alternate pages (for extended project creation).

== All bugs for 2.2 ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4,2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|product=Toaster
|resolution=!fixed
|status=!IN PROGRESS REVIEW
}}

== Toaster Enhancements for 2.2 ==
{{#bugzilla:
|columns=id,to,estimated,summary,priority,from,qa,milestone,status,resolution,whiteboard
|milestone=2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|severity=enhancement
|product=Toaster
|status=!verified
}}

Toaster future release planning

2016-04-25T16:11:26Z

Belenbarrospena: /* 2.2 release */

[[Category:Toaster]]

== 2.2 Planning ==

=== Wish lists ===

==== Michael's ====
* Remove pseudo API cruft / template context to json response stuff
* Remove bldcontrol (we only need localhostbecontroller.py)
* Look at schema and rework where needed
* Consolidate used API into it's own view
* Finish toaster tables porting
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line
* Drop supporting old releases

==== Brian's ====
The Ordered Part
# Django 1.8 aka LTS
# Image Customization
# Testing and Stability
# One way to start/One code path
<br>
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

===== 2.2 release =====

* Move to Bootstrap 3
* Clean up all the small little bugs in the Toaster UI
* Provide a better way to build the extensible SDK from Toaster ([https://bugzilla.yoctoproject.org/show_bug.cgi?id=9297 Bugzilla entry 9297])
* Improve the variable history ([https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811 Bugzilla entry 5811])

===== 2.1 release =====

* Implement new custom theme (already in progress, aiming for end of M1: Dec 7th). Related bugs: 8417
* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

==== Sujith's ====

* Get toaster working with non-git repos. Related bugs: 8456
* minor, but would be good to have :- Once user launches toaster, it would be nice to see the progress bar updated without user refreshing the page. Related bugs: 8328
* Cancellation of build. Related bugs: 6787

Would love to take up more tasks.

==== David's ====

* Finish the effort around Toaster "extensions", started by Farrell. This will enable Toaster customization for commercial partners, as per branding and
alternate pages (for extended project creation).

== All bugs for 2.2 ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4,2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|product=Toaster
|resolution=!fixed
|status=!IN PROGRESS REVIEW
}}

== Toaster Enhancements for 2.2 ==
{{#bugzilla:
|columns=id,to,estimated,summary,priority,from,qa,milestone,status,resolution,whiteboard
|milestone=2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|severity=enhancement
|product=Toaster
|status=!verified
}}

Toaster future release planning

2016-04-25T16:09:39Z

Belenbarrospena: /* 2.2 release */

[[Category:Toaster]]

== 2.2 Planning ==

=== Wish lists ===

==== Michael's ====
* Remove pseudo API cruft / template context to json response stuff
* Remove bldcontrol (we only need localhostbecontroller.py)
* Look at schema and rework where needed
* Consolidate used API into it's own view
* Finish toaster tables porting
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line
* Drop supporting old releases

==== Brian's ====
The Ordered Part
# Django 1.8 aka LTS
# Image Customization
# Testing and Stability
# One way to start/One code path
<br>
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

===== 2.2 release =====

* Move to Bootstrap 3
* Clean up all the small little bugs in the Toaster UI
*
* Improve the variable history [https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811 Bugzilla entry 5811]

===== 2.1 release =====

* Implement new custom theme (already in progress, aiming for end of M1: Dec 7th). Related bugs: 8417
* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

==== Sujith's ====

* Get toaster working with non-git repos. Related bugs: 8456
* minor, but would be good to have :- Once user launches toaster, it would be nice to see the progress bar updated without user refreshing the page. Related bugs: 8328
* Cancellation of build. Related bugs: 6787

Would love to take up more tasks.

==== David's ====

* Finish the effort around Toaster "extensions", started by Farrell. This will enable Toaster customization for commercial partners, as per branding and
alternate pages (for extended project creation).

== All bugs for 2.2 ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4,2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|product=Toaster
|resolution=!fixed
|status=!IN PROGRESS REVIEW
}}

== Toaster Enhancements for 2.2 ==
{{#bugzilla:
|columns=id,to,estimated,summary,priority,from,qa,milestone,status,resolution,whiteboard
|milestone=2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|severity=enhancement
|product=Toaster
|status=!verified
}}

Toaster future release planning

2016-04-25T16:08:46Z

Belenbarrospena: /* 2.2 release */

[[Category:Toaster]]

== 2.2 Planning ==

=== Wish lists ===

==== Michael's ====
* Remove pseudo API cruft / template context to json response stuff
* Remove bldcontrol (we only need localhostbecontroller.py)
* Look at schema and rework where needed
* Consolidate used API into it's own view
* Finish toaster tables porting
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line
* Drop supporting old releases

==== Brian's ====
The Ordered Part
# Django 1.8 aka LTS
# Image Customization
# Testing and Stability
# One way to start/One code path
<br>
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

===== 2.2 release =====

* Move to Bootstrap 3
* Clean up all the small little bugs in the Toaster UI
*
* Improve the variable history [https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811|Bugzilla entry 5811 ]

===== 2.1 release =====

* Implement new custom theme (already in progress, aiming for end of M1: Dec 7th). Related bugs: 8417
* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

==== Sujith's ====

* Get toaster working with non-git repos. Related bugs: 8456
* minor, but would be good to have :- Once user launches toaster, it would be nice to see the progress bar updated without user refreshing the page. Related bugs: 8328
* Cancellation of build. Related bugs: 6787

Would love to take up more tasks.

==== David's ====

* Finish the effort around Toaster "extensions", started by Farrell. This will enable Toaster customization for commercial partners, as per branding and
alternate pages (for extended project creation).

== All bugs for 2.2 ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4,2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|product=Toaster
|resolution=!fixed
|status=!IN PROGRESS REVIEW
}}

== Toaster Enhancements for 2.2 ==
{{#bugzilla:
|columns=id,to,estimated,summary,priority,from,qa,milestone,status,resolution,whiteboard
|milestone=2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|severity=enhancement
|product=Toaster
|status=!verified
}}

Toaster future release planning

2016-04-25T16:08:09Z

Belenbarrospena: /* 2.2 release */

[[Category:Toaster]]

== 2.2 Planning ==

=== Wish lists ===

==== Michael's ====
* Remove pseudo API cruft / template context to json response stuff
* Remove bldcontrol (we only need localhostbecontroller.py)
* Look at schema and rework where needed
* Consolidate used API into it's own view
* Finish toaster tables porting
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line
* Drop supporting old releases

==== Brian's ====
The Ordered Part
# Django 1.8 aka LTS
# Image Customization
# Testing and Stability
# One way to start/One code path
<br>
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

===== 2.2 release =====

* Move to Bootstrap 3
* Clean up all the small little bugs in the Toaster UI
*
* Improve the variable history [https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811 |Bugzilla entry 5811 ]

===== 2.1 release =====

* Implement new custom theme (already in progress, aiming for end of M1: Dec 7th). Related bugs: 8417
* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

==== Sujith's ====

* Get toaster working with non-git repos. Related bugs: 8456
* minor, but would be good to have :- Once user launches toaster, it would be nice to see the progress bar updated without user refreshing the page. Related bugs: 8328
* Cancellation of build. Related bugs: 6787

Would love to take up more tasks.

==== David's ====

* Finish the effort around Toaster "extensions", started by Farrell. This will enable Toaster customization for commercial partners, as per branding and
alternate pages (for extended project creation).

== All bugs for 2.2 ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4,2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|product=Toaster
|resolution=!fixed
|status=!IN PROGRESS REVIEW
}}

== Toaster Enhancements for 2.2 ==
{{#bugzilla:
|columns=id,to,estimated,summary,priority,from,qa,milestone,status,resolution,whiteboard
|milestone=2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|severity=enhancement
|product=Toaster
|status=!verified
}}

Toaster future release planning

2016-04-25T16:07:24Z

Belenbarrospena: /* Belén's */

[[Category:Toaster]]

== 2.2 Planning ==

=== Wish lists ===

==== Michael's ====
* Remove pseudo API cruft / template context to json response stuff
* Remove bldcontrol (we only need localhostbecontroller.py)
* Look at schema and rework where needed
* Consolidate used API into it's own view
* Finish toaster tables porting
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line
* Drop supporting old releases

==== Brian's ====
The Ordered Part
# Django 1.8 aka LTS
# Image Customization
# Testing and Stability
# One way to start/One code path
<br>
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

===== 2.2 release =====

* Move to Bootstrap 3
* Clean up of the small little bugs in the Toaster UI
* Improve the variable history [https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811 | Bugzilla entry 5811 ]

===== 2.1 release =====

* Implement new custom theme (already in progress, aiming for end of M1: Dec 7th). Related bugs: 8417
* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

==== Sujith's ====

* Get toaster working with non-git repos. Related bugs: 8456
* minor, but would be good to have :- Once user launches toaster, it would be nice to see the progress bar updated without user refreshing the page. Related bugs: 8328
* Cancellation of build. Related bugs: 6787

Would love to take up more tasks.

==== David's ====

* Finish the effort around Toaster "extensions", started by Farrell. This will enable Toaster customization for commercial partners, as per branding and
alternate pages (for extended project creation).

== All bugs for 2.2 ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4,2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|product=Toaster
|resolution=!fixed
|status=!IN PROGRESS REVIEW
}}

== Toaster Enhancements for 2.2 ==
{{#bugzilla:
|columns=id,to,estimated,summary,priority,from,qa,milestone,status,resolution,whiteboard
|milestone=2.2,2.2 M1,2.2 M2,2.2 M3,2.2 M4
|sort=priority
|severity=enhancement
|product=Toaster
|status=!verified
}}

Contribute to Toaster

2016-04-07T18:30:47Z

Belenbarrospena: /* Submitting patch sets for integration into Bitbake */

Contribute to Toaster

2016-04-07T18:30:08Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:29:48Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:29:22Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:20:30Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:20:00Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:18:59Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:18:25Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:17:56Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:17:09Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:16:12Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:15:59Z

Belenbarrospena: /* Submitting patches */

Contribute to Toaster

2016-04-07T18:14:01Z

Belenbarrospena: /* Submitting patch sets for integration into Bitbake */

Contribute to Toaster

2016-04-07T18:12:56Z

Belenbarrospena: /* Submitting patch sets for integration into Bitbake */

Contribute to Toaster

2016-04-07T18:11:06Z

Belenbarrospena: /* Submitting patch sets for integration into Bitbake */