diff options
| -rw-r--r-- | documentation/ref-manual/faq.xml | 81 |
1 files changed, 49 insertions, 32 deletions
diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml index 176573d..370f65f 100644 --- a/documentation/ref-manual/faq.xml +++ b/documentation/ref-manual/faq.xml @@ -485,30 +485,38 @@ <qandaentry> <question> <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'> - How does the OpenEmbedded build system obtain source code and will it work behind my - firewall or proxy server? + How does the OpenEmbedded build system obtain source code and + will it work behind my firewall or proxy server? </para> </question> <answer> <para> - The way the build system obtains source code is highly configurable. - You can setup the build system to get source code in most environments if - HTTP transport is available. + The way the build system obtains source code is highly + configurable. + You can setup the build system to get source code in most + environments if HTTP transport is available. </para> <para> - When the build system searches for source code, it first tries the local download directory. - If that location fails, Poky tries PREMIRRORS, the upstream source, - and then MIRRORS in that order. + When the build system searches for source code, it first + tries the local download directory. + If that location fails, Poky tries + <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>, + the upstream source, and then + <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link> + in that order. </para> <para> - By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS - for SCM-based sources, - upstreams for normal tarballs, and then falls back to a number of other mirrors - including the Yocto Project source mirror if those fail. + Assuming your distribution is "poky", the OpenEmbedded build + system uses the Yocto Project source + <filename>PREMIRRORS</filename> by default for SCM-based + sources, upstreams for normal tarballs, and then falls back + to a number of other mirrors including the Yocto Project + source mirror if those fail. </para> <para> - As an example, you could add a specific server for Poky to attempt before any - others by adding something like the following to the <filename>local.conf</filename> + As an example, you could add a specific server for the + build system to attempt before any others by adding something + like the following to the <filename>local.conf</filename> configuration file: <literallayout class='monospaced'> PREMIRRORS_prepend = "\ @@ -519,26 +527,29 @@ </literallayout> </para> <para> - These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS - requests and direct them to the <filename>http://</filename> sources mirror. - You can use <filename>file://</filename> URLs to point to local directories - or network shares as well. + These changes cause the build system to intercept Git, FTP, + HTTP, and HTTPS requests and direct them to the + <filename>http://</filename> sources mirror. + You can use <filename>file://</filename> URLs to point to + local directories or network shares as well. </para> <para> Aside from the previous technique, these options also exist: <literallayout class='monospaced'> BB_NO_NETWORK = "1" </literallayout> - This statement tells BitBake to throw an error instead of trying to access the - Internet. - This technique is useful if you want to ensure code builds only from local sources. + This statement tells BitBake to issue an error instead of + trying to access the Internet. + This technique is useful if you want to ensure code builds + only from local sources. </para> <para> Here is another technique: <literallayout class='monospaced'> BB_FETCH_PREMIRRORONLY = "1" </literallayout> - This statement limits Poky to pulling source from the PREMIRRORS only. + This statement limits Poky to pulling source from the + <filename>PREMIRRORS</filename> only. Again, this technique is useful for reproducing builds. </para> <para> @@ -548,12 +559,15 @@ </literallayout> This statement tells Poky to generate mirror tarballs. This technique is useful if you want to create a mirror server. - If not, however, the technique can simply waste time during the build. + If not, however, the technique can simply waste time during + the build. </para> <para> - Finally, consider an example where you are behind an HTTP-only firewall. - You could make the following changes to the <filename>local.conf</filename> - configuration file as long as the PREMIRROR server is up to date: + Finally, consider an example where you are behind an + HTTP-only firewall. + You could make the following changes to the + <filename>local.conf</filename> configuration file as long as + the <filename>PREMIRRORS</filename> server is up to date: <literallayout class='monospaced'> PREMIRRORS_prepend = "\ ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ @@ -561,14 +575,17 @@ https://.*/.* http://www.yoctoproject.org/sources/ \n" BB_FETCH_PREMIRRORONLY = "1" </literallayout> - These changes would cause Poky to successfully fetch source over HTTP and - any network accesses to anything other than the PREMIRROR would fail. + These changes would cause the build system to successfully + fetch source over HTTP and any network accesses to anything + other than the <filename>PREMIRRORS</filename> would fail. </para> <para> - The build system also honors the standard shell environment variables - <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, - <filename>https_proxy</filename>, and <filename>all_proxy</filename> - to redirect requests through proxy servers. + The build system also honors the standard shell environment + variables <filename>http_proxy</filename>, + <filename>ftp_proxy</filename>, + <filename>https_proxy</filename>, and + <filename>all_proxy</filename> to redirect requests through + proxy servers. </para> </answer> </qandaentry> |
