ref-manual: Edits to the question on how source code is fetched.
Updated the question that asks "How doe the OpenEmbedded build system obtain source code and will it work behind my firewall or proxy server?". Some of the variables did not have links or proper font type. (From yocto-docs rev: be1f665b480a47483595381c9a837892100007e8) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
7183fe85ec
commit
40fde06345
|
|
@ -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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue