diff options
Diffstat (limited to 'poky/documentation')
| -rw-r--r-- | poky/documentation/Makefile | 4 | ||||
| -rw-r--r-- | poky/documentation/dev-manual/dev-manual-common-tasks.xml | 320 | ||||
| -rw-r--r-- | poky/documentation/dev-manual/figures/cute-files-npm-example.png | bin | 0 -> 26248 bytes | |||
| -rw-r--r-- | poky/documentation/mega-manual/figures/cute-files-npm-example.png | bin | 0 -> 26248 bytes | |||
| -rw-r--r-- | poky/documentation/overview-manual/overview-manual-concepts.xml | 11 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/migration.xml | 4 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/ref-classes.xml | 57 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/ref-devtool-reference.xml | 179 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/ref-features.xml | 4 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/ref-tasks.xml | 44 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/ref-variables.xml | 26 | ||||
| -rw-r--r-- | poky/documentation/sdk-manual/sdk-extensible.xml | 4 |
12 files changed, 495 insertions, 158 deletions
diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile index accf23414f..525a7309aa 100644 --- a/poky/documentation/Makefile +++ b/poky/documentation/Makefile @@ -156,7 +156,7 @@ TARFILES = dev-style.css dev-manual.html \ TARFILES = dev-style.css dev-manual.html figures/buildhistory-web.png \ figures/dev-title.png figures/buildhistory.png \ figures/recipe-workflow.png figures/bitbake-build-flow.png \ - figures/multiconfig_files.png + figures/multiconfig_files.png figures/cute-files-npm-example.png endif MANUALS = $(DOC)/$(DOC).html @@ -260,7 +260,7 @@ TARFILES = mega-manual.html mega-style.css \ figures/sdk-devtool-modify-flow.png \ figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \ figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \ - figures/bb_multiconfig_files.png figures/bitbake-title.png + figures/bb_multiconfig_files.png figures/bitbake-title.png figures/cute-files-npm-example.png endif MANUALS = $(DOC)/$(DOC).html diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml index 8ddcd5b075..9231d1416e 100644 --- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml @@ -4197,11 +4197,27 @@ built by layer recipes. It is recommended to keep recipes up-to-date with upstream version releases. + </para> + + <para> + While several methods exist that allow you upgrade a recipe, + you might consider checking on the upgrade status of a recipe + first. + You can do so using the + <filename>devtool check-upgrade-status</filename> command. + See the + "<ulink url='&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</ulink>" + section in the Yocto Project Reference Manual for more information. + </para> + + <para> + The remainder of this section describes three ways you can + upgrade a recipe. You can use the Automated Upgrade Helper (AUH) to set up automatic version upgrades. Alternatively, you can use <filename>devtool upgrade</filename> to set up semi-automatic version upgrades. - Finally, you can even manually upgrade a recipe by editing the + Finally, you can manually upgrade a recipe by editing the recipe itself. </para> @@ -4320,12 +4336,6 @@ Make these following configurations: <itemizedlist> <listitem><para> - Enable "distrodata" as follows: - <literallayout class='monospaced'> - INHERIT =+ "distrodata" - </literallayout> - </para></listitem> - <listitem><para> If you want to enable <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Build History</ulink>, which is optional, you need the following @@ -8964,11 +8974,17 @@ <link linkend='handling-optional-module-packaging'>Handling optional module packaging</link> </para></listitem> <listitem><para> - <link linkend='using-runtime-package-management'>Using Runtime Package Management</link> + <link linkend='using-runtime-package-management'>Using runtime package management</link> + </para></listitem> + <listitem><para> + <link linkend='generating-and-using-signed-packages'>Generating and using signed packages</link> </para></listitem> <listitem><para> <link linkend='testing-packages-with-ptest'>Setting up and running package test (ptest)</link> </para></listitem> + <listitem><para> + <link linkend='creating-node-package-manager-npm-packages'>Creating node package manager (NPM) packages</link> + </para></listitem> </itemizedlist> </para> @@ -10397,6 +10413,292 @@ </para> </section> </section> + + <section id='creating-node-package-manager-npm-packages'> + <title>Creating Node Package Manager (NPM) Packages</title> + + <para> + <ulink url='https://en.wikipedia.org/wiki/Npm_(software)'>NPM</ulink> + is a package manager for the JavaScript programming + language. + The Yocto Project supports the NPM + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink>. + You can use this fetcher in combination with + <ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename></ulink> + to create recipes that produce NPM packages. + </para> + + <para> + Two workflows exist that allow you to create NPM packages + using <filename>devtool</filename>: the NPM registry modules + method and the NPM project code method. + <note> + While it is possible to create NPM recipes manually, + using <filename>devtool</filename> is far simpler. + </note> + Additionally, some requirements and caveats exist. + </para> + + <section id='npm-package-creation-requirements'> + <title>Requirements and Caveats</title> + + <para> + You need to be aware of the following before using + <filename>devtool</filename> to create NPM packages: + <itemizedlist> + <listitem><para> + Of the two methods that you can use + <filename>devtool</filename> to create NPM + packages, the registry approach is slightly + simpler. + However, you might consider the project + approach because you do not have to publish + your module in the NPM registry + (<ulink url='https://docs.npmjs.com/misc/registry'><filename>npm-registry</filename></ulink>), + which is NPM's public registry. + </para></listitem> + <listitem><para> + Be familiar with + <ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename></ulink>. + </para></listitem> + <listitem><para> + The NPM host tools need the native + <filename>nodejs-npm</filename> package, which + is part of the OpenEmbedded environment. + You need to get the package by cloning the + <ulink url='https://github.com/openembedded/meta-openembedded'></ulink> + repository out of GitHub. + Be sure to add the path to your local copy to + your <filename>bblayers.conf</filename> file. + </para></listitem> + <listitem><para> + <filename>devtool</filename> cannot detect + native libraries in module dependencies. + Consequently, you must manually add packages + to your recipe. + </para></listitem> + <listitem><para> + While deploying NPM packages, + <filename>devtool</filename> cannot determine + which dependent packages are missing on the + target (e.g. the node runtime + <filename>nodejs</filename>). + Consequently, you need to find out what + files are missing and be sure they are on the + target. + </para></listitem> + <listitem><para> + Although you might not need NPM to run your + node package, it is useful to have NPM on your + target. + The NPM package name is + <filename>nodejs-npm</filename>. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='npm-using-the-registry-modules-method'> + <title>Using the Registry Modules Method</title> + + <para> + This section presents an example that uses the + <filename>cute-files</filename> module, which is a + file browser web application. + <note> + You must know the <filename>cute-files</filename> + module version. + </note> + </para> + + <para> + The first thing you need to do is use + <filename>devtool</filename> and the NPM fetcher to + create the recipe: + <literallayout class='monospaced'> + $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2" + </literallayout> + The <filename>devtool add</filename> command runs + <filename>recipetool create</filename> and uses the + same fetch URI to download each dependency and capture + license details where possible. + The result is a generated recipe. + </para> + + <para> + The recipe file is fairly simple and contains every + license that <filename>recipetool</filename> finds + and includes the licenses in the recipe's + <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink> + variables. + You need to examine the variables and look for those + with "unknown" in the + <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink> + field. + You need to track down the license information for + "unknown" modules and manually add the information to the + recipe. + </para> + + <para> + <filename>recipetool</filename> creates "shrinkwrap" and + "lockdown" files for your recipe. + Shrinkwrap files capture the version of all dependent + modules. + Many packages do not provide shrinkwrap files. + <filename>recipetool</filename> create a shrinkwrap + file as it runs. + You can replace the shrinkwrap file with your own file + by setting the <filename>NPM_SHRINKWRAP</filename> + variable. + </para> + + <para> + Lockdown files contain the checksum for each module + to determine if your users download the same files when + building with a recipe. + Lockdown files ensure that dependencies have not been + changed and that your NPM registry is still providing + the same file. + <note> + A package is created for each sub-module. + This policy is the only practical way to have the + licenses for all of the dependencies represented + in the license manifest of the image. + </note> + </para> + + <para> + The <filename>devtool edit-recipe</filename> command + lets you take a look at the recipe: + <literallayout class='monospaced'> + $ devtool edit-recipe cute-files + SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network." + LICENSE = "BSD-3-Clause & Unknown & MIT & ISC" + LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \ + file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \ + file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \ + ... + + SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}" + NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json" + NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json" + inherit npm + # Must be set after inherit npm since that itself sets S + S = "${WORKDIR}/npmpkg" + + LICENSE_${PN}-content-disposition = "MIT" + ... + LICENSE_${PN}-express = "MIT" + LICENSE_${PN} = "MIT" + </literallayout> + Three key points exist in the previous example: + <itemizedlist> + <listitem><para> + <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> + uses the NPM scheme so that the NPM fetcher + is used. + </para></listitem> + <listitem><para> + <filename>recipetool</filename> collects all + the license information. + If a sub-module's license is unavailable, + the sub-module's name appears in the comments. + </para></listitem> + <listitem><para> + The <filename>inherit npm</filename> statement + causes the + <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-npm'><filename>npm</filename></ulink> + class to package up all the modules. + </para></listitem> + </itemizedlist> + </para> + + <para> + You can run the following command to build the + <filename>cute-files</filename> package: + <literallayout class='monospaced'> + $ devtool build cute-files + </literallayout> + Remember that <filename>nodejs</filename> must be + installed on the target before your package. + </para> + + <para> + Assuming 192.168.7.2 for the target's IP address, use + the following command to deploy your package: + <literallayout class='monospaced'> + $ devtool deploy-target -s cute-files root@192.168.7.2 + </literallayout> + Once the package is installed on the target, you can + test the application: + <note> + Because of a know issue, you cannot simply run + <filename>cute-files</filename> as you would if you + had run <filename>npm install</filename>. + </note> + <literallayout class='monospaced'> + $ cd /usr/lib/node_modules/cute-files + $ node cute-files.js + </literallayout> + On a browser, go to + <filename>http://192.168.7.2:3000</filename> and you + see the following: + <imagedata fileref="figures/cute-files-npm-example.png" align="center" width="6in" depth="4in" /> + </para> + + <para> + You can find the recipe in + <filename>workspace/recipes/cute-files</filename>. + You can use the recipe in any layer you choose. + </para> + </section> + + <section id='npm-using-the-npm-projects-method'> + <title>Using the NPM Projects Code Method</title> + + <para> + Although it is useful to package modules already in the + NPM registry, adding <filename>node.js</filename> projects + under development is a more common developer use case. + </para> + + <para> + This section covers the NPM projects code method, which is + very similar to the "registry" approach described in the + previous section. + In the NPM projects method, you provide + <filename>devtool</filename> with an URL that points to the + source files. + </para> + + <para> + Replicating the same example, (i.e. + <filename>cute-files</filename>) use the following command: + <literallayout class='monospaced'> + $ devtool add https://github.com/martinaglv/cute-files.git + </literallayout> + The recipe this command generates is very similar to the + recipe created in the previous section. + However, the <filename>SRC_URI</filename> looks like the + following: + <literallayout class='monospaced'> + SRC_URI = "git://github.com/martinaglv/cute-files.git;protocol=https \ + npm://registry.npmjs.org;name=commander;version=2.9.0;subdir=node_modules/commander \ + npm://registry.npmjs.org;name=express;version=4.14.0;subdir=node_modules/express \ + npm://registry.npmjs.org;name=content-disposition;version=0.3.0;subdir=node_modules/content-disposition \ + " + </literallayout> + In this example, the main module is taken from the Git + repository and dependents are taken from the NPM registry. + Other than those differences, the recipe is basically the + same between the two methods. + You can build and deploy the package exactly as described + in the previous section that uses the registry modules + method. + </para> + </section> + </section> </section> <section id='efficiently-fetching-source-files-during-a-build'> @@ -10519,7 +10821,7 @@ <title>Using systemd Exclusively</title> <para> - Set the these variables in your distribution configuration + Set these variables in your distribution configuration file as follows: <literallayout class='monospaced'> DISTRO_FEATURES_append = " systemd" diff --git a/poky/documentation/dev-manual/figures/cute-files-npm-example.png b/poky/documentation/dev-manual/figures/cute-files-npm-example.png Binary files differnew file mode 100644 index 0000000000..1ebe74f535 --- /dev/null +++ b/poky/documentation/dev-manual/figures/cute-files-npm-example.png diff --git a/poky/documentation/mega-manual/figures/cute-files-npm-example.png b/poky/documentation/mega-manual/figures/cute-files-npm-example.png Binary files differnew file mode 100644 index 0000000000..1ebe74f535 --- /dev/null +++ b/poky/documentation/mega-manual/figures/cute-files-npm-example.png diff --git a/poky/documentation/overview-manual/overview-manual-concepts.xml b/poky/documentation/overview-manual/overview-manual-concepts.xml index 8a1b38c87d..f085dd710d 100644 --- a/poky/documentation/overview-manual/overview-manual-concepts.xml +++ b/poky/documentation/overview-manual/overview-manual-concepts.xml @@ -924,17 +924,18 @@ <title>Source Control Managers (Optional)</title> <para> - Another place the build system can get source files from is - through a Source Control Manager (SCM) such as Git or - Subversion. + Another place from which the build system can get source + files is with + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink> + employing various Source Control Managers (SCMs) such as + Git or Subversion. In such cases, a repository is cloned or checked out. The <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink> task inside BitBake uses the <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable and the argument's prefix to determine the correct - <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'><filename>fetcher</filename></ulink> - module. + fetcher module. <note> For information on how to have the OpenEmbedded build system generate tarballs for Git repositories and place diff --git a/poky/documentation/ref-manual/migration.xml b/poky/documentation/ref-manual/migration.xml index 1ecf5b9996..ade8787b4d 100644 --- a/poky/documentation/ref-manual/migration.xml +++ b/poky/documentation/ref-manual/migration.xml @@ -2566,9 +2566,7 @@ <link linkend='oe-core'>OE-Core</link>. The change includes <filename>package_regex.inc</filename> and <filename>distro_alias.inc</filename>, which are typically enabled - when using the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class. + when using the <filename>distrodata</filename> class. Additionally, the contents of <filename>upstream_tracking.inc</filename> has now been split out to the relevant recipes. diff --git a/poky/documentation/ref-manual/ref-classes.xml b/poky/documentation/ref-manual/ref-classes.xml index d602851c54..ece47e757b 100644 --- a/poky/documentation/ref-manual/ref-classes.xml +++ b/poky/documentation/ref-manual/ref-classes.xml @@ -335,18 +335,6 @@ </para> </section> -<section id='ref-classes-bugzilla'> - <title><filename>bugzilla.bbclass</filename></title> - - <para> - The <filename>bugzilla</filename> class supports setting up an - instance of Bugzilla in which you can automatically files bug reports - in response to build failures. - For this class to work, you need to enable the XML-RPC interface in - the instance of Bugzilla. - </para> -</section> - <section id='ref-classes-buildhistory'> <title><filename>buildhistory.bbclass</filename></title> @@ -714,39 +702,6 @@ </para> </section> -<section id='ref-classes-distrodata'> - <title><filename>distrodata.bbclass</filename></title> - - <para> - The <filename>distrodata</filename> class - provides for automatic checking for upstream recipe updates. - The class creates a comma-separated value (CSV) spreadsheet that - contains information about the recipes. - The information provides the - <link linkend='ref-tasks-distrodata'><filename>do_distrodata</filename></link> - and - <filename>do_distro_check</filename> tasks, which do upstream checking - and also verify if a package is used in multiple major distributions. - </para> - - <para> - The class is not included by default. - To use it, you must set the - <link linkend='var-INHERIT'><filename>INHERIT</filename></link> - variable: - <literallayout class='monospaced'> - INHERIT+= "distrodata" - </literallayout> - </para> - - <para> - The <filename>distrodata</filename> class also provides the - <link linkend='ref-tasks-checkpkg'><filename>do_checkpkg</filename></link> - task, which can be used against a simple recipe or against an - image to get all its recipe information. - </para> -</section> - <section id='ref-classes-distutils'> <title><filename>distutils*.bbclass</filename></title> @@ -776,11 +731,6 @@ some of the <filename>distutils*</filename> classes to provide common Python2 support. </para> - - <para> - The <filename>distutils-tools</filename> class supports recipes for - additional "distutils" tools. - </para> </section> <section id='ref-classes-distutils3'> @@ -2335,13 +2285,16 @@ This check was removed for YP 2.3 release <title><filename>npm.bbclass</filename></title> <para> - Provides support for building Node.js software fetched using the npm - package manager. + Provides support for building Node.js software fetched using the + <ulink url='https://en.wikipedia.org/wiki/Npm_(software)'>node package manager (NPM)</ulink>. <note> Currently, recipes inheriting this class must use the <filename>npm://</filename> fetcher to have dependencies fetched and packaged automatically. </note> + For information on how to create NPM packages, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-node-package-manager-npm-packages'>Creating Node Package Manager (NPM) Packages</ulink>" + section in the Yocto Project Development Tasks Manual. </para> </section> diff --git a/poky/documentation/ref-manual/ref-devtool-reference.xml b/poky/documentation/ref-manual/ref-devtool-reference.xml index b974d0f595..4810d28ad1 100644 --- a/poky/documentation/ref-manual/ref-devtool-reference.xml +++ b/poky/documentation/ref-manual/ref-devtool-reference.xml @@ -34,7 +34,7 @@ You can run <filename>devtool --help</filename> to see all the commands: <literallayout class='monospaced'> - $ devtool --help + $ devtool -h NOTE: Starting bitbake server... usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] @@ -43,50 +43,48 @@ OpenEmbedded development tool options: - --basepath BASEPATH Base directory of SDK / build directory - --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it - from the metadata - -d, --debug Enable debug output - -q, --quiet Print only errors - --color COLOR Colorize output (where COLOR is auto, always, never) - -h, --help show this help message and exit + --basepath BASEPATH Base directory of SDK / build directory + --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it + from the metadata + -d, --debug Enable debug output + -q, --quiet Print only errors + --color COLOR Colorize output (where COLOR is auto, always, never) + -h, --help show this help message and exit subcommands: Beginning work on a recipe: - add Add a new recipe - modify Modify the source for an existing recipe - upgrade Upgrade an existing recipe + add Add a new recipe + modify Modify the source for an existing recipe + upgrade Upgrade an existing recipe Getting information: - status Show workspace status - search Search available recipes - latest-version Report the latest version of an existing recipe + status Show workspace status + search Search available recipes + latest-version Report the latest version of an existing recipe + check-upgrade-status Report upgradability for multiple (or all) recipes Working on a recipe in the workspace: - build Build a recipe - rename Rename a recipe file in the workspace - edit-recipe Edit a recipe file - find-recipe Find a recipe file - configure-help Get help on configure script options - update-recipe Apply changes from external source tree to recipe - reset Remove a recipe from your workspace - finish Finish working on a recipe in your workspace + build Build a recipe + rename Rename a recipe file in the workspace + edit-recipe Edit a recipe file + find-recipe Find a recipe file + configure-help Get help on configure script options + update-recipe Apply changes from external source tree to recipe + reset Remove a recipe from your workspace + finish Finish working on a recipe in your workspace Testing changes on target: - deploy-target Deploy recipe output files to live target machine - undeploy-target Undeploy recipe output files in live target machine - build-image Build image including workspace recipe packages + deploy-target Deploy recipe output files to live target machine + undeploy-target Undeploy recipe output files in live target machine + build-image Build image including workspace recipe packages Advanced: - create-workspace Set up workspace in an alternative location - export Export workspace into a tar archive - import Import exported tar archive into workspace - extract Extract the source for an existing recipe - sync Synchronize the source tree for an existing recipe + create-workspace Set up workspace in an alternative location + export Export workspace into a tar archive + import Import exported tar archive into workspace + extract Extract the source for an existing recipe + sync Synchronize the source tree for an existing recipe Use devtool <subcommand> --help to get help on a specific command </literallayout> - </para> - - <para> - As directed in the general help output, you can get more - syntax on a specific command by providing the command - name and using <filename>--help</filename>: + As directed in the general help output, you can get more syntax + on a specific command by providing the command name and using + "--help": <literallayout class='monospaced'> $ devtool add --help NOTE: Starting bitbake server... @@ -429,6 +427,108 @@ </para> </section> + <section id='devtool-checking-on-the-upgrade-status-of-a-recipe'> + <title>Checking on the Upgrade Status of a Recipe</title> + + <para> + Upstream recipes change over time. + Consequently, you might find that you need to determine if you + can upgrade a recipe to a newer version. + </para> + + <para> + To check on the upgrade status of a recipe, use the + <filename>devtool check-upgrade-status</filename> command. + The command displays a table of your current recipe versions, + the latest upstream versions, the email address of the recipe's + maintainer, and any additional information such as commit hash + strings and reasons you might not be able to upgrade a particular + recipe. + <note><title>NOTES:</title> + <itemizedlist> + <listitem><para> + For the <filename>oe-core</filename> layer, recipe + maintainers come from the + <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc'><filename>maintainers.inc</filename></ulink> + file. + </para></listitem> + <listitem><para> + If the recipe is using the + <ulink url='&YOCTO_DOCS_BB_URL;#git-fetcher'>Git fetcher</ulink> + rather than a tarball, the commit hash points to the + commit that matches the recipe's latest version tag. + </para></listitem> + </itemizedlist> + </note> + </para> + + <para> + As with all <filename>devtool</filename> commands, you can get + help on the individual command: + <literallayout class='monospaced'> + $ devtool check-upgrade-status -h + NOTE: Starting bitbake server... + usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]] + + Prints a table of recipes together with versions currently provided by + recipes, and latest upstream versions, when there is a later version available + + arguments: + recipe Name of the recipe to report (omit to report upgrade info for + all recipes) + + options: + -h, --help show this help message and exit + --all, -a Show all recipes, not just recipes needing upgrade + </literallayout> + </para> + + <para> + Unless you provide a specific recipe name on the command line, + the command checks all recipes in all configured layers. + </para> + + <para> + Following is a partial example table that reports on all the + recipes. + Notice the reported reason for not upgrading the + <filename>base-passwd</filename> recipe. + In this example, while a new version is available upstream, + you do not want to use it because the dependency on + <filename>cdebconf</filename> is not easily satisfied. + <note> + When a reason for not upgrading displays, the reason is + usually written into the recipe using the + <filename>RECIPE_NO_UPDATE_REASON</filename> variable. + See the + <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb'><filename>base-passwd.bb</filename></ulink> + recipe for an example. + </note> + <literallayout class='monospaced'> + $ devtool check-upgrade-status + ... + NOTE: acpid 2.0.30 2.0.31 + Ross Burton <ross.burton@intel.com> + NOTE: u-boot-fw-utils 2018.11 2019.01 + Marek Vasut <marek.vasut@gmail.com> + d3689267f92c5956e09cc7d1baa4700141662bff + NOTE: u-boot-tools 2018.11 2019.01 + Marek Vasut <marek.vasut@gmail.com> + d3689267f92c5956e09cc7d1baa4700141662bff + . + . + . + NOTE: base-passwd 3.5.29 3.5.45 + Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version + 3.5.38 requires cdebconf for update-passwd utility + NOTE: busybox 1.29.2 1.30.0 + Andrej Valek <andrej.valek@siemens.com> + NOTE: dbus-test 1.12.10 1.12.12 + Chen Qi <Qi.Chen@windriver.com> + </literallayout> + </para> + </section> + <section id='devtool-upgrading-a-recipe'> <title>Upgrading a Recipe</title> @@ -443,6 +543,13 @@ section of the Yocto Project Development Tasks Manual. This section overviews the <filename>devtool upgrade</filename> command. + <note> + Before you upgrade a recipe, you can check on its upgrade + status. + See the + "<link linkend='devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</link>" + for more information. + </note> </para> <para> diff --git a/poky/documentation/ref-manual/ref-features.xml b/poky/documentation/ref-manual/ref-features.xml index 7a3555d0b9..b057d2d040 100644 --- a/poky/documentation/ref-manual/ref-features.xml +++ b/poky/documentation/ref-manual/ref-features.xml @@ -76,8 +76,6 @@ </para></listitem> <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive </para></listitem> - <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support - </para></listitem> <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard </para></listitem> <listitem><para><emphasis>pcbios:</emphasis> Support for booting through BIOS @@ -190,8 +188,6 @@ support.</para></listitem> <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support. </para></listitem> - <listitem><para><emphasis>irda:</emphasis> Include IrDA support. - </para></listitem> <listitem><para><emphasis>keyboard:</emphasis> Include keyboard support (e.g. keymaps will be loaded during boot). </para></listitem> diff --git a/poky/documentation/ref-manual/ref-tasks.xml b/poky/documentation/ref-manual/ref-tasks.xml index 8f3ff26d24..011e0d7496 100644 --- a/poky/documentation/ref-manual/ref-tasks.xml +++ b/poky/documentation/ref-manual/ref-tasks.xml @@ -158,32 +158,6 @@ </para> </section> - <section id='ref-tasks-distrodata'> - <title><filename>do_distrodata</filename></title> - - <para> - Provides information about the recipe. - </para> - - <para> - The <filename>distrodata</filename> task is included as part of the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class. - </para> - - <para> - To build the <filename>distrodata</filename> task, use the - <filename>bitbake</filename> command with the "-c" option and - task name: - <literallayout class='monospaced'> - $ bitbake core-image-minimal -c distrodata - </literallayout> - By default, the results are stored in - <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link> - (e.g. <filename>$BUILD_DIR/tmp/log</filename>). - </para> - </section> - <section id='ref-tasks-fetch'> <title><filename>do_fetch</filename></title> @@ -192,7 +166,8 @@ This task uses the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> variable and the argument's prefix to determine the correct - fetcher module. + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink> + module. </para> </section> @@ -635,9 +610,18 @@ </para> <para> - The <filename>checkpkg</filename> task is included as part of the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class. + To check the upstream version and status of a recipe, use the + following devtool commands: + <literallayout class='monospaced'> + $ devtool latest-version + $ devtool check-upgrade-status + </literallayout> + See the + "<link linkend='ref-devtool-reference'><filename>devtool</filename> Quick Reference</link>" + chapter for more information on <filename>devtool</filename>. + See the + "<ulink url='&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</ulink>" + section for information on checking the upgrade status of a recipe. </para> <para> diff --git a/poky/documentation/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml index 0d01c16ddb..12876e3d9a 100644 --- a/poky/documentation/ref-manual/ref-variables.xml +++ b/poky/documentation/ref-manual/ref-variables.xml @@ -16629,16 +16629,16 @@ <glossdef> <para role="glossdeffirst"> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - When the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class is enabled globally, you can perform a per-recipe - check for what the latest upstream source code version is - by calling + You can perform a per-recipe check for what the latest + upstream source code version is by calling <filename>bitbake -c checkpkg</filename> <replaceable>recipe</replaceable>. If the recipe source code is provided from Git repositories, the OpenEmbedded build system determines the latest upstream version by picking the latest tag from the list of all repository tags. + </para> + + <para> You can use the <filename>UPSTREAM_CHECK_GITTAGREGEX</filename> variable to provide a regular expression to filter only the @@ -16658,11 +16658,8 @@ <glossdef> <para role="glossdeffirst"> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - When the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class is enabled globally, use the - <filename>UPSTREAM_CHECK_REGEX</filename> variable to - specify a different regular expression instead of the + Use the <filename>UPSTREAM_CHECK_REGEX</filename> variable + to specify a different regular expression instead of the default one when the package checking system is parsing the page found using <link linkend='var-UPSTREAM_CHECK_URI'><filename>UPSTREAM_CHECK_URI</filename></link>. @@ -16680,12 +16677,9 @@ <glossdef> <para role="glossdeffirst"> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> - When the - <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link> - class is enabled globally, you can perform a per-recipe - check for what the latest upstream source code version is - by calling <filename>bitbake -c checkpkg</filename> - <replaceable>recipe</replaceable>. + You can perform a per-recipe check for what the latest + upstream source code version is by calling + <filename>bitbake -c checkpkg</filename> <replaceable>recipe</replaceable>. If the source code is provided from tarballs, the latest version is determined by fetching the directory listing where the tarball is and attempting to find a later tarball. diff --git a/poky/documentation/sdk-manual/sdk-extensible.xml b/poky/documentation/sdk-manual/sdk-extensible.xml index f7c5c00b8b..bd5278493f 100644 --- a/poky/documentation/sdk-manual/sdk-extensible.xml +++ b/poky/documentation/sdk-manual/sdk-extensible.xml @@ -825,7 +825,9 @@ versioning schemes, extract code into or out of the <filename>devtool</filename> <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>, - and work with any source file forms that the fetchers support. + and work with any source file forms that the + <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink> + support. </para> <para> |
