From c387f0c2543a9dd7f8eca069629ede4bb5ec5dba Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Thu, 17 Sep 2020 01:58:59 +0200 Subject: sphinx: replace special quotes with single and double quotes (From yocto-docs rev: 0aeb7a94abcef3cb3850c753dd0a243f381e6675) Signed-off-by: Quentin Schulz Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- documentation/test-manual/test-manual-intro.rst | 6 +++--- documentation/test-manual/test-manual-intro.xml | 6 +++--- .../test-manual-understand-autobuilder.rst | 20 ++++++++++---------- .../test-manual-understand-autobuilder.xml | 16 ++++++++-------- 4 files changed, 24 insertions(+), 24 deletions(-) (limited to 'documentation/test-manual') diff --git a/documentation/test-manual/test-manual-intro.rst b/documentation/test-manual/test-manual-intro.rst index b0bc24c9b0..53ad650b35 100644 --- a/documentation/test-manual/test-manual-intro.rst +++ b/documentation/test-manual/test-manual-intro.rst @@ -12,9 +12,9 @@ Welcome Welcome to the Yocto Project Test Environment Manual! This manual is a work in progress. The manual contains information about the testing environment used by the Yocto Project to make sure each major and minor -release works as intended. All the project’s testing infrastructure and +release works as intended. All the project's testing infrastructure and processes are publicly visible and available so that the community can -see what testing is being performed, how it’s being done and the current +see what testing is being performed, how it's being done and the current status of the tests and the project at any given time. It is intended that Other organizations can leverage off the process and testing environment used by the Yocto Project to create their own automated, @@ -514,7 +514,7 @@ resource utilisation as that happens. An example from 'bitbake -p (cached)') This example shows how three specific parsing timings are -measured, with and without various caches, to show how BitBake’s parsing +measured, with and without various caches, to show how BitBake's parsing performance trends over time. .. _test-writing-considerations: diff --git a/documentation/test-manual/test-manual-intro.xml b/documentation/test-manual/test-manual-intro.xml index 8e2c7cd874..0cdbee4d8e 100644 --- a/documentation/test-manual/test-manual-intro.xml +++ b/documentation/test-manual/test-manual-intro.xml @@ -12,8 +12,8 @@ Welcome to the Yocto Project Test Environment Manual! This manual is a work in progress. The manual contains information about the testing environment used by the Yocto Project to make sure each major and minor release works as intended. All the - project’s testing infrastructure and processes are publicly visible and available so - that the community can see what testing is being performed, how it’s being done and the + project's testing infrastructure and processes are publicly visible and available so + that the community can see what testing is being performed, how it's being done and the current status of the tests and the project at any given time. It is intended that Other organizations can leverage off the process and testing environment used by the Yocto Project to create their own automated, production test environment, building upon the @@ -579,7 +579,7 @@ 'bitbake -p (cached)') This example shows how three specific parsing timings are measured, with and without - various caches, to show how BitBake’s parsing performance trends over time. + various caches, to show how BitBake's parsing performance trends over time.
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.rst b/documentation/test-manual/test-manual-understand-autobuilder.rst index 0809190b5b..2fcae5000e 100644 --- a/documentation/test-manual/test-manual-understand-autobuilder.rst +++ b/documentation/test-manual/test-manual-understand-autobuilder.rst @@ -7,19 +7,19 @@ Understanding the Yocto Project Autobuilder Execution Flow within the Autobuilder ===================================== -The “a-full” and “a-quick” targets are the usual entry points into the +The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and it makes sense to follow the process through the system starting there. This is best visualised from the Autobuilder Console view (:yocto_ab:`/typhoon/#/console`). -Each item along the top of that view represents some “target build” and -these targets are all run in parallel. The ‘full’ build will trigger the -majority of them, the “quick” build will trigger some subset of them. +Each item along the top of that view represents some "target build" and +these targets are all run in parallel. The 'full' build will trigger the +majority of them, the "quick" build will trigger some subset of them. The Autobuilder effectively runs whichever configuration is defined for each of those targets on a seperate buildbot worker. To understand the configuration, you need to look at the entry on ``config.json`` file within the ``yocto-autobuilder-helper`` repository. The targets are -defined in the ‘overrides’ section, a quick example could be qemux86-64 +defined in the ‘overrides' section, a quick example could be qemux86-64 which looks like:: "qemux86-64" : { @@ -32,8 +32,8 @@ which looks like:: } }, -And to expand that, you need the “arch-qemu” entry from -the “templates” section, which looks like:: +And to expand that, you need the "arch-qemu" entry from +the "templates" section, which looks like:: "arch-qemu" : { "BUILDINFO" : true, @@ -54,9 +54,9 @@ the “templates” section, which looks like:: } }, -Combining these two entries you can see that “qemux86-64” is a three step build where the +Combining these two entries you can see that "qemux86-64" is a three step build where the ``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for -``MACHINE=”qemx86-64”`` but with differing SDKMACHINE settings. In step +``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step 1 an extra variable is added to the ``auto.conf`` file to enable wic image generation. @@ -262,7 +262,7 @@ of post-build steps, including: #. Cleanup the build directory using :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful, - else rename it to “build-renamed” for potential future debugging. + else rename it to "build-renamed" for potential future debugging. .. _test-deploying-yp-autobuilder: diff --git a/documentation/test-manual/test-manual-understand-autobuilder.xml b/documentation/test-manual/test-manual-understand-autobuilder.xml index a04006605f..8600367be7 100644 --- a/documentation/test-manual/test-manual-understand-autobuilder.xml +++ b/documentation/test-manual/test-manual-understand-autobuilder.xml @@ -8,18 +8,18 @@ Understanding the Yocto Project Autobuilder
Execution Flow within the Autobuilder - The “a-full” and “a-quick” targets are the usual entry points into the Autobuilder and + The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and it makes sense to follow the process through the system starting there. This is best visualised from the Autobuilder Console view (https://autobuilder.yoctoproject.org/typhoon/#/console). - Each item along the top of that view represents some “target build” and these targets - are all run in parallel. The ‘full’ build will trigger the majority of them, the “quick” + Each item along the top of that view represents some "target build" and these targets + are all run in parallel. The 'full' build will trigger the majority of them, the "quick" build will trigger some subset of them. The Autobuilder effectively runs whichever configuration is defined for each of those targets on a seperate buildbot worker. To understand the configuration, you need to look at the entry on config.json file within the yocto-autobuilder-helper repository. The targets are defined in - the ‘overrides’ section, a quick example could be qemux86-64 which looks + the ‘overrides' section, a quick example could be qemux86-64 which looks like: "qemux86-64" : { "MACHINE" : "qemux86-64", @@ -31,7 +31,7 @@ } }, And - to expand that, you need the “arch-qemu” entry from the “templates” section, which looks + to expand that, you need the "arch-qemu" entry from the "templates" section, which looks like: "arch-qemu" : { "BUILDINFO" : true, @@ -52,10 +52,10 @@ } }, Combining - these two entries you can see that “qemux86-64” is a three step build where the + these two entries you can see that "qemux86-64" is a three step build where the bitbake BBTARGETS would be run, then bitbake SANITYTARGETS for each step; all for - MACHINE=”qemx86-64” but with differing SDKMACHINE settings. In + MACHINE="qemx86-64" but with differing SDKMACHINE settings. In step 1 an extra variable is added to the auto.conf file to enable wic image generation. While not every detail of this is covered here, you can see how the templating @@ -260,7 +260,7 @@ Cleanup the build directory using clobberdir if the - build was successful, else rename it to “build-renamed” for potential future + build was successful, else rename it to "build-renamed" for potential future debugging. -- cgit v1.2.3-54-g00ecf