diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2021-02-13 00:55:30 +0300 |
|---|---|---|
| committer | Brad Bishop <bradleyb@fuzziesquirrel.com> | 2021-02-25 23:15:06 +0300 |
| commit | 706d5aacd7ab7b37c00df1a1b210e4ced06119e1 (patch) | |
| tree | ed0bec373424d01accfb2e9c895c177a3e2d7abe /poky/documentation | |
| parent | ac970dd705934286df062e0f1501f776dc2ef01d (diff) | |
| download | openbmc-706d5aacd7ab7b37c00df1a1b210e4ced06119e1.tar.xz | |
Reset poky to before our libpam hacks
Things got a bit out of synch with openbmc-config due to the libpam
issues and the migration from the meta-* layers.
Revert the two previous commits and then put the latest poky in with the
libpam revert and get openbmc-config right again.
Revert "Revert "libpam: update 1.3.1 -> 1.5.1""
This reverts commit 87ddd3eab4df68e624b5350ccaab28b3b97547c0.
Revert "poky: subtree update:796be0593a..10c69538c0"
This reverts commit c723b72979bfac6362509cf1fe086900f6641f28.
Change-Id: I3a1f405193aee6a21fe0cd24be9927c143a23d9a
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Diffstat (limited to 'poky/documentation')
32 files changed, 148 insertions, 182 deletions
diff --git a/poky/documentation/README b/poky/documentation/README index be03bb119a..b0a3cb1dc0 100644 --- a/poky/documentation/README +++ b/poky/documentation/README @@ -2,7 +2,7 @@ documentation ============= This is the directory that contains the Yocto Project documentation. The Yocto -Project source repositories at https://git.yoctoproject.org/cgit.cgi have two +Project source repositories at http://git.yoctoproject.org/cgit.cgi have two instances of the "documentation" directory. You should understand each of these instances. @@ -47,12 +47,12 @@ Folders exist for individual manuals as follows: Each folder is self-contained regarding content and figures. If you want to find HTML versions of the Yocto Project manuals on the web, -go to https://www.yoctoproject.org and click on the "Documentation" tab. From +go to http://www.yoctoproject.org and click on the "Documentation" tab. From there you have access to archived documentation from previous releases, current documentation for the latest release, and "Docs in Progress" for the release currently being developed. -In general, the Yocto Project site (https://www.yoctoproject.org) is a great +In general, the Yocto Project site (http://www.yoctoproject.org) is a great reference for both information and downloads. poky.yaml @@ -228,7 +228,7 @@ content: Variables can be nested, like it was the case for DocBook: - YOCTO_HOME_URL : "https://www.yoctoproject.org" + YOCTO_HOME_URL : "http://www.yoctoproject.org" YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs" Note directive diff --git a/poky/documentation/boilerplate.rst b/poky/documentation/boilerplate.rst index 2ad60eb8b9..ddffdac242 100644 --- a/poky/documentation/boilerplate.rst +++ b/poky/documentation/boilerplate.rst @@ -8,7 +8,7 @@ Permission is granted to copy, distribute and/or modify this document under the terms of the `Creative Commons Attribution-Share Alike 2.0 UK: England & Wales -<https://creativecommons.org/licenses/by-sa/2.0/uk/>`_ as published by Creative +<http://creativecommons.org/licenses/by-sa/2.0/uk/>`_ as published by Creative Commons. To report any inaccuracies or problems with this (or any other Yocto Project) diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst index 63083cb13d..f077ee843d 100644 --- a/poky/documentation/brief-yoctoprojectqs/index.rst +++ b/poky/documentation/brief-yoctoprojectqs/index.rst @@ -397,7 +397,7 @@ information including the website, wiki pages, and user manuals: Development Community into which you can tap. - **Developer Screencast:** The `Getting Started with the Yocto Project - - New Developer Screencast Tutorial <https://vimeo.com/36450321>`__ + New Developer Screencast Tutorial <http://vimeo.com/36450321>`__ provides a 30-minute video created for users unfamiliar with the Yocto Project but familiar with Linux build hosts. While this screencast is somewhat dated, the introductory and fundamental diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index 93e9182490..068ab6c804 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -894,8 +894,8 @@ Yocto Project: ``recipes-*`` subdirectories specific to the recipe's function, or within a subdirectory containing a set of closely-related recipes. The recipes themselves should follow the general guidelines for - recipes used in the Yocto Project found in the ":oe_wiki:`OpenEmbedded - Style Guide </Styleguide>`". + recipes used in the Yocto Project found in the "`OpenEmbedded Style + Guide <http://openembedded.org/wiki/Styleguide>`__". - *License File:* You must include a license file in the ``meta-bsp_root_name`` directory. This license covers the BSP diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py index 407ea3292f..a626b1f14d 100644 --- a/poky/documentation/conf.py +++ b/poky/documentation/conf.py @@ -68,7 +68,7 @@ rst_prolog = """ # external links and substitutions extlinks = { - 'yocto_home': ('https://www.yoctoproject.org%s', None), + 'yocto_home': ('https://yoctoproject.org%s', None), 'yocto_wiki': ('https://wiki.yoctoproject.org/wiki%s', None), 'yocto_dl': ('https://downloads.yoctoproject.org%s', None), 'yocto_lists': ('https://lists.yoctoproject.org%s', None), @@ -79,9 +79,6 @@ extlinks = { 'oe_home': ('https://www.openembedded.org%s', None), 'oe_lists': ('https://lists.openembedded.org%s', None), 'oe_git': ('https://git.openembedded.org%s', None), - 'oe_wiki': ('https://www.openembedded.org/wiki%s', None), - 'oe_layerindex': ('https://layers.openembedded.org%s', None), - 'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None), } # Intersphinx config to use cross reference with Bitbake user manual diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst index e1dee8ecdd..ada3bac7e1 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -38,8 +38,9 @@ Follow these general steps to create your layer without using tools: 1. *Check Existing Layers:* Before creating a new layer, you should be sure someone has not already created a layer containing the Metadata - you need. You can see the :oe_layerindex:`OpenEmbedded Metadata Index <>` - for a list of layers from the OpenEmbedded community that can be used in + you need. You can see the `OpenEmbedded Metadata + Index <https://layers.openembedded.org/layerindex/layers/>`__ for a + list of layers from the OpenEmbedded community that can be used in the Yocto Project. You could find a layer that is identical or close to what you need. @@ -321,7 +322,7 @@ Logo for your layer and application. The process consists of two parts: successful compatibility registration. 2. Completion of an application acceptance form, which you can find at - :yocto_home:`/webform/yocto-project-compatible-registration`. + https://www.yoctoproject.org/webform/yocto-project-compatible-registration. To be granted permission to use the logo, you need to satisfy the following: @@ -345,7 +346,7 @@ application, you can use the Yocto Project Compatibility Logo with your layer and the application that uses your layer. To access the form, use this link: -:yocto_home:`/webform/yocto-project-compatible-registration`. +https://www.yoctoproject.org/webform/yocto-project-compatible-registration. Follow the instructions on the form to complete your application. The application consists of the following sections: @@ -1193,8 +1194,8 @@ Before writing a recipe from scratch, it is often useful to discover whether someone else has already written one that meets (or comes close to meeting) your needs. The Yocto Project and OpenEmbedded communities maintain many recipes that might be candidates for what you are doing. -You can find a good central index of these recipes in the -:oe_layerindex:`OpenEmbedded Layer Index <>`. +You can find a good central index of these recipes in the `OpenEmbedded +Layer Index <https://layers.openembedded.org>`__. Working from an existing recipe or a skeleton recipe is the best way to get started. Here are some points on both methods: @@ -2539,7 +2540,7 @@ Following Recipe Style Guidelines --------------------------------- When writing recipes, it is good to conform to existing style -guidelines. The :oe_wiki:`OpenEmbedded Styleguide </Styleguide>` wiki page +guidelines. The :oe_home:`OpenEmbedded Styleguide </wiki/Styleguide>` wiki page provides rough guidelines for preferred recipe style. It is common for existing recipes to deviate a bit from this style. @@ -6043,7 +6044,7 @@ the Internet: Botnet - *"*\ `Security Issues for Embedded - Devices <https://elinux.org/images/6/6f/Security-issues.pdf>`__\ *"* + Devices <http://elinux.org/images/6/6f/Security-issues.pdf>`__\ *"* by Jake Edge When securing your image is of concern, there are steps, tools, and diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst index f6c9b97137..c95d2f7cb9 100644 --- a/poky/documentation/kernel-dev/intro.rst +++ b/poky/documentation/kernel-dev/intro.rst @@ -72,7 +72,8 @@ tools with your own kernel sources. The remainder of this manual provides instructions for completing specific Linux kernel development tasks. These instructions assume you -are comfortable working with :oe_wiki:`BitBake </Bitbake>` recipes and basic +are comfortable working with +`BitBake <https://openembedded.org/wiki/Bitbake>`__ recipes and basic open-source development tools. Understanding these concepts will facilitate the process of working with the kernel recipes. If you find you need some additional background, please be sure to review and diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst index 257de44ec8..8fbbabbac5 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -141,10 +141,12 @@ hardware-specific configurations allows you to share other metadata by using a different layer where that metadata might be common across several pieces of hardware. -Many layers exist that work in the Yocto Project development environment. The -:yocto_home:`Yocto Project Curated Layer Index </software-overview/layers/>` -and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from -which you can use or leverage. +Many layers exist that work in the Yocto Project development +environment. The `Yocto Project Curated Layer +Index <https://www.yoctoproject.org/software-overview/layers/>`__ +and `OpenEmbedded Layer +Index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__ +both contain layers from which you can use or leverage. By convention, layers in the Yocto Project follow a specific form. Conforming to a known structure allows BitBake to make assumptions @@ -378,11 +380,13 @@ figure <#general-workflow-figure>`__: - *Metadata (.bb + Patches):* Software layers containing user-supplied recipe files, patches, and append files. A good example - of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>` - from the :oe_layerindex:`OpenEmbedded Layer Index <>`. This layer is for - version 5.0 of the popular `Qt <https://wiki.qt.io/About_Qt>`__ - cross-platform application development framework for desktop, embedded and - mobile. + of a software layer might be the + `meta-qt5 layer <https://github.com/meta-qt5/meta-qt5>`__ from + the `OpenEmbedded Layer + Index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__. + This layer is for version 5.0 of the popular + `Qt <https://wiki.qt.io/About_Qt>`__ cross-platform application + development framework for desktop, embedded and mobile. - *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e. "BSP Layer" in the following figure) providing machine-specific @@ -2092,8 +2096,10 @@ The capability to run tasks in a fake root environment is known as the BitBake keyword/variable flag that requests a fake root environment for a task. -In the :term:`OpenEmbedded Build System`, the program that implements -fakeroot is known as :yocto_home:`Pseudo </software-item/pseudo/>`. Pseudo +In the :term:`OpenEmbedded Build System`, +the program that +implements fakeroot is known as +`Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo overrides system calls by using the environment variable ``LD_PRELOAD``, which results in the illusion of running as root. To keep track of "fake" file ownership and permissions resulting from operations that diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst index 011a479578..9a2997d9fc 100644 --- a/poky/documentation/overview-manual/development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -40,7 +40,7 @@ project is the Windows family of operating systems developed by Microsoft Corporation. Wikipedia has a good historical description of the Open Source -Philosophy `here <https://en.wikipedia.org/wiki/Open_source>`__. You can +Philosophy `here <http://en.wikipedia.org/wiki/Open_source>`__. You can also find helpful information on how to participate in the Linux Community `here <https://www.kernel.org/doc/html/latest/process/index.html>`__. @@ -291,7 +291,7 @@ While each development environment is unique, there are some best practices or methods that help development run smoothly. The following list describes some of these practices. For more information about Git workflows, see the workflow topics in the `Git Community -Book <https://book.git-scm.com>`__. +Book <http://book.git-scm.com>`__. - *Make Small Changes:* It is best to keep the changes you commit small as compared to bundling many disparate changes into a single commit. @@ -368,12 +368,12 @@ commands. .. note:: - For more information on Git, see - https://git-scm.com/documentation. + http://git-scm.com/documentation. - If you need to download Git, it is recommended that you add Git to your system through your distribution's "software store" (e.g. for Ubuntu, use the Ubuntu Software feature). For the Git download - page, see https://git-scm.com/download. + page, see http://git-scm.com/download. - For information beyond the introductory nature in this section, see the ":ref:`dev-manual/start:locating yocto project source files`" @@ -507,7 +507,7 @@ you can manage with a small set of basic operations and workflows once you understand the basic philosophy behind Git. You do not have to be an expert in Git to be functional. A good place to look for instruction on a minimal set of Git commands is -`here <https://git-scm.com/documentation>`__. +`here <http://git-scm.com/documentation>`__. The following list of Git commands briefly describes some basic Git operations as a way to get started. As with any set of commands, this @@ -614,10 +614,10 @@ and Free Software has an interesting history. If you are interested in this history, you can find basic information here: - `Open source license - history <https://en.wikipedia.org/wiki/Open-source_license>`__ + history <http://en.wikipedia.org/wiki/Open-source_license>`__ - `Free software license - history <https://en.wikipedia.org/wiki/Free_software_license>`__ + history <http://en.wikipedia.org/wiki/Free_software_license>`__ In general, the Yocto Project is broadly licensed under the Massachusetts Institute of Technology (MIT) License. MIT licensing @@ -626,9 +626,9 @@ license is distributed with that software. MIT is also compatible with the GNU General Public License (GPL). Patches to the Yocto Project follow the upstream licensing scheme. You can find information on the MIT license -`here <https://www.opensource.org/licenses/mit-license.php>`__. You can +`here <http://www.opensource.org/licenses/mit-license.php>`__. You can find information on the GNU GPL -`here <https://www.opensource.org/licenses/LGPL-3.0>`__. +`here <http://www.opensource.org/licenses/LGPL-3.0>`__. When you build an image using the Yocto Project, the build process uses a known list of licenses to ensure compliance. You can find this list in @@ -646,11 +646,11 @@ the developer to resolve potential licensing issues. The base list of licenses used by the build process is a combination of the Software Package Data Exchange (SPDX) list and the Open Source -Initiative (OSI) projects. `SPDX Group <https://spdx.org>`__ is a working +Initiative (OSI) projects. `SPDX Group <http://spdx.org>`__ is a working group of the Linux Foundation that maintains a specification for a standard format for communicating the components, licenses, and copyrights associated with a software package. -`OSI <https://opensource.org>`__ is a corporation dedicated to the Open +`OSI <http://opensource.org>`__ is a corporation dedicated to the Open Source Definition and the effort for reviewing and approving licenses that conform to the Open Source Definition (OSD). diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index 0ec7e2b961..66a88c9521 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -221,7 +221,8 @@ your Metadata, the easier it is to cope with future changes. - Familiarize yourself with the `Yocto Project curated layer index <https://www.yoctoproject.org/software-overview/layers/>`__ - or the :oe_layerindex:`OpenEmbedded layer index <>`. + or the `OpenEmbedded layer + index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__. The latter contains more layers but they are less universally validated. @@ -363,12 +364,13 @@ activities using the Yocto Project: versions available for Yocto Project. The main purpose of the system is to help you manage the recipes you maintain and to offer a dynamic overview of the project. The Recipe Reporting System is built on top - of the :oe_layerindex:`OpenEmbedded Layer Index <>`, which + of the `OpenEmbedded Layer + Index <http://layers.openembedded.org/layerindex/layers/>`__, which is a website that indexes OpenEmbedded-Core layers. - *Patchwork:* `Patchwork <http://jk.ozlabs.org/projects/patchwork/>`__ is a fork of a project originally started by - `OzLabs <https://ozlabs.org/>`__. The project is a web-based tracking + `OzLabs <http://ozlabs.org/>`__. The project is a web-based tracking system designed to streamline the process of bringing contributions into a project. The Yocto Project uses Patchwork as an organizational tool to handle patches, which number in the thousands for every @@ -400,7 +402,7 @@ activities using the Yocto Project: Historically, cross-prelink is a variant of prelink, which was conceived by `Jakub - Jelínek <https://people.redhat.com/jakub/prelink.pdf>`__ a number of + Jelínek <http://people.redhat.com/jakub/prelink.pdf>`__ a number of years ago. Both prelink and cross-prelink are maintained in the same repository albeit on separate branches. By providing an emulated runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation), @@ -529,7 +531,8 @@ targets: Debian Package (dpkg) in operation. Opkg is intended for use on embedded Linux devices and is used in - this capacity in the :oe_home:`OpenEmbedded <>` and + this capacity in the + `OpenEmbedded <http://www.openembedded.org/wiki/Main_Page>`__ and `OpenWrt <https://openwrt.org/>`__ projects, as well as the Yocto Project. diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst index b401cf9040..418f4e9937 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -39,7 +39,7 @@ other tools when it seems useful to do so. The coverage below details some of the most common ways you'll likely want to apply the tool; full documentation can be found either within the tool itself or in the man pages at -`perf(1) <https://linux.die.net/man/1/perf>`__. +`perf(1) <http://linux.die.net/man/1/perf>`__. Perf Setup ---------- @@ -860,7 +860,7 @@ the right kind of trace data, higher-level profiling-type summaries can be derived from it. Documentation on using the `'perf script' python -binding <https://linux.die.net/man/1/perf-script-python>`__. +binding <http://linux.die.net/man/1/perf-script-python>`__. System-Wide Tracing and Profiling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1136,31 +1136,32 @@ Perf Documentation Online versions of the man pages for the commands discussed in this section can be found here: -- The `'perf stat' manpage <https://linux.die.net/man/1/perf-stat>`__. +- The `'perf stat' manpage <http://linux.die.net/man/1/perf-stat>`__. - The `'perf record' - manpage <https://linux.die.net/man/1/perf-record>`__. + manpage <http://linux.die.net/man/1/perf-record>`__. - The `'perf report' - manpage <https://linux.die.net/man/1/perf-report>`__. + manpage <http://linux.die.net/man/1/perf-report>`__. -- The `'perf probe' manpage <https://linux.die.net/man/1/perf-probe>`__. +- The `'perf probe' manpage <http://linux.die.net/man/1/perf-probe>`__. - The `'perf script' - manpage <https://linux.die.net/man/1/perf-script>`__. + manpage <http://linux.die.net/man/1/perf-script>`__. - Documentation on using the `'perf script' python - binding <https://linux.die.net/man/1/perf-script-python>`__. + binding <http://linux.die.net/man/1/perf-script-python>`__. -- The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__. +- The top-level `perf(1) manpage <http://linux.die.net/man/1/perf>`__. Normally, you should be able to invoke the man pages via perf itself e.g. 'perf help' or 'perf help record'. However, by default Yocto doesn't install man pages, but perf invokes the man pages for most help functionality. This is a bug and is being -addressed by a Yocto bug: :yocto_bugs:`Bug 3388 - perf: enable man pages for -basic 'help' functionality </show_bug.cgi?id=3388>`. +addressed by a Yocto bug: `Bug 3388 - perf: enable man pages for basic +'help' +functionality <https://bugzilla.yoctoproject.org/show_bug.cgi?id=3388>`__. The man pages in text form, along with some other files, such as a set of examples, can be found in the 'perf' directory of the kernel tree: :: @@ -1718,7 +1719,7 @@ events': The tool is pretty self-explanatory, but for more detailed information on navigating through the data, see the `kernelshark -website <https://rostedt.homelinux.com/kernelshark/>`__. +website <http://rostedt.homelinux.com/kernelshark/>`__. ftrace Documentation -------------------- @@ -1736,19 +1737,19 @@ Documentation directory: :: There is a nice series of articles on using ftrace and trace-cmd at LWN: - `Debugging the kernel using Ftrace - part - 1 <https://lwn.net/Articles/365835/>`__ + 1 <http://lwn.net/Articles/365835/>`__ - `Debugging the kernel using Ftrace - part - 2 <https://lwn.net/Articles/366796/>`__ + 2 <http://lwn.net/Articles/366796/>`__ - `Secrets of the Ftrace function - tracer <https://lwn.net/Articles/370423/>`__ + tracer <http://lwn.net/Articles/370423/>`__ - `trace-cmd: A front-end for Ftrace <https://lwn.net/Articles/410200/>`__ There's more detailed documentation kernelshark usage here: -`KernelShark <https://rostedt.homelinux.com/kernelshark/>`__ +`KernelShark <http://rostedt.homelinux.com/kernelshark/>`__ An amusing yet useful README (a tracing mini-HOWTO) can be found in ``/sys/kernel/debug/tracing/README``. @@ -1763,7 +1764,7 @@ gather/print/aggregate data extracted from the context they end up being invoked under. For example, this probe from the `SystemTap -tutorial <https://sourceware.org/systemtap/tutorial/>`__ simply prints a +tutorial <http://sourceware.org/systemtap/tutorial/>`__ simply prints a line every time any process on the system open()s a file. For each line, it prints the executable name of the program that opened the file, along with its PID, and the name of the file it opened (or tried to open), @@ -1936,11 +1937,11 @@ systemtap Documentation ----------------------- The SystemTap language reference can be found here: `SystemTap Language -Reference <https://sourceware.org/systemtap/langref/>`__ +Reference <http://sourceware.org/systemtap/langref/>`__ Links to other SystemTap documents, tutorials, and examples can be found here: `SystemTap documentation -page <https://sourceware.org/systemtap/documentation.html>`__ +page <http://sourceware.org/systemtap/documentation.html>`__ Sysprof ======= @@ -2214,7 +2215,7 @@ developers who are working in a Linux environment and are interested in efficient software tracing. For information on LTTng in general, visit the `LTTng -Project <https://lttng.org/lttng2.0>`__ site. You can find a "Getting +Project <http://lttng.org/lttng2.0>`__ site. You can find a "Getting Started" link on this site that takes you to an LTTng Quick Start. blktrace @@ -2365,7 +2366,7 @@ first part of the filenames: :: The report shows each event that was found in the blktrace data, along with a summary of the overall block I/O traffic during the run. You can look at the -`blkparse <https://linux.die.net/man/1/blkparse>`__ manpage to learn the +`blkparse <http://linux.die.net/man/1/blkparse>`__ manpage to learn the meaning of each field displayed in the trace listing. Live Mode @@ -2564,11 +2565,11 @@ blktrace Documentation Online versions of the man pages for the commands discussed in this section can be found here: -- https://linux.die.net/man/8/blktrace +- http://linux.die.net/man/8/blktrace -- https://linux.die.net/man/1/blkparse +- http://linux.die.net/man/1/blkparse -- https://linux.die.net/man/8/btrace +- http://linux.die.net/man/8/btrace The above manpages, along with manpages for the other blktrace utilities (btt, blkiomon, etc) can be found in the /doc directory of the blktrace diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index a152dcac77..5a30ce379b 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -278,7 +278,7 @@ The ``ccache`` class enables the C/C++ Compiler Cache for the build. This class is used to give a minor performance boost during the build. However, using the class can lead to unexpected side-effects. Thus, it is recommended that you do not use this class. See -https://ccache.samba.org/ for information on the C/C++ Compiler +http://ccache.samba.org/ for information on the C/C++ Compiler Cache. .. _ref-classes-chrpath: @@ -1374,36 +1374,36 @@ generation. ``kernel-fitimage.bbclass`` =========================== -The ``kernel-fitimage`` class provides support to pack a kernel image, +The ``kernel-fitimage`` class provides support to pack a kernel Image, device trees and a RAM disk into a single FIT image. In theory, a FIT -image can support any number of kernels, RAM disks and device trees. +image can support any number of kernels, RAM disks and device-trees. However, ``kernel-fitimage`` currently only supports limited usescases: just one kernel image, an optional RAM disk, and -any number of device trees. +any number of device tree. To create a FIT image, it is required that :term:`KERNEL_CLASSES` -is set to include "kernel-fitimage" and :term:`KERNEL_IMAGETYPE` +is set to "kernel-fitimage" and :term:`KERNEL_IMAGETYPE` is set to "fitImage". -The options for the device tree compiler passed to ``mkimage -D`` +The options for the device tree compiler passed to mkimage -D feature when creating the FIT image are specified using the :term:`UBOOT_MKIMAGE_DTCOPTS` variable. Only a single kernel can be added to the FIT image created by ``kernel-fitimage`` and the kernel image in FIT is mandatory. The -address where the kernel image is to be loaded by U-Boot is +address where the kernel image is to be loaded by U-boot is specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by :term:`UBOOT_ENTRYPOINT`. Multiple device trees can be added to the FIT image created by ``kernel-fitimage`` and the device tree is optional. -The address where the device tree is to be loaded by U-Boot is +The address where the device tree is to be loaded by U-boot is specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries. Only a single RAM disk can be added to the FIT image created by ``kernel-fitimage`` and the RAM disk in FIT is optional. -The address where the RAM disk image is to be loaded by U-Boot +The address where the RAM disk image is to be loaded by U-boot is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by :term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to FIT image when :term:`INITRAMFS_IMAGE` is specified. @@ -2581,7 +2581,7 @@ the :term:`SYSTEMD_BOOT_CFG`, :term:`SYSTEMD_BOOT_TIMEOUT` variables. You can also see the `Systemd-boot -documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__ +documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__ for more information. .. _ref-classes-terminal: diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst index 34b26ee3ef..f67c53824b 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -55,9 +55,9 @@ Yocto Project is fairly straightforward. **Q:** Are there any products built using the OpenEmbedded build system? **A:** The software running on the `Vernier -LabQuest <https://vernier.com/labquest/>`__ is built using the +LabQuest <http://vernier.com/labquest/>`__ is built using the OpenEmbedded build system. See the `Vernier -LabQuest <https://www.vernier.com/products/interfaces/labq/>`__ website +LabQuest <http://www.vernier.com/products/interfaces/labq/>`__ website for more information. There are a number of pre-production devices using the OpenEmbedded build system and the Yocto Project team announces them as soon as they are released. @@ -273,7 +273,7 @@ OpenEmbedded build system to use its internally built toolchain (i.e. particular, "external-\*" refers to external toolchains. One example is the Sourcery G++ Toolchain. The support for this toolchain resides in the separate ``meta-sourcery`` layer at -https://github.com/MentorEmbedded/meta-sourcery/. +http://github.com/MentorEmbedded/meta-sourcery/. In addition to the toolchain configuration, you also need a corresponding toolchain recipe file. This recipe file needs to package diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst index cf5cc1109f..5e9374eae7 100644 --- a/poky/documentation/ref-manual/images.rst +++ b/poky/documentation/ref-manual/images.rst @@ -37,9 +37,9 @@ Following is a list of supported recipes: all the pieces required to run builds using the build system as well as the build system itself. You can boot and run the image using either the `VMware - Player <https://www.vmware.com/products/player/overview.html>`__ or + Player <http://www.vmware.com/products/player/overview.html>`__ or `VMware - Workstation <https://www.vmware.com/products/workstation/overview.html>`__. + Workstation <http://www.vmware.com/products/workstation/overview.html>`__. For more information on this image, see the :yocto_home:`Build Appliance </software-item/build-appliance>` page on the Yocto Project website. diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst index 472820f165..bb9c0460f3 100644 --- a/poky/documentation/ref-manual/kickstart.rst +++ b/poky/documentation/ref-manual/kickstart.rst @@ -24,7 +24,7 @@ The information lists the commands, their syntax, and meanings. Kickstart commands are based on the Fedora kickstart versions but with modifications to reflect Wic capabilities. You can see the original documentation for those commands at the following link: -https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html +http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html Command: part or partition ========================== @@ -164,7 +164,7 @@ the ``part`` and ``partition`` commands: - ``--part-type``: This option is a Wic-specific option that specifies the partition type globally unique identifier (GUID) for GPT partitions. You can find the list of partition type GUIDs at - https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs. + http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs. - ``--use-uuid``: This option is a Wic-specific option that causes Wic to generate a random GUID for the partition. The generated diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst index 54544e4798..19275b3cd6 100644 --- a/poky/documentation/ref-manual/migration-1.7.rst +++ b/poky/documentation/ref-manual/migration-1.7.rst @@ -190,7 +190,7 @@ Removed Recipes The following recipes have been removed: -- ``x-load``: This recipe has been superseded by U-Boot SPL for all +- ``x-load``: This recipe has been superseded by U-boot SPL for all Cortex-based TI SoCs. For legacy boards, the ``meta-ti`` layer, which contains a maintained recipe, should be used instead. diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst index 861d04861b..e8b3ada264 100644 --- a/poky/documentation/ref-manual/migration-2.1.rst +++ b/poky/documentation/ref-manual/migration-2.1.rst @@ -89,7 +89,7 @@ package-specific nesting should be done by the package itself. Finally, having ``libexecdir`` change between recipes makes it very difficult for different recipes to invoke binaries that have been installed into ``libexecdir``. The Filesystem Hierarchy Standard (i.e. -https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now +http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now recognizes the use of ``${prefix}/libexec/``, giving distributions the choice between ``${prefix}/lib`` or ``${prefix}/libexec`` without breaking FHS. diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst index 5c6fecf328..ac247dce46 100644 --- a/poky/documentation/ref-manual/migration-2.2.rst +++ b/poky/documentation/ref-manual/migration-2.2.rst @@ -28,8 +28,8 @@ The way directories are staged in sysroot has been simplified and introduces the new :term:`SYSROOT_DIRS`, :term:`SYSROOT_DIRS_NATIVE`, and :term:`SYSROOT_DIRS_BLACKLIST`. See the -:oe_lists:`v2 patch series on the OE-Core Mailing List -</pipermail/openembedded-core/2016-May/121365.html>` +`v2 patch series on the OE-Core Mailing +List <http://lists.openembedded.org/pipermail/openembedded-core/2016-May/121365.html>`__ for additional information. .. _migration-2.2-removal-of-old-images-from-tmp-deploy-now-enabled: diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst index 04b11daa7d..3e9758119b 100644 --- a/poky/documentation/ref-manual/migration-2.3.rst +++ b/poky/documentation/ref-manual/migration-2.3.rst @@ -238,7 +238,7 @@ to substitute a GPLv2 version of a GPLv3 recipe, then you must add the .. note:: You can ``find meta-gplv2`` layer in the OpenEmbedded layer index at - :oe_layer:`/meta-gplv2`. + https://layers.openembedded.org/layerindex/branch/master/layer/meta-gplv2/. These relocated GPLv2 recipes do not receive the same level of maintenance as other core recipes. The recipes do not get security fixes @@ -274,7 +274,7 @@ The following package management changes took place: fixed. For more information, see the `DNF - Documentation <https://dnf.readthedocs.io/en/latest/>`__. + Documentation <http://dnf.readthedocs.io/en/latest/>`__. - Rpm 5.x is replaced with Rpm 4.x. This is done for two major reasons: diff --git a/poky/documentation/ref-manual/migration-2.7.rst b/poky/documentation/ref-manual/migration-2.7.rst index 5af5947fff..7e628fc3ec 100644 --- a/poky/documentation/ref-manual/migration-2.7.rst +++ b/poky/documentation/ref-manual/migration-2.7.rst @@ -159,7 +159,7 @@ The following miscellaneous changes occurred: from the top-level ``scripts`` directory. - Perl now builds for the target using - `perl-cross <https://arsv.github.io/perl-cross/>`_ for better + `perl-cross <http://arsv.github.io/perl-cross/>`_ for better maintainability and improved build performance. This change should not present any problems unless you have heavily customized your Perl recipe. diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst index 6cb767d934..54977dcb21 100644 --- a/poky/documentation/ref-manual/qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst @@ -227,7 +227,7 @@ Errors and Warnings CFLAGS_append = " -fPIC " For more information on text relocations at runtime, see - https://www.akkadia.org/drepper/textrelocs.html. + http://www.akkadia.org/drepper/textrelocs.html. .. _qa-check-ldflags: diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst index 7554164d11..77c3678095 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -52,7 +52,7 @@ against the Yocto Project, see the following: - The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>` -For information on Bugzilla in general, see https://www.bugzilla.org/about/. +For information on Bugzilla in general, see http://www.bugzilla.org/about/. .. _resources-mailinglist: @@ -118,7 +118,8 @@ Here is a list of resources you might find helpful: distribution from which the Yocto Project derives its build system (Poky) and to which it contributes. -- :oe_wiki:`BitBake </BitBake>`\ *:* The tool used to process metadata. +- :oe_home:`BitBake </wiki/BitBake>`\ *:* The tool + used to process metadata. - :doc:`BitBake User Manual <bitbake:index>`\ *:* A comprehensive guide to the BitBake tool. If you want information on BitBake, see @@ -193,5 +194,5 @@ Here is a list of resources you might find helpful: available for Yocto Project and Poky discussions: ``#yocto`` and ``#poky``, respectively. -- `Quick EMUlator (QEMU) <https://wiki.qemu.org/Index.html>`__\ *:* An +- `Quick EMUlator (QEMU) <http://wiki.qemu.org/Index.html>`__\ *:* An open-source machine emulator and virtualizer. diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst index 966962005b..c07dd4b128 100644 --- a/poky/documentation/ref-manual/terms.rst +++ b/poky/documentation/ref-manual/terms.rst @@ -349,8 +349,7 @@ universal, the list includes them just in case: Source Directory is derived from the Yocto Project release tarball. For example, downloading and unpacking :yocto_dl:`/releases/yocto/&DISTRO_REL_TAG;/&YOCTO_POKY;.tar.bz2` - results in a Source Directory whose root folder is named - ``&YOCTO_POKY;``. + results in a Source Directory whose root folder is named ``poky``. It is important to understand the differences between the Source Directory created by unpacking a released tarball as compared to diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index 4ce2648136..8c6cc46b6c 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -2538,13 +2538,6 @@ system and gives an overview of their function and contents. For guidance on how to create your own file permissions settings table file, examine the existing ``fs-perms.txt``. - :term:`FIT_DESC` - Specifies the description string encoded into a fitImage. The default - value is set by the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` - class as follows:: - - FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}" - :term:`FIT_GENERATE_KEYS` Decides whether to generate the keys for signing fitImage if they don't already exist. The keys are created in ``UBOOT_SIGN_KEYDIR``. @@ -2575,13 +2568,6 @@ system and gives an overview of their function and contents. Size of private key in number of bits used in fitImage. The default value is "2048". - :term:`FIT_SIGN_INDIVIDUAL` - If set to "1", then the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` - class will sign the kernel, dtb and ramdisk images individually in addition - to signing the fitImage itself. This could be useful if you are - intending to verify signatures in another context than booting via - U-Boot. - :term:`FONT_EXTRA_RDEPENDS` When inheriting the :ref:`fontcache <ref-classes-fontcache>` class, this variable specifies the runtime dependencies for font packages. @@ -2662,7 +2648,7 @@ system and gives an overview of their function and contents. GROUPADD_PARAM_${PN} = "-r netdev" For information on the standard Linux shell command - ``groupadd``, see https://linux.die.net/man/8/groupadd. + ``groupadd``, see http://linux.die.net/man/8/groupadd. :term:`GROUPMEMS_PARAM` When inheriting the :ref:`useradd <ref-classes-useradd>` class, @@ -2671,7 +2657,7 @@ system and gives an overview of their function and contents. of a group when the package is installed. For information on the standard Linux shell command ``groupmems``, - see https://linux.die.net/man/8/groupmems. + see http://linux.die.net/man/8/groupmems. :term:`GRUB_GFXSERIAL` Configures the GNU GRand Unified Bootloader (GRUB) to have graphics @@ -3884,15 +3870,6 @@ system and gives an overview of their function and contents. KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - :term:`KERNEL_DTC_FLAGS` - Specifies the ``dtc`` flags that are passed to the Linux kernel build - system when generating the device trees (via ``DTC_FLAGS`` environment - variable). - - In order to use this variable, the - :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class must - be inherited. - :term:`KERNEL_EXTRA_ARGS` Specifies additional ``make`` command-line arguments the OpenEmbedded build system passes on when compiling the kernel. @@ -4006,9 +3983,8 @@ system and gives an overview of their function and contents. when building the kernel and is passed to ``make`` as the target to build. - If you want to build an alternate kernel image type in addition to that - specified by ``KERNEL_IMAGETYPE``, use the :term:`KERNEL_ALT_IMAGETYPE` - variable. + If you want to build an alternate kernel image type, use the + :term:`KERNEL_ALT_IMAGETYPE` variable. :term:`KERNEL_MODULE_AUTOLOAD` Lists kernel modules that need to be auto-loaded during boot. @@ -4703,7 +4679,7 @@ system and gives an overview of their function and contents. See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information. module_conf - Specifies `modprobe.d <https://linux.die.net/man/5/modprobe.d>`_ + Specifies `modprobe.d <http://linux.die.net/man/5/modprobe.d>`_ syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf`` file. @@ -7628,7 +7604,7 @@ system and gives an overview of their function and contents. SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf" For information on Systemd-boot, see the `Systemd-boot - documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. + documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. :term:`SYSTEMD_BOOT_ENTRIES` When :term:`EFI_PROVIDER` is set to @@ -7642,7 +7618,7 @@ system and gives an overview of their function and contents. SYSTEMD_BOOT_ENTRIES ?= "" For information on Systemd-boot, see the `Systemd-boot - documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. + documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. :term:`SYSTEMD_BOOT_TIMEOUT` When :term:`EFI_PROVIDER` is set to @@ -7655,7 +7631,7 @@ system and gives an overview of their function and contents. SYSTEMD_BOOT_TIMEOUT ?= "10" For information on Systemd-boot, see the `Systemd-boot - documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. + documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. :term:`SYSTEMD_PACKAGES` When inheriting the :ref:`systemd <ref-classes-systemd>` class, @@ -7686,7 +7662,7 @@ system and gives an overview of their function and contents. When using :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`, specifies a space-separated list of the virtual terminals that should - run a `getty <https://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ + run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ (allowing login), assuming :term:`USE_VT` is not set to "0". @@ -7910,7 +7886,7 @@ system and gives an overview of their function and contents. toolchain. One example is the Sourcery G++ Toolchain. The support for this toolchain resides in the separate Mentor Graphics ``meta-sourcery`` layer at - https://github.com/MentorEmbedded/meta-sourcery/. + http://github.com/MentorEmbedded/meta-sourcery/. The layer's ``README`` file contains information on how to use the Sourcery G++ Toolchain as an external toolchain. In summary, you must @@ -8413,21 +8389,21 @@ system and gives an overview of their function and contents. In this example, "sd" is selected as the configuration of the possible four for the ``UBOOT_MACHINE``. The "sd" configuration defines "mx6qsabreauto_config" as the value for ``UBOOT_MACHINE``, while the - "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-Boot image. + "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-boot image. For more information on how the ``UBOOT_CONFIG`` is handled, see the :ref:`uboot-config <ref-classes-uboot-config>` class. :term:`UBOOT_DTB_LOADADDRESS` - Specifies the load address for the dtb image used by U-Boot. During FIT + Specifies the load address for the dtb image used by U-boot. During FIT image creation, the ``UBOOT_DTB_LOADADDRESS`` variable is used in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in creating the dtb sections of Image Tree Source for the FIT image. :term:`UBOOT_DTBO_LOADADDRESS` - Specifies the load address for the dtbo image used by U-Boot. During FIT + Specifies the load address for the dtbo image used by U-boot. During FIT image creation, the ``UBOOT_DTBO_LOADADDRESS`` variable is used in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in creating the dtbo sections of Image Tree Source for the FIT image. @@ -8464,29 +8440,9 @@ system and gives an overview of their function and contents. Specifies the target called in the ``Makefile``. The default target is "all". - :term:`UBOOT_MKIMAGE` - Specifies the name of the mkimage command as used by the - :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to assemble - the FIT image. This can be used to substitute an alternative command, wrapper - script or function if desired. The default is "uboot-mkimage". - :term:`UBOOT_MKIMAGE_DTCOPTS` Options for the device tree compiler passed to mkimage '-D' feature while creating FIT image in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class. - If ``UBOOT_MKIMAGE_DTCOPTS`` is not set then kernel-fitimage will not - pass the ``-D`` option to mkimage. - - :term:`UBOOT_MKIMAGE_SIGN` - Specifies the name of the mkimage command as used by the - :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to sign - the FIT image after it has been assembled (if enabled). This can be used - to substitute an alternative command, wrapper script or function if - desired. The default is "${:term:`UBOOT_MKIMAGE`}". - - :term:`UBOOT_MKIMAGE_SIGN_ARGS` - Optionally specifies additional arguments for the - :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to pass to the - mkimage command when signing the FIT image. :term:`UBOOT_RD_ENTRYPOINT` Specifies the entrypoint for the RAM disk image. @@ -8512,7 +8468,7 @@ system and gives an overview of their function and contents. certificate used for signing FIT image. :term:`UBOOT_SIGN_KEYNAME` - The name of keys used for signing U-Boot FIT image stored in + The name of keys used for signing U-boot FIT image stored in :term:`UBOOT_SIGN_KEYDIR` directory. For e.g. dev.key key and dev.crt certificate stored in :term:`UBOOT_SIGN_KEYDIR` directory will have :term:`UBOOT_SIGN_KEYNAME` set to "dev". @@ -8606,7 +8562,7 @@ system and gives an overview of their function and contents. When using :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`, determines whether or not to run a - `getty <https://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any + `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any virtual terminals in order to enable logging in through those terminals. @@ -8717,7 +8673,7 @@ system and gives an overview of their function and contents. For information on the standard Linux shell command ``useradd``, see - https://linux.die.net/man/8/useradd. + http://linux.die.net/man/8/useradd. :term:`USERADD_UID_TABLES` Specifies a password file to use for obtaining static user diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst index b409072021..2546300556 100644 --- a/poky/documentation/releases.rst +++ b/poky/documentation/releases.rst @@ -9,7 +9,6 @@ ******************************* - :yocto_docs:`3.2 Documentation </3.2>` -- :yocto_docs:`3.2.1 Documentation </3.2.1>` **************************** 3.1 'dunfell' Release Series diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst index e4b9b05ba6..66b12cdff9 100644 --- a/poky/documentation/sdk-manual/intro.rst +++ b/poky/documentation/sdk-manual/intro.rst @@ -210,7 +210,7 @@ You just need to follow these general steps: 3. *Develop and Test your Application:* At this point, you have the tools to develop your application. If you need to separately install and use the QEMU emulator, you can go to `QEMU Home - Page <https://wiki.qemu.org/Main_Page>`__ to download and learn about + Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about the emulator. See the ":doc:`/dev-manual/qemu`" chapter in the Yocto Project Development Tasks Manual for information on using QEMU within the Yocto Project. diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js index 754de2e6af..fc901d3298 100644 --- a/poky/documentation/sphinx-static/switchers.js +++ b/poky/documentation/sphinx-static/switchers.js @@ -3,7 +3,7 @@ var all_versions = { 'dev': 'dev (3.3)', - '3.2.1': '3.2.1', + '3.2': '3.2', '3.1.4': '3.1.4', '3.0.4': '3.0.4', '2.7.4': '2.7.4', diff --git a/poky/documentation/toaster-manual/intro.rst b/poky/documentation/toaster-manual/intro.rst index 57e5b2bb7b..c78b3f53da 100644 --- a/poky/documentation/toaster-manual/intro.rst +++ b/poky/documentation/toaster-manual/intro.rst @@ -27,7 +27,7 @@ extensive information about the build process. - Browse layers listed in the various :ref:`layer sources <toaster-manual/reference:layer source>` that are available in your project (e.g. the OpenEmbedded Layer Index at - :oe_layerindex:`/`). + http://layers.openembedded.org/layerindex/). - Browse images, recipes, and machines provided by those layers. diff --git a/poky/documentation/toaster-manual/reference.rst b/poky/documentation/toaster-manual/reference.rst index d2ab14c8e6..dfe51889e8 100644 --- a/poky/documentation/toaster-manual/reference.rst +++ b/poky/documentation/toaster-manual/reference.rst @@ -24,12 +24,12 @@ type of layer source called a "layer index." A layer index is a web application that contains information about a set of custom layers. A good example of an existing layer index is the OpenEmbedded Layer Index. A public instance of this layer index exists -at :oe_layerindex:`/`. You can find the code for this +at http://layers.openembedded.org. You can find the code for this layer index's web application at :yocto_git:`/layerindex-web/`. When you tie a layer source into Toaster, it can query the layer source through a -`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__ +`REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__ API, store the information about the layers in the Toaster database, and then show the information to users. Users are then able to view that information and build layers from Toaster itself without worrying about @@ -81,7 +81,7 @@ describes two methods by which you can configure and use your layer index. In the previous section, the code for the OpenEmbedded Metadata Index -(i.e. :oe_layerindex:`/`) was referenced. You can use +(i.e. http://layers.openembedded.org) was referenced. You can use this code, which is at :yocto_git:`/layerindex-web/`, as a base to create your own layer index. @@ -370,7 +370,7 @@ Remote Toaster Monitoring Toaster has an API that allows remote management applications to directly query the state of the Toaster server and its builds in a machine-to-machine manner. This API uses the -`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__ +`REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__ interface and the transfer of JSON files. For example, you might monitor a build inside a container through well supported known HTTP ports in order to easily access a Toaster server inside the container. In this diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst index ded771e796..2cb7884eb9 100644 --- a/poky/documentation/toaster-manual/setup-and-use.rst +++ b/poky/documentation/toaster-manual/setup-and-use.rst @@ -462,8 +462,9 @@ Using the Toaster Web Interface The Toaster web interface allows you to do the following: -- Browse published layers in the :oe_layerindex:`OpenEmbedded Layer Index <>` - that are available for your selected version of the build system. +- Browse published layers in the `OpenEmbedded Layer + Index <http://layers.openembedded.org>`__ that are available for your + selected version of the build system. - Import your own layers for building. @@ -572,11 +573,11 @@ However, the "Local Yocto Project" release will not provide you with any compatible layers, other than the three core layers that come with the Yocto Project: -- :oe_layer:`openembedded-core </openembedded-core>` +- `openembedded-core <http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/>`__ -- :oe_layer:`meta-poky </meta-poky>` +- `meta-poky <http://layers.openembedded.org/layerindex/branch/master/layer/meta-poky/>`__ -- :oe_layer:`meta-yocto-bsp </meta-yocto-bsp>` +- `meta-yocto-bsp <http://layers.openembedded.org/layerindex/branch/master/layer/meta-yocto-bsp/>`__ .. image:: figures/compatible-layers.png :align: center diff --git a/poky/documentation/transitioning-to-a-custom-environment.rst b/poky/documentation/transitioning-to-a-custom-environment.rst index abbd74ca1d..415f295b33 100644 --- a/poky/documentation/transitioning-to-a-custom-environment.rst +++ b/poky/documentation/transitioning-to-a-custom-environment.rst @@ -29,8 +29,8 @@ Transitioning to a custom environment for systems development #. **Find and acquire the best BSP for your target**. Use the :yocto_home:`Yocto Project curated layer index - </software-overview/layers/>` or even the :oe_layerindex:`OpenEmbedded - layer index <>` to find and acquire the best BSP for your + </software-overview/layers/>` or even the `OpenEmbedded layer index + <https://layers.openembedded.org>`_ to find and acquire the best BSP for your target board. The Yocto Project layer index BSPs are regularly validated. The best place to get your first BSP is from your silicon manufacturer or board vendor – they can point you to their most qualified efforts. In general, for diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst index 143f9fbfed..a051036bb6 100644 --- a/poky/documentation/what-i-wish-id-known.rst +++ b/poky/documentation/what-i-wish-id-known.rst @@ -27,10 +27,11 @@ contact us with other suggestions. to be responsible for your own updates. #. **Get to know the layer index:** - All layers can be found in the :oe_layerindex:`layer index <>`. Layers which - have applied for Yocto Project Compatible status (structure continuity - assurance and testing) can be found in the :yocto_home:`Yocto Project Compatible index - </software-over/layer/>`. Generally check the Compatible layer index first, + All layers can be found in the `layer index + <https://layers.openembedded.org/>`_. Layers which have applied for Yocto + Project Compatible status (structure continuity assurance and testing) can be + found in the :yocto_home:`Yocto Project Compatible index + </software-over/layer/>`. Generally check the Compatible layer index first, and if you don't find the necessary layer check the general layer index. The layer index is an original artifact from the Open Embedded Project. As such, that index doesn't have the curating and testing that the Yocto Project @@ -171,7 +172,7 @@ contact us with other suggestions. * add an ssh server to an image (enable transferring of files to target) * know the anatomy of a recipe * know how to create and use layers - * find recipes (with the :oe_layerindex:`OpenEmbedded Layer index <>`) + * find recipes (with the `OpenEmbedded Layer index <https://layers.openembedded.org>`_) * understand difference between machine and distro settings * find and use the right BSP (machine) for your hardware * find examples of distro features and know where to set them |