https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&user=Scottrif&feedformat=atomYocto Project - User contributions [en]2024-03-28T10:28:43ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=Frequently_Asked_Release_Engineering_Questions&diff=46323Frequently Asked Release Engineering Questions2019-01-21T18:02:09Z<p>Scottrif: /* Danny? Dylan? Denzil? How can I find out the name of the next Yocto Project major release? */</p>
<hr />
<div>=== Frequently Asked Questions (Release Engineering) ==<br />
<br />
=== How often are these pages updated? Who updates them? ===<br />
<br />
The main Release wiki pages will be reviewed by the Yocto Project release engineer, half way between each major release and immediately after a major release, to ensure that information is kept up to date. <br />
<br />
=== When is the next major release? When is the next X.X.x release? ===<br />
<br />
We release major releases at a 6 month interval. Generally, odd numbered releases fall sometime in mid-late October, even releases fall mid-late April. The next major release is due out sometime around April 2014.<br />
<br />
Point releases are released on an adhoc basis.<br />
<br />
=== How long are point releases supported ===<br />
<br />
We will produce point releases of prior major releases:<br />
* to fix critical bugs and security issues (CVEs) for the first 6 months after release<br />
* to fix security issues(CVEs) for the first year after release<br />
<br />
From an autobuilder standpoint, we generally maintain autobuilder backwards compatibility for at least 5 major releases. This is slowly getting better, with the goal of being able to be backwards compatible for at least 3 years worth of releases.<br />
<br />
=== Danny? Dylan? Denzil? How can I find out the name of the next Yocto Project major release? ===<br />
<br />
We generally call the next major release by it's major.minor number up until about a month or so prior to the major release. <br />
In the spirit of full disclosure, we don't even know the name of the release until Richard Purdie comes up with it.<br />
<br />
The https://wiki.yoctoproject.org/wiki/Releases page of the wiki has a nice list of release numbers past and <br />
present. See that site for information.<br />
<br />
=== Where does the naming convention come from? ===<br />
<br />
It's a secret!<br />
<br />
=== How does the Yocto Project release software? ===<br />
<br />
The [[Yocto_Project_Release_Process | Yocto Project's Release Process]] establishes the full process for both major and point releases.<br />
<br />
=== How do I release my own board support package and put them up on the Yocto Project downloads site? ===<br />
<br />
The [[Third_Party_BSP_Release_Process | Third Party BSP Release Process]] establishes the full process for BSP releases.<br />
<br />
=== How do I maintain compliance with open source licenses? ===<br />
<br />
Coming Soon<br />
<br />
=== How do I release a product using the Yocto Project? ===<br />
<br />
Coming Soon<br />
<br />
=== meta-jarvis layer? kernel 0.98pl13? What is wrong with you people? ===<br />
<br />
Every major release includes an easter egg or two within the Yocto Project's release notes.<br />
<br />
Prior Easter Eggs included:<br />
<br />
* Implementation of a magic smoke generator<br />
* The meta-jarvis layer for the Iron Man suit<br />
* The meta-yocto-classic layer, which includes mc.<br />
<br />
Most of these are inside project jokes. For example, our community manager, Jeff "jefro" Osier-Mixon bears a resemblance to Robert Downey Jr. <br />
Richard Purdie has a love of mc. They're generally pretty obvious jokes, except when they're [https://plus.google.com/111049168280159033135/posts/hTcunXAqCHU not].</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43105Documentation Decoder2018-10-30T16:16:02Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
URLs use the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>.<br />
With this format, the "release" string specifies the Yocto Project release associated with the manual.<br />
The "name" string represents the manual's folder name.<br />
You can find the list of the current folder strings in the next section.<br />
<br />
Here is an example for the "Yocto Project Reference Manual" for release 2.4: <tt>http://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html</tt><br />
<br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43104Documentation Decoder2018-10-30T16:15:38Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
URLs use the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>.<br />
With this format, the "release" string specifies the Yocto Project release associated with the manual.<br />
The "name" string represents the manual's folder name.<br />
You can find the list of the current folder strings in the next section.<br />
<br />
Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
<br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43103Documentation Decoder2018-10-30T16:15:18Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
URLs use the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>.<br />
With this format, the "release" specifies the Yocto Project release associated with the manual.<br />
The "name" string represents the manual's folder name.<br />
You can find the list of the current folder strings in the next section.<br />
<br />
Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
<br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43102Documentation Decoder2018-10-30T16:14:23Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
URLs use the following format: http://www.yoctoproject.org/docs/<release>/<name>/<name>.html.<br />
With this format, the "release" specifies the Yocto Project release associated with the manual.<br />
The "name" string represents the manual's folder name.<br />
You can find the list of the current folder strings in the next section.<br />
<br />
Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
<br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43101Documentation Decoder2018-10-30T16:13:52Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
URLs use the following format: <tt>http://www.yoctoproject.org/docs/<release>/<name>/<name>.html</tt>.<br />
With this format, the "release" specifies the Yocto Project release associated with the manual.<br />
The "name" string represents the manual's folder name.<br />
You can find the list of the current folder strings in the next section.<br />
<br />
Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
<br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43100Documentation Decoder2018-10-30T16:12:54Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
URLs use the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>.<br />
With this format, the "release" specifies the Yocto Project release associated with the manual.<br />
The "name" string represents the manual's folder name.<br />
You can find the list of the current folder strings in the next section.<br />
<br />
Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
<br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43099Documentation Decoder2018-10-30T16:10:20Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what.<br />
You should be sure that an URL returned by a search engine represents the actual version of the manual in which you are interested. <br />
Searches many times return very old versions of a manual.<br />
<br />
:URLs have the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>. <br />
: Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43098Documentation Decoder2018-10-30T16:08:47Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what. <br />
:URLs have the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>. <br />
: Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br />
For example, to access the latest Yocto Project Development Tasks Manual, use the <tt>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html</tt> URL.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43097Documentation Decoder2018-10-30T16:07:11Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what. <br />
:URLs have the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>. <br />
: Here is an example for the "Yocto Project Reference Manual" for release 2.5.1: <tt>http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html</tt><br />
You can use the string <tt>current</tt> rather than a specific release number (e.g. 2.5.1) to go to the latest released version of a manual.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=43096Documentation Decoder2018-10-30T16:03:19Z<p>Scottrif: /* List of Manual Pages */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what. <br />
:URLs have the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>. <br />
: Here is an example for the "Yocto Project Reference Manual" for release 2.1.1: <tt>http://www.yoctoproject.org/docs/2.1.1/ref-manual/ref-manual.html</tt><br />
Note that <tt>current</tt> can be used in place of the current release number.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes.<br />
This list represents the latest Yocto Project release:<br />
:[http://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html brief-yoctoprojectqs]. A very brief quick start to get you going.<br />
:[http://www.yoctoproject.org/docs/current/overview-manual/overview-manual.html overview-manual]. Presents Yocto Project overview and conceptual information.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. A development tasks manual. Provides procedures for common and not-so-common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to build and use Yocto Project SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a Board Support Package (BSP)layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. The kernel development manual, which is often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/profile-manual/profile-manual.html profile-manual] Presents information on profiling and tracing.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Describes how to use "Toaster". which is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Gathers together Yocto Project reference material, which consists of variable descriptions, class descriptions, and so forth.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one "mega manual". You can use this manual to quickly search for terms and stings throughout the Yocto Project manual set.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40918Distribution Support2018-08-02T02:07:10Z<p>Scottrif: /* Distro test coverage */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
<br />
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "[https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual.<br />
<br />
<br />
<pre>Example of distro list in poky.conf:<br />
<br />
SANITY_TESTED_DISTROS ?= " \<br />
poky-2.4 \n \<br />
poky-2.5 \n \<br />
ubuntu-15.04 \n \<br />
ubuntu-16.04 \n \<br />
ubuntu-16.10 \n \<br />
ubuntu-17.04 \n \<br />
fedora-26 \n \<br />
centos-7 \n \<br />
debian-8 \n \<br />
debian-9 \n \<br />
opensuse-42.1 \n \<br />
opensuse-42.2 \n \<br />
"<br />
</pre><br />
Again, the previous listing is just an example and is not meant to be a definitive reference. <br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
<br />
The criteria for adding a supported distro is quite rigid. Obviously, any candidate distro must be of production quality. In other words, the distro is capable of being used in a production environment on a Yocto Project Autobuilder build worker. A compelling reason must also exist for the Yocto Project to actually use the distro on a build worker. Obscure, poorly supported, or highly customized distros are not likely to be good candidates for submission. Major stable distros (e.g. Debian, Fedora, Ubunto, Centos, and so forth.) are generally already supported. If they are not supported, they are likely on the list to become supported once sufficient criteria are met. Please be sure to check the latest supported distros beforehand to make sure the distro in question is not already supported.<br />
<br />
If you have a compelling reason to suggest a distro for support, please submit your request to the Yocto Project mailing list for discussion. You will likely be asked to provide the reasoning behind your request. Along with your request, relevant bug reports, failed test cases, and so forth are helpful. Have them ready in advance. <br />
<br />
If you are not already a member of the Yocto Project mailing list, you can find more information and subscription requirements here: [https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto].<br />
<br />
The Yocto Project mailing list is also the right place for more general questions or issues surrounding distro support.<br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
<br />
<br />
Distro Testing is intended to reveal bugs that are distribution-specific using the yocto-autobuilder. The tests all run on identical hardware and use each updated OS.<br />
<br />
For detailed information on Distro testing, please see [[Distro_Testing_Plan]].<br />
<br />
For more information on the overall QA testing plan, please see [[QA_Master_Test_Plan]]. (Comprehensive)</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40917Distribution Support2018-08-02T02:04:47Z<p>Scottrif: /* How to add a new entry or additional distro information */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
<br />
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "[https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual.<br />
<br />
<br />
<pre>Example of distro list in poky.conf:<br />
<br />
SANITY_TESTED_DISTROS ?= " \<br />
poky-2.4 \n \<br />
poky-2.5 \n \<br />
ubuntu-15.04 \n \<br />
ubuntu-16.04 \n \<br />
ubuntu-16.10 \n \<br />
ubuntu-17.04 \n \<br />
fedora-26 \n \<br />
centos-7 \n \<br />
debian-8 \n \<br />
debian-9 \n \<br />
opensuse-42.1 \n \<br />
opensuse-42.2 \n \<br />
"<br />
</pre><br />
Again, the previous listing is just an example and is not meant to be a definitive reference. <br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
<br />
The criteria for adding a supported distro is quite rigid. Obviously, any candidate distro must be of production quality. In other words, the distro is capable of being used in a production environment on a Yocto Project Autobuilder build worker. A compelling reason must also exist for the Yocto Project to actually use the distro on a build worker. Obscure, poorly supported, or highly customized distros are not likely to be good candidates for submission. Major stable distros (e.g. Debian, Fedora, Ubunto, Centos, and so forth.) are generally already supported. If they are not supported, they are likely on the list to become supported once sufficient criteria are met. Please be sure to check the latest supported distros beforehand to make sure the distro in question is not already supported.<br />
<br />
If you have a compelling reason to suggest a distro for support, please submit your request to the Yocto Project mailing list for discussion. You will likely be asked to provide the reasoning behind your request. Along with your request, relevant bug reports, failed test cases, and so forth are helpful. Have them ready in advance. <br />
<br />
If you are not already a member of the Yocto Project mailing list, you can find more information and subscription requirements here: [https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto].<br />
<br />
The Yocto Project mailing list is also the right place for more general questions or issues surrounding distro support.<br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
<br />
<br />
Distro Testing is intended to catch bugs that are distribution-specific using the yocto-autobuilder. The tests are all run on identical hardware and with each OS updated.<br />
<br />
For detailed information on Distro testing, please see [[Distro_Testing_Plan]].<br />
<br />
For more information on the overall QA testing plan, please refer to [[QA_Master_Test_Plan]]. (Comprehensive)</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40916Distribution Support2018-08-02T02:04:05Z<p>Scottrif: /* How to add a new entry or additional distro information */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
<br />
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "[https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual.<br />
<br />
<br />
<pre>Example of distro list in poky.conf:<br />
<br />
SANITY_TESTED_DISTROS ?= " \<br />
poky-2.4 \n \<br />
poky-2.5 \n \<br />
ubuntu-15.04 \n \<br />
ubuntu-16.04 \n \<br />
ubuntu-16.10 \n \<br />
ubuntu-17.04 \n \<br />
fedora-26 \n \<br />
centos-7 \n \<br />
debian-8 \n \<br />
debian-9 \n \<br />
opensuse-42.1 \n \<br />
opensuse-42.2 \n \<br />
"<br />
</pre><br />
Again, the previous listing is just an example and is not meant to be a definitive reference. <br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
<br />
The criteria for adding a supported distro is quite rigid. Obviously, any candidate distro must be of production quality. In other words, the distro is capable of being used in a production environment on a Yocto Project Autobuilder build worker. A compelling reason must also exist for the Yocto Project actually use the distro on a build worker. Obscure, poorly supported, or highly customized distros are not likely to be good candidates for submission. Major stable distros (e.g. Debian, Fedora, Ubunto, Centos, and so forth.) are generally already supported. If they are not supported, they are likely on the list to become supported once sufficient criteria are met. Please be sure to check the latest supported distros beforehand to make sure the distro in question is not already supported.<br />
<br />
If you have a compelling reason to suggest a distro for support, please submit your request to the Yocto Project mailing list for discussion. You will likely be asked to provide the reasoning behind your request. Along with your request, relevant bug reports, failed test cases, and so forth are helpful. Have them ready in advance. <br />
<br />
If you are not already a member of the Yocto Project mailing list, you can find more information and subscription requirements here: [https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto].<br />
<br />
The Yocto Project mailing list is also the right place for more general questions or issues surrounding distro support.<br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
<br />
<br />
Distro Testing is intended to catch bugs that are distribution-specific using the yocto-autobuilder. The tests are all run on identical hardware and with each OS updated.<br />
<br />
For detailed information on Distro testing, please see [[Distro_Testing_Plan]].<br />
<br />
For more information on the overall QA testing plan, please refer to [[QA_Master_Test_Plan]]. (Comprehensive)</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40915Distribution Support2018-08-02T01:57:01Z<p>Scottrif: /* Distribution Support */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
<br />
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "[https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual.<br />
<br />
<br />
<pre>Example of distro list in poky.conf:<br />
<br />
SANITY_TESTED_DISTROS ?= " \<br />
poky-2.4 \n \<br />
poky-2.5 \n \<br />
ubuntu-15.04 \n \<br />
ubuntu-16.04 \n \<br />
ubuntu-16.10 \n \<br />
ubuntu-17.04 \n \<br />
fedora-26 \n \<br />
centos-7 \n \<br />
debian-8 \n \<br />
debian-9 \n \<br />
opensuse-42.1 \n \<br />
opensuse-42.2 \n \<br />
"<br />
</pre><br />
Again, the previous listing is just an example and is not meant to be a definitive reference. <br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
<br />
The criteria for adding a distro to be supported is quite high. Obviously, any candidate distro would need to be production quality. That is, capable of being used in a production environment, on a Yocto Project Autobuilder build worker. There would also need to be a compelling reason for the Yocto Project to actually DO that. Obscure, poorly supported, or highly customized distros are not likely to be good candidates for submission. Major stable distros (Debian, Fedora, Ubunto, Centos, etc.) are generally already supported, or they are on the radar to be supported down the road when sufficient criteria are met. Please be sure to check the latest supported distros beforehand, to make sure it's not already supported.<br />
<br />
If you have a compelling reason to suggest a distro to support, please submit your request to the Yocto mailing list for discussion. You will likely be asked to provide the reasoning behind your request, so relevant bug reports, failed test cases, etc., would be helpful to have ready in advance. <br />
<br />
If you are not already a member of the Yocto mailing list, you may find more information about the list, and subscribe, here: https://lists.yoctoproject.org/listinfo/yocto.<br />
<br />
This is also the right place for more general question or issues around distro support.<br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
<br />
<br />
Distro Testing is intended to catch bugs that are distribution-specific using the yocto-autobuilder. The tests are all run on identical hardware and with each OS updated.<br />
<br />
For detailed information on Distro testing, please see [[Distro_Testing_Plan]].<br />
<br />
For more information on the overall QA testing plan, please refer to [[QA_Master_Test_Plan]]. (Comprehensive)</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40914Distribution Support2018-08-02T01:56:39Z<p>Scottrif: /* Distribution Support */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
<br />
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "[https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual.<br />
<br />
<br />
<pre>Example of distro list in poky.conf:<br />
<br />
SANITY_TESTED_DISTROS ?= " \<br />
poky-2.4 \n \<br />
poky-2.5 \n \<br />
ubuntu-15.04 \n \<br />
ubuntu-16.04 \n \<br />
ubuntu-16.10 \n \<br />
ubuntu-17.04 \n \<br />
fedora-26 \n \<br />
centos-7 \n \<br />
debian-8 \n \<br />
debian-9 \n \<br />
opensuse-42.1 \n \<br />
opensuse-42.2 \n \<br />
"<br />
</pre><br />
Again, this is just an example and is not meant to be a definitive reference. <br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
<br />
The criteria for adding a distro to be supported is quite high. Obviously, any candidate distro would need to be production quality. That is, capable of being used in a production environment, on a Yocto Project Autobuilder build worker. There would also need to be a compelling reason for the Yocto Project to actually DO that. Obscure, poorly supported, or highly customized distros are not likely to be good candidates for submission. Major stable distros (Debian, Fedora, Ubunto, Centos, etc.) are generally already supported, or they are on the radar to be supported down the road when sufficient criteria are met. Please be sure to check the latest supported distros beforehand, to make sure it's not already supported.<br />
<br />
If you have a compelling reason to suggest a distro to support, please submit your request to the Yocto mailing list for discussion. You will likely be asked to provide the reasoning behind your request, so relevant bug reports, failed test cases, etc., would be helpful to have ready in advance. <br />
<br />
If you are not already a member of the Yocto mailing list, you may find more information about the list, and subscribe, here: https://lists.yoctoproject.org/listinfo/yocto.<br />
<br />
This is also the right place for more general question or issues around distro support.<br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
<br />
<br />
Distro Testing is intended to catch bugs that are distribution-specific using the yocto-autobuilder. The tests are all run on identical hardware and with each OS updated.<br />
<br />
For detailed information on Distro testing, please see [[Distro_Testing_Plan]].<br />
<br />
For more information on the overall QA testing plan, please refer to [[QA_Master_Test_Plan]]. (Comprehensive)</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40895Distribution Support2018-07-31T22:24:55Z<p>Scottrif: /* Distribution Support */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
<br />
The poky.conf file tracks all the distros supported by the Yocto Project. (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf) The supported, and subsequently sanity tested, distros are listed in the "SANITY_TEST_DISTROS" section in poky.conf. Each supported distro is deployed and used as a Yocto Autobuilder build worker. For more information on supported distros, please refer to the "[https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual.<br />
<br />
<br />
<pre>Example of distro list in poky.conf:<br />
<br />
SANITY_TESTED_DISTROS ?= " \<br />
poky-2.4 \n \<br />
poky-2.5 \n \<br />
ubuntu-15.04 \n \<br />
ubuntu-16.04 \n \<br />
ubuntu-16.10 \n \<br />
ubuntu-17.04 \n \<br />
fedora-26 \n \<br />
centos-7 \n \<br />
debian-8 \n \<br />
debian-9 \n \<br />
opensuse-42.1 \n \<br />
opensuse-42.2 \n \<br />
"<br />
</pre><br />
Again, this is just an example, not meant to be a definitive reference. <br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
* Check if there is already a distribution listed on this page<br />
* If there is no such distribution, you could add a new entry in above matrix for the distribution and add following information in the sub-page of this entry:<br />
<br />
* Distribution (Fedora15/Ubuntu10.04/Opensuse11.4... etc):<br />
* Arch (32/64):<br />
* MACHINE (qemux86/qemuarm/qemuppc... etc):<br />
* TARGET (core-image-sato/core-image-sato-sdk... etc):<br />
* Commit/Release (7eea637db0.../master, 1.0.1 release):<br />
* Validated by/DATE (user@email.com - 2011-09-14):<br />
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)<br />
<br />
* If there is already a distribution in above matrix, it's better for you to check if your test result is consistent with the old result in matrix. You could update the "Status" field and add additional information with above format into sub-page of the distribution.<br />
<br><br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
Distro Testing is intended to catch bugs that are distribution specific using the yocto-autobuilder. The tests are all run on identical hardware and with all OS-es updated. The distributions used will be Fedora, Ubuntu, CentOS, OpenSuse with their latest update.<br />
<br><br />
This is the list of the builds that are performed on Distro testing:<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|Build-set<br />
! scope="col"|Images Built<br />
! scope="col"|Target machine<br />
|-<br />
|nightly-world<br />
|world<br />
|qemux86<br />
|-<br />
|buildtools<br />
|buildtools-tarball<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="5"|nightly-arm<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemuarm<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="4"|nightly-multilib<br />
|lib32-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86-64<br />
|-<br />
|lib32-core-image-sato<br />
|-<br />
|lib64-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86<br />
|-<br />
|lib64-core-image-sato<br />
|-<br />
|nightly-qa-systemd<br />
|core-image-sato<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86-64<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|}<br />
<br />
<br></div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40856Distribution Support2018-07-30T22:55:38Z<p>Scottrif: /* Distribution Support */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
This page is to maintain a list of distributions validated to work with Yocto Project. Everyone is welcome to add distribution support information into this page.<br />
<br />
'''NOTE: This list could be outdated'''. Please refer to the "[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual for the current list of supported Linux distributions.<br />
<br />
{|border="1"<br />
|| '''OS version''' || '''Host Arch''' || '''Status'''<br />
|-<br />
|| openSUSE 11.2 "Emerald" || -- || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/centos5.7|CentOS 5.7]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/centos6.2|CentOS 6.2]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/ubuntu7.04|Ubuntu 7.04]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/ubuntu8.04|Ubuntu 8.04 LTS]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/ubuntu10.04_32b|Ubuntu10.04]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/ubuntu11.04_64b|Ubuntu11.04]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora13_32b|Fedora 13]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
|| Fedora 14 || -- || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora15_32b|Fedora 15]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora15_64b|Fedora 15]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora16_64b|Fedora 16]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora17_64b|Fedora 17]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora18_64b|Fedora 18]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/opensuse11.3_32b|OpenSUSE 11.3]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/opensuse11.4_64b|OpenSUSE 11.4]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/rhel6.2_64b|Red Hat Enterprise Linux Server 6.2]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
|[[Distro/DebianWheezy | Debian Wheezy]] || 64bit || align="center" style="color:red;" | FAIL<br />
|}<br />
<br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
* Check if there is already a distribution listed on this page<br />
* If there is no such distribution, you could add a new entry in above matrix for the distribution and add following information in the sub-page of this entry:<br />
<br />
* Distribution (Fedora15/Ubuntu10.04/Opensuse11.4... etc):<br />
* Arch (32/64):<br />
* MACHINE (qemux86/qemuarm/qemuppc... etc):<br />
* TARGET (core-image-sato/core-image-sato-sdk... etc):<br />
* Commit/Release (7eea637db0.../master, 1.0.1 release):<br />
* Validated by/DATE (user@email.com - 2011-09-14):<br />
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)<br />
<br />
* If there is already a distribution in above matrix, it's better for you to check if your test result is consistent with the old result in matrix. You could update the "Status" field and add additional information with above format into sub-page of the distribution.<br />
<br><br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
Distro Testing is intended to catch bugs that are distribution specific using the yocto-autobuilder. The tests are all run on identical hardware and with all OS-es updated. The distributions used will be Fedora, Ubuntu, CentOS, OpenSuse with their latest update.<br />
<br><br />
This is the list of the builds that are performed on Distro testing:<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|Build-set<br />
! scope="col"|Images Built<br />
! scope="col"|Target machine<br />
|-<br />
|nightly-world<br />
|world<br />
|qemux86<br />
|-<br />
|buildtools<br />
|buildtools-tarball<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="5"|nightly-arm<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemuarm<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="4"|nightly-multilib<br />
|lib32-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86-64<br />
|-<br />
|lib32-core-image-sato<br />
|-<br />
|lib64-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86<br />
|-<br />
|lib64-core-image-sato<br />
|-<br />
|nightly-qa-systemd<br />
|core-image-sato<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86-64<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|}<br />
<br />
<br><br />
=== Distro Machines for 1.7 ===<br />
Here is the list of the machines that Distro testing is being run against for 1.7<br />
<br><br />
<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|OS Version<br />
! scope="col"|Host Arch<br />
! scope="col"|Status<br />
|-<br />
|Ubuntu 14.04 LTS<br />
|64 bit<br />
|Pass<br />
|-<br />
|Fedora 20<br />
|64 bit<br />
|Pass<br />
|-<br />
|OpenSuse 13.1<br />
|64 bit<br />
|Pass<br />
|-<br />
|CentOS 6.5<br />
|64 bit<br />
|Pass<br />
|}</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40855Distribution Support2018-07-30T22:54:36Z<p>Scottrif: /* Distribution Support */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
This page is to maintain a list of distributions validated to work with Yocto Project. Everyone is welcome to add distribution support information into this page.<br />
<br />
'''NOTE: This list is outdated'''. Please refer to the "[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual for the current list of supported Linux distributions.<br />
<br />
{|border="1"<br />
|| '''OS version''' || '''Host Arch''' || '''Status'''<br />
|-<br />
|| openSUSE 11.2 "Emerald" || -- || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/centos5.7|CentOS 5.7]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/centos6.2|CentOS 6.2]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/ubuntu7.04|Ubuntu 7.04]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/ubuntu8.04|Ubuntu 8.04 LTS]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/ubuntu10.04_32b|Ubuntu10.04]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/ubuntu11.04_64b|Ubuntu11.04]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora13_32b|Fedora 13]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
|| Fedora 14 || -- || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora15_32b|Fedora 15]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora15_64b|Fedora 15]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora16_64b|Fedora 16]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora17_64b|Fedora 17]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora18_64b|Fedora 18]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/opensuse11.3_32b|OpenSUSE 11.3]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/opensuse11.4_64b|OpenSUSE 11.4]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/rhel6.2_64b|Red Hat Enterprise Linux Server 6.2]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
|[[Distro/DebianWheezy | Debian Wheezy]] || 64bit || align="center" style="color:red;" | FAIL<br />
|}<br />
<br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
* Check if there is already a distribution listed on this page<br />
* If there is no such distribution, you could add a new entry in above matrix for the distribution and add following information in the sub-page of this entry:<br />
<br />
* Distribution (Fedora15/Ubuntu10.04/Opensuse11.4... etc):<br />
* Arch (32/64):<br />
* MACHINE (qemux86/qemuarm/qemuppc... etc):<br />
* TARGET (core-image-sato/core-image-sato-sdk... etc):<br />
* Commit/Release (7eea637db0.../master, 1.0.1 release):<br />
* Validated by/DATE (user@email.com - 2011-09-14):<br />
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)<br />
<br />
* If there is already a distribution in above matrix, it's better for you to check if your test result is consistent with the old result in matrix. You could update the "Status" field and add additional information with above format into sub-page of the distribution.<br />
<br><br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
Distro Testing is intended to catch bugs that are distribution specific using the yocto-autobuilder. The tests are all run on identical hardware and with all OS-es updated. The distributions used will be Fedora, Ubuntu, CentOS, OpenSuse with their latest update.<br />
<br><br />
This is the list of the builds that are performed on Distro testing:<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|Build-set<br />
! scope="col"|Images Built<br />
! scope="col"|Target machine<br />
|-<br />
|nightly-world<br />
|world<br />
|qemux86<br />
|-<br />
|buildtools<br />
|buildtools-tarball<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="5"|nightly-arm<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemuarm<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="4"|nightly-multilib<br />
|lib32-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86-64<br />
|-<br />
|lib32-core-image-sato<br />
|-<br />
|lib64-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86<br />
|-<br />
|lib64-core-image-sato<br />
|-<br />
|nightly-qa-systemd<br />
|core-image-sato<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86-64<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|}<br />
<br />
<br><br />
=== Distro Machines for 1.7 ===<br />
Here is the list of the machines that Distro testing is being run against for 1.7<br />
<br><br />
<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|OS Version<br />
! scope="col"|Host Arch<br />
! scope="col"|Status<br />
|-<br />
|Ubuntu 14.04 LTS<br />
|64 bit<br />
|Pass<br />
|-<br />
|Fedora 20<br />
|64 bit<br />
|Pass<br />
|-<br />
|OpenSuse 13.1<br />
|64 bit<br />
|Pass<br />
|-<br />
|CentOS 6.5<br />
|64 bit<br />
|Pass<br />
|}</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Distribution_Support&diff=40854Distribution Support2018-07-30T22:53:47Z<p>Scottrif: /* Distribution Support */</p>
<hr />
<div>==Distribution Support ==<br />
===Distribution Support ===<br />
This page is to maintain a list of distributions validated to work with Yocto Project. Everyone is welcome to add distribution support information into this page.<br />
<br />
'''NOTE: This list is outdated'''. Please refer to the "[http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#detailed-supported-distros Supported Linux Distributions]" section in the Yocto Project Reference Manual for the current list of supported Linux distributions.<br />
<br />
{|border="1"<br />
|| '''OS version''' || '''Host Arch''' || '''Status'''<br />
|-<br />
|| openSUSE 11.2 "Emerald" || -- || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/centos5.7|CentOS 5.7]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/centos6.2|CentOS 6.2]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/ubuntu7.04|Ubuntu 7.04]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/ubuntu8.04|Ubuntu 8.04 LTS]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/ubuntu10.04_32b|Ubuntu10.04]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/ubuntu11.04_64b|Ubuntu11.04]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora13_32b|Fedora 13]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
|| Fedora 14 || -- || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora15_32b|Fedora 15]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora15_64b|Fedora 15]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora16_64b|Fedora 16]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora17_64b|Fedora 17]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/fedora18_64b|Fedora 18]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/opensuse11.3_32b|OpenSUSE 11.3]] || 32bit || align="center" style="color:green;" | PASS<br />
|-<br />
||[[Distro/opensuse11.4_64b|OpenSUSE 11.4]] || 64bit || align="center" style="color:red;" | FAIL<br />
|-<br />
||[[Distro/rhel6.2_64b|Red Hat Enterprise Linux Server 6.2]] || 64bit || align="center" style="color:green;" | PASS<br />
|-<br />
|[[Distro/DebianWheezy | Debian Wheezy]] || 64bit || align="center" style="color:red;" | FAIL<br />
|}<br />
<br />
<br><br />
<br />
=== How to add a new entry or additional distro information ===<br />
* Check if there is already a distribution listed on this page<br />
* If there is no such distribution, you could add a new entry in above matrix for the distribution and add following information in the sub-page of this entry:<br />
<br />
* Distribution (Fedora15/Ubuntu10.04/Opensuse11.4... etc):<br />
* Arch (32/64):<br />
* MACHINE (qemux86/qemuarm/qemuppc... etc):<br />
* TARGET (core-image-sato/core-image-sato-sdk... etc):<br />
* Commit/Release (7eea637db0.../master, 1.0.1 release):<br />
* Validated by/DATE (user@email.com - 2011-09-14):<br />
* Bug ID: (If the status of your testing is failure, pls. help to file a bug in our bugzilla, http://bugzilla.pokylinux.org)<br />
<br />
* If there is already a distribution in above matrix, it's better for you to check if your test result is consistent with the old result in matrix. You could update the "Status" field and add additional information with above format into sub-page of the distribution.<br />
<br><br />
<br />
== Distro Testing ==<br />
=== Distro test coverage ===<br />
Distro Testing is intended to catch bugs that are distribution specific using the yocto-autobuilder. The tests are all run on identical hardware and with all OS-es updated. The distributions used will be Fedora, Ubuntu, CentOS, OpenSuse with their latest update.<br />
<br><br />
This is the list of the builds that are performed on Distro testing:<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|Build-set<br />
! scope="col"|Images Built<br />
! scope="col"|Target machine<br />
|-<br />
|nightly-world<br />
|world<br />
|qemux86<br />
|-<br />
|buildtools<br />
|buildtools-tarball<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="5"|nightly-arm<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemuarm<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="4"|nightly-multilib<br />
|lib32-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86-64<br />
|-<br />
|lib32-core-image-sato<br />
|-<br />
|lib64-core-image-minimal<br />
| colspan="1" rowspan="2"|qemux86<br />
|-<br />
|lib64-core-image-sato<br />
|-<br />
|nightly-qa-systemd<br />
|core-image-sato<br />
|qemux86-64<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
| colspan="1" rowspan="10"|nightly-x86-64<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|-<br />
|core-image-sato<br />
| colspan="1" rowspan="5"|qemux86-64<br />
|-<br />
|core-image-sato-dev<br />
|-<br />
|core-image-sato-sdk<br />
|-<br />
|core-image-minimal<br />
|-<br />
|core-image-minimal-dev<br />
|}<br />
<br />
<br><br />
=== Distro Machines for 1.7 ===<br />
Here is the list of the machines that Distro testing is being run against for 1.7<br />
<br><br />
<br />
{| border="1" cellpadding="1" cellspacing="1" class="article-table" style="width: 500px;"<br />
|-<br />
! scope="col"|OS Version<br />
! scope="col"|Host Arch<br />
! scope="col"|Status<br />
|-<br />
|Ubuntu 14.04 LTS<br />
|64 bit<br />
|Pass<br />
|-<br />
|Fedora 20<br />
|64 bit<br />
|Pass<br />
|-<br />
|OpenSuse 13.1<br />
|64 bit<br />
|Pass<br />
|-<br />
|CentOS 6.5<br />
|64 bit<br />
|Pass<br />
|}</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38522Bugzilla Configuration and Bug Tracking2018-05-10T17:36:23Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Because the Yocto Project spans many geographies and is a large and active project, a single bug scrub meeting is not easy to maintain. Consequently, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity and features and then schedules the bug to best facilitate a resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]].<br />
<br />
Part of the Triage process is the distribution of a weekly Bugzilla Cleanup Request. This email request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request. For the actual request, links to lists of bugs exist that allow you to see the list of bugs that fail to meet a particular requirement:<br />
<br />
*'''No Estimate:''' You own a medium or higher priority bug or enhancement in Bugzilla targeted for completion in the given release. Do to the amount of work trying to get done in Yocto Project, we are asking you take a minute or two and give an estimated amount of work – in "Perfect-Work-Days" – to complete the bug or enhancement. We know your estimates might not be perfect. However, this effort helps us know who is overloaded with work and where to apply the resources we are adding to the project. Please estimate how many "Perfect-Work-Days" remain to close the bugs in the "Estimate: Person-Days" box in Bugzilla. Also while updating the bug or enhancement, please ensure the estimate targets the correct Milestone for completion.<br />
<br />
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker whose assigned milestone is old. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has already passed, please do one of the following actions:<br />
**If it is completed: Close the bug. (Great News!)<br />
**If it is partly complete: Break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
**If it is not done at all but you still plan to fix it in the future: Move the bug to milestone that is not yet completed. (Future is a possible milestone.) <br />
**If it is no longer in your plans to do this but you think this still needs to be fixed: Change the bug to an unassigned priority. During the Triage process, we will assess the bug again and appropriately reassign the bug.<br />
**If it no longer makes sense to fix this bug: Please close the bug request with a status of either OBSOLETE or WONTFIX.<br />
<br />
*'''Needs specific milestone:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker that has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). Medium+ and High bugs are not allowed to be set to the "Future" milestone.<br />
<br />
*'''Needs to be broken up:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker that is a medium or higher priority and has more than five "Perfect-Work-Days" assigned. All open medium or higher bugs with more than five days should be broken into smaller dependent tasks.<br />
<br />
*'''Dependency Issue:''' You have a dependency problem in Yocto Project Bugzilla tracker where either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with the bug.<br />
<br />
*'''Need Info > 2 Weeks:''' You have bugs or requested enhancements for the Yocto Project for which more information has been requested in order to allow progress on these bugs. These bugs or enhancements have been in this state waiting for this information from you for at least two weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you cannot supply the information, please change the bug's status to CLOSED and the resolution to either OBSOLETE or WONTFIX, whichever is more appropriate.<br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38521Bugzilla Configuration and Bug Tracking2018-05-10T17:32:17Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Because the Yocto Project spans many geographies and is a large and active project, a single bug scrub meeting is not easy to maintain. Consequently, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity and features and then schedules the bug to best facilitate a resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]].<br />
<br />
Part of the Triage process is the distribution of a weekly Bugzilla Cleanup Request. This email request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request. For the actual request, links to lists of bugs exist that allow you to see the list of bugs that fail to meet a particular requirement:<br />
<br />
*'''No Estimate:''' You own a medium or higher priority bug or enhancement in Bugzilla targeted for completion in the given release. Do to the amount of work trying to get done in Yocto Project, we are asking you take a minute or two and give an estimated amount of work – in "Perfect-Work-Days" – to complete the bug or enhancement. We know your estimates might not be perfect. However, this effort helps us know who is overloaded with work and where to apply the resources we are adding to the project. Please estimate how many "Perfect-Work-Days" remain to close the bugs in the "Estimate: Person-Days" box in Bugzilla. Also while updating the bug or enhancement, please ensure the estimate targets the correct Milestone for completion.<br />
<br />
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker whose assigned milestone is old. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has already passed, please do one of the following actions:<br />
**If it is completed: Close the bug. (Great News!)<br />
**If it is partly complete: Break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
**If it is not done at all but you still plan to fix it in the future: Move the bug to milestone that is not yet completed. (Future is a possible milestone.) <br />
**If it is no longer in your plans to do this but you think this still needs to be fixed: Change the bug to an unassigned priority. During the Triage process, we will assess the bug again and appropriately reassign the bug.<br />
**If it no longer makes sense to fix this bug: Please close the bug request with a status of either OBSOLETE or WONTFIX.<br />
<br />
*'''Needs specific milestone:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). M+ and High bugs are not allowed to be set to the "Future" milestone.<br />
<br />
*'''Needs to be broken up:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
<br />
*'''Dependency Issue:''' You have a dependency problem in Bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
<br />
*'''Need Info > 2 Weeks:''' You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38520Bugzilla Configuration and Bug Tracking2018-05-10T17:19:42Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<br />
<br />
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions:<br />
**Close the bug since it has been completed. (Great News!)<br />
**If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
**If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
**If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
**If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
<br />
*'''Needs specific milestone:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). M+ and High bugs are not allowed to be set to the "Future" milestone.<br />
<br />
*'''Needs to be broken up:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
<br />
*'''Dependency Issue:''' You have a dependency problem in Bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
<br />
*'''Need Info > 2 Weeks:''' You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38519Bugzilla Configuration and Bug Tracking2018-05-10T17:19:14Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<br />
<br />
<br />
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions:<br />
**Close the bug since it has been completed. (Great News!)<br />
**If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
**If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
**If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
**If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
<br />
*'''Needs specific milestone:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). M+ and High bugs are not allowed to be set to the "Future" milestone.<br />
<br />
*'''Needs to be broken up:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
<br />
*'''Dependency Issue:''' You have a dependency problem in Bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
<br />
*'''Need Info > 2 Weeks:''' You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38518Bugzilla Configuration and Bug Tracking2018-05-10T17:18:45Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<p>Please review the below links to find these bugs:<br />
**High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
**Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
**Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29</p><br />
<br />
<br />
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions:<br />
**Close the bug since it has been completed. (Great News!)<br />
**If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
**If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
**If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
**If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
<br />
*'''Needs specific milestone:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (e.g. 2.2.3). M+ and High bugs are not allowed to be set to the "Future" milestone.<br />
<br />
*'''Needs to be broken up:''' You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
<br />
*'''Dependency Issue:''' You have a dependency problem in Bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
<br />
*'''Need Info > 2 Weeks:''' You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38517Bugzilla Configuration and Bug Tracking2018-05-10T17:13:31Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<p>Please review the below links to find these bugs:<br />
**High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
**Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
**Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29</p><br />
<br />
<br />
*'''Old Milestone:''' You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions:<br />
**Close the bug since it has been completed. (Great News!)<br />
**If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
**If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
**If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
**If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38516Bugzilla Configuration and Bug Tracking2018-05-10T17:09:35Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<p>Please review the below links to find these bugs:<br />
**High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
**Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
**Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29</p><br />
<br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38515Bugzilla Configuration and Bug Tracking2018-05-10T17:08:45Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<p>Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29</p><br />
<br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38514Bugzilla Configuration and Bug Tracking2018-05-10T17:07:57Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' <p>You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.</p><br />
<br />
<p>Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29</p><br />
<br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38513Bugzilla Configuration and Bug Tracking2018-05-10T17:07:38Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' <br />
<p>You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.</p><br />
<br />
<p>Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29</p><br />
<br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38512Bugzilla Configuration and Bug Tracking2018-05-10T17:06:03Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:''' You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
<br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38511Bugzilla Configuration and Bug Tracking2018-05-10T17:05:26Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
*'''No Estimate:'''<br />
You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
<br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38510Bugzilla Configuration and Bug Tracking2018-05-10T17:02:00Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
<li>'''No Estimate:'''<br />
You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Bugzilla_Configuration_and_Bug_Tracking&diff=38509Bugzilla Configuration and Bug Tracking2018-05-10T16:58:19Z<p>Scottrif: /* Bug Tracking */</p>
<hr />
<div>You should also read our [[Community Guidelines]] before submitting bugs.<br />
<br />
------<br />
== Defect Management ==<br />
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool. <br />
<br />
=== Home Address ===<br />
http://bugzilla.yoctoproject.org<br />
<br />
=== Get an Account ===<br />
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug. <br />
<br />
To set up an account, go to the '''[http://bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.<br />
<br />
=== Classification, Product and Components ===<br />
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:<br />
<br />
<pre><br />
+============================+===================================+=====================================================+<br />
| Classification | Product | Components |<br />
|================================================================+=====================================================|<br />
| Build system, metadata & | BitBake | bitbake |<br />
| Runtime | | |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSPs | bsps-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-intel-corei7-64 |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-arm |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-fsl-ppc |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-intel |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-minnow |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-ti |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-xilinx |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-meta-yocto |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-oe-core |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-runtime |<br />
| | +-----------------------------------------------------|<br />
| | | bsps-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Meta-yocto | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | meta-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | OE-Core | configuration |<br />
| | +-----------------------------------------------------|<br />
| | | connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | core |<br />
| | +-----------------------------------------------------|<br />
| | | deployment |<br />
| | +-----------------------------------------------------|<br />
| | | devtools /tool chain |<br />
| | +-----------------------------------------------------|<br />
| | | graphics |<br />
| | +-----------------------------------------------------|<br />
| | | kernel |<br />
| | +-----------------------------------------------------|<br />
| | | multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | Scripts and Tools |<br />
| | +-----------------------------------------------------|<br />
| | | virtual machines |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Other YP Layers | baryon |<br />
| | +-----------------------------------------------------|<br />
| | | layers |<br />
| | +-----------------------------------------------------|<br />
| | | meta-cgl |<br />
| | +-----------------------------------------------------|<br />
| | | meta-intel-iot-middleware |<br />
| | +-----------------------------------------------------|<br />
| | | meta-security |<br />
| | +-----------------------------------------------------|<br />
| | | meta-swupd |<br />
| | +-----------------------------------------------------|<br />
| | | meta-zephyr |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Runtime | build-appliance |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security - Recipe Upgrade | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Toaster | toaster |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Yocto Project Subprojects | ADT | adt |<br />
| | +-----------------------------------------------------| <br />
| | | kernel analysis |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Update Handler | Automatic Update Handler |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | CROPS | crops-default |<br />
| | +-----------------------------------------------------|<br />
| | | eclipse-crops |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Cross-prelink | cross-prelink |<br />
| | +-----------------------------------------------------|<br />
| | | poky integration |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Eclipse Plugin | eclipse-plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Error Reporting Tool | Error Reporting Tool |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | eSDK | eSDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit | intel-iot-refkit-application-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-connectivity |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-default |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-documentation |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-multimedia |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-platform-support |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-computer-vision |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-gateway |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-profile-industrial-robotics |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-security |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-software-update |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-tools |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel | kernel-configuration |<br />
| | +-----------------------------------------------------|<br />
| | | kernel-tooling |<br />
| | +-----------------------------------------------------|<br />
| | | linux-yocto |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Layer Index | Layer Index |<br />
| | +-----------------------------------------------------|<br />
| | | Layer Index Metadata |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Matchbox | matchbox |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | opkg | opkg |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Patchwork/Patchtest | Patchtest |<br />
| | +-----------------------------------------------------|<br />
| | | Patchtest Testsuite |<br />
| | +-----------------------------------------------------|<br />
| | | Patchwork |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Pseudo | poky integration |<br />
| | +-----------------------------------------------------|<br />
| | | pseudo |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Recipe Reporting System (RRS) | Recipe Reporting System (RRS) |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Sato | gtk-engine |<br />
| | +-----------------------------------------------------|<br />
| | | Icon |<br />
| | +-----------------------------------------------------|<br />
| | | Matchbox |<br />
| | +-----------------------------------------------------|<br />
| | | sato |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Documentation | ADT Manual | SDK |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BitBake User Manual | bitbake-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | BSP Guide | bsp-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Demos | demos-docs |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Development Manual | devolopment |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | General Docs | docs-general |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Kernel Development | kernel-development |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Mega Manual | mega-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Profile and Tracing Manual | profile-manual |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Quick Start | quick-start |<br />
| +-----------------------------------+-----------------------------------------------------| <br />
| | Reference | handbook |<br />
| | +-----------------------------------------------------|<br />
| | | PRD |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Infrastructure | AutoBuilder | autobuilder |<br />
| | +-----------------------------------------------------|<br />
| | | jenkins autobuilder plugin |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Bugzilla | bugzilla |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Program Management | management-default |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Release Process | Release Process |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Testopia | testopia |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Website | web-admin |<br />
| | +-----------------------------------------------------|<br />
| | | web-content |<br />
| | +-----------------------------------------------------|<br />
| | | web-design |<br />
| | +-----------------------------------------------------|<br />
| | | web-structure |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Wiki | wiki |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| QA/Testing | Automated Build Testing | automated-build-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Automated Runtime Testing | automated-runtime-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | IoT Reference OS Kit Testing | intel-iot-refkit-automated-build-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-automated-runtime-testing |<br />
| | +-----------------------------------------------------|<br />
| | | intel-iot-refkit-manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Manual Testing | manual-testing |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Test Plans/Suite | test-plans/suite |<br />
+----------------------------+-----------------------------------+-----------------------------------------------------|<br />
| Runtime | General Runtime | General Runtime |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Installation | Installation |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Package Management Issues | Debian Packaging - DEB |<br />
| | +-----------------------------------------------------|<br />
| | | ipkg opkg |<br />
| | +-----------------------------------------------------|<br />
| | | package-management-issues |<br />
| | +-----------------------------------------------------|<br />
| | | RPM |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | Security | security |<br />
| +-----------------------------------+-----------------------------------------------------|<br />
| | System Startup | system-startup |<br />
+============================|===================================+=====================================================+<br />
</pre><br />
<br />
=== Platform ===<br />
This field represents the hardware and architecture (platform) for which the bug applies. The platform consists of a Hardware component and an Architecture component. For example, the Platform could have a hardware of "PC" and an architecture of "x86". Here is a list of the hardware choices:<br />
<br />
* All<br />
* PC<br />
* Beagleboard<br />
* BeagleBone<br />
* Blacksand<br />
* Cheifriver<br />
* Crownbay<br />
* E-Menlow<br />
* EdgeRouter<br />
* FRI2<br />
* Galileo<br />
* JasperForest<br />
* MinnowBoard<br />
* MinnowBoard Max<br />
* mpc8315e-rdb<br />
* Netbook<br />
* NUC<br />
* RouterStationpro<br />
* TunnelCreek<br />
* Macintosh<br />
* Other<br />
<br />
Here is a list of the Architecture choices:<br />
<br />
* Multiple<br />
* arm<br />
* arm64<br />
* mips<br />
* mips64<br />
* ppc<br />
* ppc64<br />
* x86<br />
* x86_64<br />
* Other<br />
<br />
=== Version ===<br />
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. The list also contains versions of the Yocto Project that are currently being developed.<br />
<br />
Here is a sample list of selections at given the last time this wiki page was updated: <br />
<br />
* 2.0.3<br />
* 2.0.4<br />
* 2.1.2<br />
* 2.1.3<br />
* 2.1.4<br />
* 2.2<br />
* 2.2.1<br />
* 2.2.2<br />
* 2.2.3<br />
* 2.3<br />
* 2.3.1<br />
* 2.3.2<br />
* 2.4<br />
* 2.5<br />
* Unspecified<br />
<br />
=== Target Milestone ===<br />
This field represents the Yocto Project release milestone the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "2.4 M4" indicates the fourth milestone for the 2.4 release.<br />
<br />
=== Importance ===<br />
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:<br />
<br />
* High -- Bug fixing is planned immediately for the target milestone. Milestone cannot be released if there is a high bug opened against the milestone. High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release. The bug assignee is not to change the target milestones for High bugs without prior approval of the Triage team.<br />
* Medium+ -- Bug fixing is planned before the milestone and must be fixed or have a solution planned before the release is finalized. These issues are not show-stoppers but have somewhat significant impact to system functions and user experience. <br />
* Medium -- These are important issues we keep track and try to plan fixing for the release. They have limited impact for the system functions and releases.<br />
* Low -- Bug fixing is only done opportunistically. Generally not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.<br />
* Undecided -- These issues are newly reported and are '''undecided''' before Triage. Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Triage team approves it. <br />
<br />
'''Note:''' High impact but Low Priority bugs can be documented in the release notes.<br />
<br />
The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.<br />
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.<br />
* Major -- Major loss of functionality of POR.<br />
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.<br />
* Minor -- Minor loss of functionality, or issues with easy workaround available.<br />
* Enhancement -- Request for enhancement or new feature to be worked.<br />
<br />
=== Bug Status ===<br />
* NEW -- A new reported bug with default assignee.<br />
* ACCEPTED-- The assigned developer has reviewed and accept the bug.<br />
* RESOLVED -- bug is fixed or closed by other resolved method.<br />
** FIXED -- This is fixed and in the master branch will be set automatically during build<br />
** NOTABUG -- This is verified as not a bug<br />
** WONTFIX -- We will not fix this bug, possibly because a newer package fixes it.<br />
** DUPLICATE -- Duplicate of another bug, possibly different failure mode <br />
** INVALID -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NEEDINFO''' or it is not a feature of Yocto Project to fix.<br />
** OBSOLETE -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.<br />
** WORKSFORME -- The bug does not appear when tested by engineer, more appropriately, this may be '''NEEDINFO'''<br />
* VERIFIED -- bug is double checked and agreed with the resolved method by original reporter.<br />
* REOPENED: bug can be reopened, if it is in Resolved, Verified or Close stage. <br />
* NEEDINFO: bug needs further information from someone in order to make progress on the bug. Whoever set a bug to NEEDINFO should also change the assignee to who they are requesting the information from.<br />
* '''CLOSED''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it (close stage) is just for keeping wrong bug out of scrub cycle and statistic.<br />
<br />
=== Bug Life Cycle ===<br />
A normal Bug's life is starts from '''NEW''' and ends with '''VERIFIED'''. Triage team will select "verified: Program Management", after confirm the verification. <br />
<br />
[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]<br />
<br />
Bug should be marked as '''RESOLVED/FIXED''', after its fixing patch is built into formal build (weekly build or milestone build). There is an automatic method to update bugs to '''RESOVLED/FIXED''' status by following steps.<br />
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description (e.g. '''[YOCTO #4321]''')<br />
# Developer asked tree gatekeeper to pull patch.<br />
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.<br />
# Build script will notify bugzilla and update bugs status to '''RESOLVE/FIXED'''<br />
<br />
If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopened.<br />
<br />
[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]<br />
<br />
== Submitting and Owning a Defect ==<br />
Anyone working with Yocto who has a Bugzilla account can enter a defect. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs. <br />
<br />
=== Bug Submitter ===<br />
When you submit (open) a bug, be sure to do the following:<br />
<br />
# Provide a clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].<br />
# Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.<br />
# Judge and select the appropriate Severity.<br />
# Add any additional information from the bug scrub.<br />
# Assign the bug to the correct person to disposition the bug.<br />
# If a bug is too vague to make a determination, then the Resolution Field of the bug will be set to '''NEEDINFO''' and sent back the bug submitter.<br />
# Make sure you edit the '''CC''' list to include other people you might think should know about the defect.<br />
# Set the "Documentation change" field appropriately. This field helps the people that create and maintain the Yocto Project manuals by alerting them to a documentation need for the defect's resolution.<br />
<br />
'''NOTE:''' You cannot set a defect's Priority when you submit a bug. The Priority is set during the Bug Triage.<br />
<br />
=== Bug Owner ===<br />
If you are the owner of a bug, be sure to do the following:<br />
<br />
# Review your bugs to check if there is enough information. If not, set the bug to '''NEEDINFO'''. <br />
# Try to reproduce your bugs when clear steps exist in the bug's description. <br />
# Address bugs based on their Priority and Severity. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which impacts the whole system.<br />
# Be timely regarding updating bugs with comments. Timely comments both helps those working on the bug and keeps a bug active. Set the bug to '''FIXED''' and provide the tree/commit information once the bug is fixed. You should not mark a bug as '''RESOLVED/FIXED''', if the patch is not checked into the repository.<br />
<br />
== Bug Tracking ==<br />
Yocto spans many geographies. A single bug scrub meeting is not easy to maintain. Because Yocto Project is a large, active project, a ''Triage'' is used to effectively disposition bugs. The Bug Triage team reviews a bug's severity, features, and schedule to best facilitate a bug's resolution. The Triage team sets new bug priorities, corrects ownership for the work to be done, and ensures an appropriate target milestone for the bug. The Triage process is documented at [[Bug_Triage]]<br />
<br />
Aside from the Triage process that initially defines a bug's parameters, the process emails out a weekly Bugzilla Cleanup Request. This request is a reminder for bug owners when various parameters of a bug are not in line with the Yocto Project Bugzilla tracking system. For example, if a bug has no estimate information or a milestone by which it should complete. Following is a summary of the type of information in the weekly Bugzilla Cleanup Request:<br />
<br />
<li>No Estimate:<br />
You are an owner of a medium or higher priority bug or enhancement in bugzilla targeting completion during YP 2.5. Do to the amount of work we are trying to get done in Yocto Project; we are asking you take a minute or two and give an estimated amount of work – in ""Perfect-Work-Days"" – to complete the bug/enhancement. We know your estimates might not be perfect themselves; but this effort will help us know who is overloaded and where to apply the resources we are adding to the project. Please estimate how many ""Perfect-Work-Days"" remain to close the bugs in the ""Estimate: Person-Days"" box in Bugzilla. Currently 556 of the 556 open YP 2.5 bugs/enhancements have an estimate time entered. Also while updating the bug/enhancement please insure you have it targeting the correct Milestone for completion.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Old Milestone:<br />
You are assigned an open bug in the Yocto Project Bugzilla tracker which has an old milestone assigned to it. To see the list of bugs with old milestones please look here: https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone. Since the milestone for this bug in the Yocto Project has been completed please do one of the below actions.<br />
1. Close the bug since it has been completed. (Great News!)<br />
2. If it is partly done: break the bug request into two or more parts and close what is done and move the remaining parts to a future milestone.<br />
3. If it is not done at all; but you still plan to fix it in the future; move the bug to milestone which is not yet completed. (Future is a possible milestone.) <br />
4. If it is no longer your plans to do this, but you think this still needs to be fixed – change the bug to an unassigned priority, we will triage it again and reassign it someone.<br />
5. If it no longer makes sense to fix this bug, please close the bug request as OBSOLETE or WONTFIX.<br />
</li><br />
<br />
<li>Needs specific milestone: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which has a medium+ or high priority assigned to it without a targeted specific milestone or specific dot release. All open medium+ or high bugs must have a specific target milestone or specific dot release assigned to them (i.e. 2.2.3).<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Note: M+ and High are not allowed to be set to the Future milestone either.<br />
</li><br />
<br />
<li>Needs to be broken up: <br />
You are assigned an open bug or enhancement in the Yocto Project Bugzilla tracker which is a medium or higher priority and has more than 5 ""Perfect-Work-Days"" assigned. All open medium or higher bugs with more than 5 days should be broken into smaller dependent tasks.<br />
Please review the below links to find these bugs:<br />
High Bugs: https://wiki.yoctoproject.org/wiki/Bug_Triage#High_Enhancements.2FBugs<br />
Medium+ Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
Medium Bugs and Enhancements by Owner: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium_Bugs_and_Enhancements_by_Owner_.21.28Future.2C_2.4.29<br />
</li><br />
<br />
<li>Dependency Issue: <br />
You have a dependency problem in bugzilla. This means that either your bug or enhancement is dependent on a lower priority bug or enhancement, or your bug or enhancement has a target milestone earlier than dependent bugs or enhancements. Please open your bug and review the dependencies to see what the problem is with it.<br />
</li><br />
<br />
<li>Need Info > 2 Weeks:<br />
You all have bugs or requested enhancements for Yocto Project for which more information has been requested about to allow progress on these bugs. These bugs or enhancements have been in this state, waiting for this information from you, for at least 2 weeks. Please update the bug or enhancement request at: https://wiki.yoctoproject.org/wiki/Bug_Triage#NEEDINFO to have the requested information so that work on this bug or enhancement can move forward. If you can’t supply the information please change the status to CLOSED and the resolution to either OBSOLETE or WONTFIX whichever is more appropriate.<br />
</li><br />
<br />
== Feature Request Process ==<br />
New feature request should be applied through Bugzilla as a bug. User should set the Severity to Enhancement. The request will be triaged in the Triage Team meetings.<br />
<br />
There will be two important feature request review time per year in March and September (2 months before final release). In the review period, there will be 2~4 times review meetings by the triage team. The Triage team will which decide new features which will be included in next release, that will be released in April and October.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=37573Documentation Decoder2018-04-02T20:35:19Z<p>Scottrif: /* List of Manual Pages */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what. <br />
:URLs have the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>. <br />
: Here is an example for the "Yocto Project Reference Manual" for release 2.1.1: <tt>http://www.yoctoproject.org/docs/2.1.1/ref-manual/ref-manual.html</tt><br />
Note that <tt>current</tt> can be used in place of the current release number.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page names and brief descriptions of their purposes:<br />
:[http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html yocto-project-qs]. Quick start guide to get you going.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. Conceptual and procedural information that covers common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to use Yocto built SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a board support package layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. Kernel development manual. Often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Toaster is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Material suited for reference rather than procedures. Come here for the details.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one mega manual.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=Documentation_Decoder&diff=37572Documentation Decoder2018-04-02T20:33:04Z<p>Scottrif: /* URL Decoder */</p>
<hr />
<div>== URL Decoder ==<br />
Many different Yocto Project documentation pages are returned by Google searches and it can be hard to know what's what. <br />
:URLs have the following format: <tt>http://www.yoctoproject.org/docs/release/name/name.html</tt>. <br />
: Here is an example for the "Yocto Project Reference Manual" for release 2.1.1: <tt>http://www.yoctoproject.org/docs/2.1.1/ref-manual/ref-manual.html</tt><br />
Note that <tt>current</tt> can be used in place of the current release number.<br/><br />
<br />
== List of Manual Pages ==<br />
Here is a list of documentation page name and a brief description of their purpose<br />
:[http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html yocto-project-qs]. Quick start guide to get you going.<br />
:[http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html dev-manual]. Conceptual and procedural information that covers common development tasks.<br />
:[http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html sdk-manual]. Describes how to use Yocto built SDKs for application development.<br />
:[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html bsp-guide]. Describes how to use or create a board support package layer for your hardware platform.<br />
:[http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html kernel-dev]. Kernel development manual. Often used in conjunction with BSP guide.<br />
:[http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html toaster-manual]. Toaster is a web interface to the Yocto Project's OpenEmbedded build system. <br />
:[http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html ref-manual]. Material suited for reference rather than procedures. Come here for the details.<br />
:[http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html mega-manual]. All of the above rolled into one mega manual.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=FutureMigrationGuide&diff=32456FutureMigrationGuide2017-10-17T22:02:37Z<p>Scottrif: /* Other changes (yet to be categorised / completed) */</p>
<hr />
<div>{| style="color:black; background-color:#ffffcc" width="100%" cellpadding="10" class="wikitable"<br />
|This page should be used to keep track of items which should be added to the [http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration migration guide] in the YP Reference Manual. It's a living document for the life of a development cycle and by M4 should represent a significant proportion of items that are worthy of note in the migration guide.<br />
<br />
Once the migration guide for a release has been completed the contents of this page should be cleared out.<br />
|}<br />
<br />
=2.4 Migration Guide items=<br />
<br />
== Memory resident mode ==<br />
<br />
Bitbake's previous "memory resident mode" has been replaced by a persistent mode which is available in bitbake's default operation. As such, you only need to set BB_SERVER_TIMEOUT to a timeout (in seconds) and BitBake's server will stay resident for that amount of time between bitbake invocations. The oe-init-build-env-memres script has been removed as a separate environment setup script is no longer needed.<br />
<br />
== Packaging changes ==<br />
<br />
* python3: the main "python3" package now brings in all of the standard Python 3 distribution rather than just a subset, matching the typical expected behaviour based on traditional Linux distributions. If you wish to install a subset of Python 3, specify python-core plus one or more of the individual packages that are still produced.<br />
* python3: bz2.py, lzma.py and _compression.py have beem moved from the python3-misc package to the python3-compression package.<br />
* binutils: libbfd is now packaged in a separate "libbfd" package in order to save space when some tools (notably perf) are installed, since they only need libbfd rather than all of binutils.<br />
* util-linux: su is now packaged in a separate "util-linux-su" package (only built when "pam" is in DISTRO_FEATURES), since su is normally provided by shadow and thus the util-linux version shouldn't be installed unless it is needed. The main util-linux package RDEPENDS on this package when "pam" is in DISTRO_FEATURES.<br />
* util-linux: switch_root is now packaged in a separate "util-linux-switch-root" package for small initramfs images which don't need the whole util-linux package (nor the busybox binary which is much larger than switch_root). The main util-linux package RRECOMMENDS this package.<br />
* util-linux: ionice is now packaged in a separate "util-linux-ionice" package for convenience. The main util-linux package RRECOMMENDS this package.<br />
* initscripts: sushell is now package in a separate "initscripts-sushell" package to allow systemd to pull it in when selinux is enabled without needing to pull in the entire initscripts package. The main initscripts package RDEPENDS on this package when "selinux" is in DISTRO_FEATURES.<br />
* glib-2.0 now RRECOMMENDS shared-mime-info, as large portions of GIO are not that useful without the MIME database. This can be removed using BAD_RECOMMENDATIONS if shared-mime-info is too large and isn't required.<br />
* The Go standard runtime has been split out from the main go recipe into a separate "go-runtime" recipe.<br />
<br />
== Removed recipes ==<br />
<br />
The following recipes have been removed in the 2.4 release:<br />
<br />
* acpitests: recipe not being maintained<br />
* autogen-native: with grub no longer requiring it, there's nothing else in oe-core or meta-oe that does.<br />
* bdwgc: moved to meta-oe as nothing in OpenEmbedded-Core needs it in any longer.<br />
* byacc: was only needed by rpm 5.x and has been moved to meta-oe<br />
* gcc (5.4): drop 5.4 series in favour of 6.3 / 7.2<br />
* gnome-common: deprecated upstream and no longer needed<br />
* go-bootstrap-native: remove recipe as go 1.9 can do its own bootstrapping<br />
* guile: was only needed by autogen-native and remake, so no longer needed<br />
* libclass-isa-perl: was previously needed for LSB 4, no longer needed<br />
* libdumpvalue-perl: was previously needed for LSB 4, no longer needed<br />
* libenv-perl: was previously needed for LSB 4, no longer needed<br />
* libfile-checktree-perl: was previously needed for LSB 4, no longer needed<br />
* libi18n-collate-perl: was previously needed for LSB 4, no longer needed<br />
* libiconv: this was only needed for uclibc which was removed in the previous release - glibc and musl have their own implementations. meta-mingw still needs it so it has been moved there.<br />
* libpng12: only previously needed for LSB; current libpng is 1.6.x.<br />
* libpod-plainer-perl: was previously needed for LSB 4, no longer needed<br />
* linux-yocto (4.1): removed in favour of 4.4, 4.9, 4.10 and 4.12<br />
* mailx: only previously needed for LSB compatibility, with upstream being defunct now for a long time.<br />
* mesa (git version only): has gone stale with respect to the release version<br />
* ofono (git version only): has gone stale with respect to the release version<br />
* portmap: obsolete - superseded by rpcbind.<br />
* python3-pygpgme: old and unmaintained; was previously required only by dnf but that has now switched to official gpgme python bindings.<br />
* python-async: removed in favour of python 3 version<br />
* python-gitdb: removed in favour of python 3 version<br />
* python-git: removed in favour of python 3 version<br />
* python-mako: removed in favour of python 3 version<br />
* python-pexpect: removed in favour of python 3 version<br />
* python-ptyprocess: removed in favour of python 3 version<br />
* python-pycurl: nothing is using this in OpenEmbedded-Core (or meta-oe)<br />
* python-six: removed in favour of python 3 version<br />
* python-smmap: removed in favour of python 3 version<br />
* remake: using remake as the provider of virtual/make has been broken for some time. No longer needed in OpenEmbedded-Core.<br />
<br />
== Kernel Device Tree move ==<br />
<br />
Kernel Device Tree support is now easier to enable in a kernel recipe. The Device Tree code has been moved to a kernel-devicetree class, and any recipe inheriting the kernel class that also sets KERNEL_DEVICETREE variable will get the functionality automatically enabled. The previous mechanism for doing this, meta/recipes-kernel/linux/linux-dtb.inc, is still present in order to avoid breakage, but triggers a deprecation warning and will be removed in a future release, so you are advised to remove the "require ...linux-dtb.inc" line from any custom kernel recipes you may have in advance as it is no longer needed as of the Yocto Project 2.4 release.<br />
<br />
== Package QA changes ===<br />
<br />
* The "unsafe-references-in-scripts" QA check has been removed, since that check was to ensure that / and /usr could be on different filesystems and the latter is no longer actively supported.<br />
* Referring to ${COREBASE}/LICENSE within LIC_FILES_CHKSUM will now trigger a warning, since this file is just a description of the license for OE-Core. If your recipe is MIT licensed and you cannot refer to a file within the source tree (which is preferred), then use ${COMMON_LICENSE_DIR}/MIT instead.<br />
<br />
== Other changes (yet to be categorised / completed) ==<br />
<br />
* The ROOTFS_PKGMANAGE_BOOTSTRAP variable is gone, and any references to it (potentially in custom image recipes) will need to be removed.<br />
* The meta-yocto directory has been removed - since the 2.1 release when meta-yocto was renamed to meta-poky, the meta-yocto subdirectory remained to avoid breaking existing configurations.<br />
* maintainers.inc, the file which tracks maintainers with primary responsibility for each recipe in OE-Core has been moved from meta-poky to OE-Core, i.e. from meta-poky/conf/distro/include to meta/conf/distro/include.<br />
* The buildhistory class now makes a single commit per build rather than one per subdirectory in the repository (assuming commits are enabled with BUILDHISTORY_COMMIT = "1" as is typical). The earlier behaviour was intended to make it easier to see just the changes for a particular subdirectory, but git can filter that itself when viewing - just specify that subdirectory as the last parameter on the git show / git diff command line and that's all you will see.<br />
* x86-base.inc (included by all x86-based machine configurations) now sets IMAGE_FSTYPES using ?= to "live" rather than appending with +=, making the default easier to override.<br />
* bitbake will now fire multiple BuildStarted events when multiconfig is enabled (one per configuration).<br />
* security_flags.inc now sets a GCCPIE variable with an appropriate option to enable PIE within gcc by default. PIE stands for "Position Independent Executables." Enabling PIE in the GNU C Compiler (GCC), makes Return Oriented Programming (ROP) attacks much more difficult to execute reliably.<br />
* Since OE-Core now provides a bitbake-layers plugin that implements a "create-layer" subcommand, the yocto-layer script is deprecated and will likely be removed in the next release.<br />
* The vmdk/vdi/qcow2 image types have been replaced by CONVERSION_CMD types, and these would now typically be used in conjunction with the "wic" image type - thus the equivalents for these now are wic.vmdk, wic.vdi and wic.qcow2 respectively.<br />
* IMAGE_DEPENDS_<type> has been replaced by do_image_<type>[depends]. If you have your own classes implementing custom image types then those will need to be updated.<br />
* OpenSSL 1.1 has been introduced, but the default is still 1.0.x via PREFERRED_VERSION due to remaining compatibility issues with other software. "openssl10" has been added to PROVIDES as a marker for recipes that still definitely depend on OpenSSL 1.0.<br />
* As part of the bitbake server changes, in order to ensure consistent behaviour, bitbake's -r/-R options (aka prefile/postfile) to read/post-read additional configuration files from the command line will only affect the current bitbake command rather than "sticking" for future executions.<br />
* The main Poky README has been moved to README.poky in the meta-poky layer, with a symlink in the main poky repository pointing to it. Additionally the README.hardware file has been moved to meta-yocto-bsp, with a symlink in the main poky repository pointing to it. A README.qemu file has been created with brief coverage of just the qemu* machines.</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=31385TipsAndTricks/KernelDevelopmentWithEsdk2017-09-07T23:33:06Z<p>Scottrif: </p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ cd ~<br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
<br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Create a Layer ==<br />
We also need to create a layer to take the kernel patches we'll be creating. <br />
<pre><br />
$ cd ~/poky<br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] <br />
Would you like to have an example bbappend file created? (y/n) [default: n]<br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ cd ~/poky/build<br />
$ bitbake-layers add-layer ../../meta-my-kernel<br />
</pre><br />
<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device is automatically allocated. The example command output here uses a variable "X" to indicate the loopback device. The actual output you get when you run the command will list the actual loopback devices (e.g. "loop0p1", "loop0p2", and "loop0p3").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device (e.g loop0p1).<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace "loopX" with the automatically allocated loopback device from earlier (e.g "loop0").<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=30542TipsAndTricks/KernelDevelopmentWithEsdk2017-08-18T19:26:48Z<p>Scottrif: /* Build Extensible SDK */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ cd ~<br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. <br />
<pre><br />
$ cd ~/poky<br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] <br />
Would you like to have an example bbappend file created? (y/n) [default: n]<br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ cd ~/poky/build<br />
$ bitbake-layers add-layer ../../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device is automatically allocated. The example command output here uses a variable "X" to indicate the loopback device. The actual output you get when you run the command will list the actual loopback devices (e.g. "loop0p1", "loop0p2", and "loop0p3").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device (e.g loop0p1).<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace "loopX" with the automatically allocated loopback device from earlier (e.g "loop0").<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=30484TipsAndTricks/KernelDevelopmentWithEsdk2017-08-17T23:31:32Z<p>Scottrif: /* Build Extensible SDK */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ cd ~<br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. <br />
<pre><br />
$ cd ~/poky<br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] <br />
Would you like to have an example bbappend file created? (y/n) [default: n]<br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ cd ~/poky/build<br />
$ bitbake-layers add-layer ../../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device is automatically allocated. The example command output here uses a variable "X" to indicate the loopback device. The actual output you get when you run the command will list the actual loopback devices (e.g. "loop0p1", "loop0p2", and "loop0p3").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device (e.g loop0p1).<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace "loopX" with the automatically allocated loopback device from earlier (e.g "loop0").<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=30483TipsAndTricks/KernelDevelopmentWithEsdk2017-08-17T23:30:26Z<p>Scottrif: /* Build Extensible SDK */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ cd ~<br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. <br />
<pre><br />
$ cd ~/poky<br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] <br />
Would you like to have an example bbappend file created? (y/n) [default: n]<br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ cd ~/poky/build<br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device is automatically allocated. The example command output here uses a variable "X" to indicate the loopback device. The actual output you get when you run the command will list the actual loopback devices (e.g. "loop0p1", "loop0p2", and "loop0p3").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device (e.g loop0p1).<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace "loopX" with the automatically allocated loopback device from earlier (e.g "loop0").<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=30482TipsAndTricks/KernelDevelopmentWithEsdk2017-08-17T23:28:54Z<p>Scottrif: /* Build Extensible SDK */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ cd ~<br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. <br />
<pre><br />
$ cd ~/poky<br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] <br />
Would you like to have an example bbappend file created? (y/n) [default: n]<br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ cd ~/poky/build<br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device is automatically allocated. The example command output here uses a variable "X" to indicate the loopback device. The actual output you get when you run the command will list the actual loopback devices (e.g. "loop0p1", "loop0p2", and "loop0p3").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device (e.g loop0p1).<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace "loopX" with the automatically allocated loopback device from earlier (e.g "loop0").<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29976TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T21:49:25Z<p>Scottrif: /* Create image with new kernel */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device is automatically allocated. The example command output here uses a variable "X" to indicate the loopback device. The actual output you get when you run the command will list the actual loopback devices (e.g. "loop0p1", "loop0p2", and "loop0p3").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device (e.g loop0p1).<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace "loopX" with the automatically allocated loopback device from earlier (e.g "loop0").<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29975TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T21:43:58Z<p>Scottrif: /* Create image with new kernel */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. NOTE: If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device (loopX) will be automatically allocated. This example uses "X". You need to use the actual loopback device (e.g. "loop0").<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
NOTE: Replace loopXp1 with the automatically allocated loopback device e.g loop3p1.<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
NOTE: Replace loopX with the automatically allocated loopback device e.g loop3.<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29973TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T21:40:00Z<p>Scottrif: /* Create image with new kernel */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. If your build system does not have kpartx installed, be sure you install it.<br />
<br />
First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file. <br />
NOTE: The first unused loopback device (loopX) will be automatically allocated e.g loop3.<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loopXp1 (253:6): 0 47446 linear /dev/loopX 2048<br />
add map loopXp2 (253:7): 0 119356 linear /dev/loopX 51200<br />
add map loopXp3 (253:8): 0 90112 linear /dev/loopX 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loopXp1 to take a look<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loopXp1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loopX<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29962TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T19:23:37Z<p>Scottrif: /* Create image with new kernel */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loop3p1 (253:6): 0 47446 linear /dev/loop3 2048<br />
add map loop3p2 (253:7): 0 119356 linear /dev/loop3 51200<br />
add map loop3p3 (253:8): 0 90112 linear /dev/loop3 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loop3p1 to take a look<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loop3p1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkpartx...<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loop3<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29961TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T19:16:17Z<p>Scottrif: /* Create image with new kernel */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loop3p1 (253:6): 0 47446 linear /dev/loop3 2048<br />
add map loop3p2 (253:7): 0 119356 linear /dev/loop3 51200<br />
add map loop3p3 (253:8): 0 90112 linear /dev/loop3 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loop3p1 to take a look<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loop3p1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkaprtx...<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kpartx -d /dev/loop3<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29960TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T19:14:36Z<p>Scottrif: /* Create image with new kernel */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loop3p1 (253:6): 0 47446 linear /dev/loop3 2048<br />
add map loop3p2 (253:7): 0 119356 linear /dev/loop3 51200<br />
add map loop3p3 (253:8): 0 90112 linear /dev/loop3 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loop3p1 to take a look<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loop3p1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkaprtx...<br />
$ sudo umount /mnt/wic-p1<br />
$ sudo kaprtx -d /dev/loop3<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29922TipsAndTricks/KernelDevelopmentWithEsdk2017-08-09T01:06:43Z<p>Scottrif: /* Checkout kernel source */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |########################################################################################################################| Time: 0:00:00<br />
Loaded 1300 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/scottrif/poky_sdk/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loop3p1 (253:6): 0 47446 linear /dev/loop3 2048<br />
add map loop3p2 (253:7): 0 119356 linear /dev/loop3 51200<br />
add map loop3p3 (253:8): 0 90112 linear /dev/loop3 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loop3p1 to take a look<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loop3p1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkaprtx...<br />
$ sudo umount mnt/wic-p1<br />
$ sudo kaprtx -d /dev/loop3<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrifhttps://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/KernelDevelopmentWithEsdk&diff=29852TipsAndTricks/KernelDevelopmentWithEsdk2017-08-07T20:20:23Z<p>Scottrif: /* Build Extensible SDK */</p>
<hr />
<div>== Overview ==<br />
This article describes an efficient workflow for Linux kernel development using Yocto Project. The goal is to get the build, deploy and test cycle to under a minute. We will be working with the generix86-64 BSP and the Intel Minnowboard Turbot in this article but the process is the same for any platform and CPU architecture. <br />
<br />
The extensible SDK (eSDK) is a key part of this workflow for a number of reasons <br />
# It contains the target toolchain which is not easily accessible in the bitbake environment<br />
# It contains '''devtool''' which gives you an easy way of getting the kernel source your target is using (if using linux-yocto or linux-intel)<br />
# devtool will also automatically create patches for your kernel updates and add them to the the kernel recipe<br />
<br />
There are two separate steps to this process<br />
# Build or download an eSDK for your platform<br />
# Install and use that eSDK to build your kernel<br />
<br />
== Build Extensible SDK ==<br />
Open a new terminal window, we'll refer to this terminal as your '''bitbake terminal'''. First we'll checkout poky and configure bitbake environment.<br />
<pre><br />
$ git clone -b pyro git://git.yoctoproject.org/poky <br />
$ source poky/oe-init-build-env<br />
</pre><br />
Now we need to do some configuration for the Minnowboard image. <br />
* Set MACHINE (as default is qemux86)<br />
* Enable kernel modules (disabled by default for minimal images)<br />
Add the following to conf/local.conf<br />
MACHINE = "genericx86-64"<br />
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"<br />
We also need to create a layer to take the kernel patches we'll be creating. Be sure to create example recipe and append files when you run you run the "yocto-layer" command.<br />
<pre><br />
$ yocto-layer create my-kernel -o ../meta-my-kernel<br />
Please enter the layer priority you'd like to use for the layer: [default: 6] <br />
Would you like to have an example recipe created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your example recipe: [default: example] <br />
Would you like to have an example bbappend file created? (y/n) [default: n] y<br />
Please enter the name you'd like to use for your bbappend file: [default: example] <br />
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] <br />
<br />
New layer created in ../meta-my-kernel.<br />
<br />
Don't forget to add it to your BBLAYERS (for details see ../meta-my-kernel/README).<br />
</pre><br />
As directed, we need to add our layer to BBLAYERS as follows:<br />
<pre><br />
$ bitbake-layers add-layer ../meta-my-kernel<br />
</pre><br />
Now build an extensible SDK installer for the Minnowboard in the bitbake terminal<br />
<pre><br />
$ bitbake core-image-minimal -c populate_sdk_ext <br />
</pre><br />
The eSDK installer can be found in /path_to_build_directory/kernel-dev/tmp/deploy/sdk/<br />
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
<br />
Alternatively, if you are not using a yocto-linux kernel, you can use a prebuilt eSDK installer that includes the toolchain you need. For example, the pyro core-image-minimal esdk release for core2-64 is located [[http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh here]]. If you downloaded the installer, make it executable.<br />
<br />
== Install Extensible SDK ==<br />
Run the installer as follows. If you do not want to use the default ~/poky_sdk directory for installation of the toolchain, use the -d option to specify a destination.<br />
<pre><br />
$ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.3.1.sh<br />
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1<br />
============================================================================<br />
Enter target directory for SDK (default: ~/poky_sdk): <br />
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y<br />
Extracting SDK......................................done<br />
Setting it up...<br />
Extracting buildtools...<br />
Preparing build system...<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:52<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:04<br />
Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00<br />
Parsing recipes: 100% |#########################################################################################################| Time: 0:00:33<br />
Initialising tasks: 100% |######################################################################################################| Time: 0:00:00<br />
done<br />
SDK has been successfully set up and is ready to be used.<br />
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.<br />
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux<br />
</pre><br />
Take note of the final line, which shows you the environment setup script you must run each time you want to use the eSDK.<br />
<br />
== Setup your ESDK build environment (ESDK terminal) ==<br />
'''YOU MUST OPEN A NEW TERMINAL WHEN USING THE ESDK. DO NOT RE-USE YOUR BITBAKE TERMINAL.'''<br />
Open a new terminal and setup your build environment. We'll refer to this terminal as your 'ESDK terminal'. Run the setup script given by the installer.<br />
$ source /path/to/esdk/environment-setup-core2-64-poky-linux<br />
"SDK environment now set up; additionally you may now run devtool to perform development tasks.<br />
Run devtool --help for further details.<br />
<br />
If you see this<br />
WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a <br />
new shell session instead."<br />
You didn't open a new terminal!<br />
<br />
== Build initial image with ESDK ==<br />
In the ESDK terminal, build the image<br />
<pre><br />
$ devtool build-image<br />
Parsing recipes: 100% |##########################################| Time: 0:00:05<br />
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.<br />
WARNING: No packages to add, building image core-image-minimal unmodified<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Resolving any missing task queue dependencies<br />
Initialising tasks: 100% |#######################################| Time: 0:00:07<br />
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00<br />
NOTE: Executing SetScene Tasks<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.<br />
NOTE: Successfully built core-image-minimal. You can find output files in /path/to/esdk/tmp/deploy/images/genericx86-64<br />
</pre><br />
Now flash to image to USB stick, assuming USB stick is on /dev/sdd<br />
$ sudo dd if=tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot the Minnowboard with this image and check to be sure that everything is OK.<br />
<br />
== Working with Yocto kernel ==<br />
=== Checkout kernel source ===<br />
First we must use devtool to checkout the kernel source code in its workspace. Do the following in the ESDK terminal. Note that we use the virtual kernel provider so we don't need to know the kernel recipe name. <br />
<br />
<pre><br />
$ devtool modify virtual/kernel<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Mapping virtual/kernel to linux-yocto<br />
Loading cache: 100% |############################################| Time: 0:00:00<br />
Loaded 1299 entries from dependency cache.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_fetch...<br />
NOTE: Executing do_unpack...<br />
NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_kernel_checkout...<br />
NOTE: Tasks Summary: Attempted 3 tasks of which 2 didn't need to be rerun and all succeeded.<br />
NOTE: Patching...<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_validate_branches...<br />
NOTE: Executing do_kernel_metadata...<br />
NOTE: Executing do_patch...<br />
NOTE: Tasks Summary: Attempted 6 tasks of which 3 didn't need to be rerun and all succeeded.<br />
NOTE: Generating kernel config<br />
NOTE: Executing RunQueue Tasks<br />
NOTE: Executing do_prepare_recipe_sysroot...<br />
NOTE: Executing do_kernel_configme...<br />
NOTE: Executing do_configure...<br />
NOTE: Tasks Summary: Attempted 9 tasks of which 6 didn't need to be rerun and all succeeded.<br />
NOTE: Copying kernel config to srctree<br />
NOTE: Source tree extracted to /home/hbruce/Tools/yocto/kernel/workspace/sources/linux-yocto<br />
NOTE: Recipe linux-yocto now set up to build from /home/hbruce/Tools/yocto/kernel/workspace/sources/linux-yocto<br />
</pre><br />
<br />
There is a bug that may cause error messages such as the following to be displayed. These can be ignored, the source code will be correct checked out.<br />
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus be3a89ce7c47178880ba7bf6293d7404 for /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack<br />
<br />
=== Edit and build driver ===<br />
Kernel source will be in the location shown at end of the <tt>devtool modify virtual/kernel</tt> output. Let's make a trivial change to the serial driver in drivers/tty/serial/8250/8250_core.c. After the line<br />
pr_info("Serial: 8250/16550 driver, %d ports, IRQ sharing %sabled\n",<br />
nr_uarts, share_irqs ? "en" : "dis");<br />
Add the line<br />
pr_info("Serial: 8250/16550 driver modified with eSDK");<br />
To build the updated kernel source, in the SDK terminal run make in your kernel source folder. Adjust the -j option to match number of cores on your workstation.<br />
$ make -C workspace/sources/linux-yocto -j4<br />
=== Create image with new kernel ===<br />
Normally you'd make a new image with <tt>devtool build-image</tt> but this can take a minute or so and messes with the kernel source folder. A faster option is to use kpartx to splice the new kernel into the image you have already built. First make a copy of your wic file in say /tmp<br />
$ cp tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.wic /tmp<br />
Then create loopback devices for each partition in wic file<br />
$ sudo kpartx -v -a /tmp/core-image-minimal-genericx86-64.wic<br />
add map loop3p1 (253:6): 0 47446 linear /dev/loop3 2048<br />
add map loop3p2 (253:7): 0 119356 linear /dev/loop3 51200<br />
add map loop3p3 (253:8): 0 90112 linear /dev/loop3 170556<br />
Kernel is in the first device, so let's mount /dev/mapper/loop3p1 to take a look<br />
$ sudo mkdir /mnt/wic-p1<br />
$ sudo mount /dev/mapper/loop3p1 /mnt/wic-p1<br />
Now copy over new kernel<br />
$ sudo cp workspace/sources/linux-yocto/arch/x86/boot/bzImage /mnt/wic-p1<br />
Then unmount and unkaprtx...<br />
$ sudo umount mnt/wic-p1<br />
$ sudo kaprtx -d /dev/loop3<br />
Now flash image<br />
$ dd if=/tmp/core-image-minimal-genericx86-64.wic of=/dev/sdd bs=1MB<br />
$ sync<br />
Boot Minnowboard, log on and look in log for driver message<br />
# root@genericx86-64:~# dmesg | grep Serial:<br />
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled<br />
Serial: 8250/16550 driver modified with eSDK<br />
It worked!<br />
<br />
=== Export patches and create a bbappend file ===<br />
To export your commits as patches and a bbappend file use the following command in the ESDK terminal. We'll target the "my-kernel" layer we created in the bitbake terminal <br />
$ devtool finish linux-yocto /path/to/meta-my-kernel<br />
The patches and the bbappend can be found in /path/to/meta-my-kernel/recipes-kernel/linux.<br />
<br />
== Working with upstream kernel ==<br />
Slightly different workflow where we use a kernel from kernel.org.<br />
<br />
Content TBD<br />
<br />
== Build image with your modified kernel ==<br />
You can now build an image which will include your kernel patches.<br />
Execute the following command from your build directory in the bitbake terminal<br />
bitbake core-image-minimal</div>Scottrif