diff options
Diffstat (limited to 'doc/bitbake-user-manual/bitbake-user-manual-fetching.rst')
| -rw-r--r-- | doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | 42 |
1 files changed, 21 insertions, 21 deletions
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst index 626278e44..3167ab138 100644 --- a/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst +++ b/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst @@ -27,7 +27,7 @@ and unpacking the files is often optionally followed by patching. Patching, however, is not covered by this module. The code to execute the first part of this process, a fetch, looks -something like the following: :: +something like the following:: src_uri = (d.getVar('SRC_URI') or "").split() fetcher = bb.fetch2.Fetch(src_uri, d) @@ -37,7 +37,7 @@ This code sets up an instance of the fetch class. The instance uses a space-separated list of URLs from the :term:`SRC_URI` variable and then calls the ``download`` method to download the files. -The instantiation of the fetch class is usually followed by: :: +The instantiation of the fetch class is usually followed by:: rootdir = l.getVar('WORKDIR') fetcher.unpack(rootdir) @@ -72,7 +72,7 @@ URLs by looking for source files in a specific search order: For each URL passed to the fetcher, the fetcher calls the submodule that handles that particular URL type. This behavior can be the source of some confusion when you are providing URLs for the ``SRC_URI`` variable. -Consider the following two URLs: :: +Consider the following two URLs:: http://git.yoctoproject.org/git/poky;protocol=git git://git.yoctoproject.org/git/poky;protocol=http @@ -81,7 +81,7 @@ In the former case, the URL is passed to the ``wget`` fetcher, which does not understand "git". Therefore, the latter case is the correct form since the Git fetcher does know how to use HTTP as a transport. -Here are some examples that show commonly used mirror definitions: :: +Here are some examples that show commonly used mirror definitions:: PREMIRRORS ?= "\ bzr://.*/.\* http://somemirror.org/sources/ \\n \ @@ -111,19 +111,19 @@ File integrity is of key importance for reproducing builds. For non-local archive downloads, the fetcher code can verify SHA-256 and MD5 checksums to ensure the archives have been downloaded correctly. You can specify these checksums by using the ``SRC_URI`` variable with the -appropriate varflags as follows: :: +appropriate varflags as follows:: SRC_URI[md5sum] = "value" SRC_URI[sha256sum] = "value" You can also specify the checksums as -parameters on the ``SRC_URI`` as shown below: :: +parameters on the ``SRC_URI`` as shown below:: SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" If multiple URIs exist, you can specify the checksums either directly as in the previous example, or you can name the URLs. The following syntax -shows how you name the URIs: :: +shows how you name the URIs:: SRC_URI = "http://example.com/foobar.tar.bz2;name=foo" SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d @@ -201,7 +201,7 @@ time the ``download()`` method is called. If you specify a directory, the entire directory is unpacked. Here are a couple of example URLs, the first relative and the second -absolute: :: +absolute:: SRC_URI = "file://relativefile.patch" SRC_URI = "file:///Users/ich/very_important_software" @@ -222,7 +222,7 @@ downloaded file is useful for avoiding collisions in :term:`DL_DIR` when dealing with multiple files that have the same name. -Some example URLs are as follows: :: +Some example URLs are as follows:: SRC_URI = "http://oe.handhelds.org/not_there.aac" SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac" @@ -318,7 +318,7 @@ The supported parameters are as follows: - *"port":* The port to which the CVS server connects. -Some example URLs are as follows: :: +Some example URLs are as follows:: SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat" @@ -360,7 +360,7 @@ The supported parameters are as follows: username is different than the username used in the main URL, which is passed to the subversion command. -Following are three examples using svn: :: +Following are three examples using svn:: SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667" SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh" @@ -433,7 +433,7 @@ This fetcher supports the following parameters: parameter implies no branch and only works when the transfer protocol is ``file://``. -Here are some example URLs: :: +Here are some example URLs:: SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1" SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http" @@ -481,7 +481,7 @@ repository. To use this fetcher, make sure your recipe has proper :term:`SRC_URI`, :term:`SRCREV`, and -:term:`PV` settings. Here is an example: :: +:term:`PV` settings. Here is an example:: SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" SRCREV = "EXAMPLE_CLEARCASE_TAG" @@ -503,7 +503,7 @@ Following are options for the ``SRC_URI`` statement: The module and vob options are combined to create the load rule in the view config spec. As an example, consider the vob and module values from the SRC_URI statement at the start of this section. Combining those values - results in the following: :: + results in the following:: load /example_vob/example_module @@ -555,7 +555,7 @@ the server's URL and port number, and you can specify a username and password directly in your recipe within ``SRC_URI``. Here is an example that relies on ``P4CONFIG`` to specify the server URL -and port, username, and password, and fetches the Head Revision: :: +and port, username, and password, and fetches the Head Revision:: SRC_URI = "p4://example-depot/main/source/..." SRCREV = "${AUTOREV}" @@ -563,7 +563,7 @@ and port, username, and password, and fetches the Head Revision: :: S = "${WORKDIR}/p4" Here is an example that specifies the server URL and port, username, and -password, and fetches a Revision based on a Label: :: +password, and fetches a Revision based on a Label:: P4PORT = "tcp:p4server.example.net:1666" SRC_URI = "p4://user:passwd@example-depot/main/source/..." @@ -589,7 +589,7 @@ paths locally is desirable, the fetcher supports two parameters: paths locally for the specified location, even in combination with the ``module`` parameter. -Here is an example use of the the ``module`` parameter: :: +Here is an example use of the the ``module`` parameter:: SRC_URI = "p4://user:passwd@example-depot/main;module=source/..." @@ -597,7 +597,7 @@ In this case, the content of the top-level directory ``source/`` will be fetched to ``${P4DIR}``, including the directory itself. The top-level directory will be accesible at ``${P4DIR}/source/``. -Here is an example use of the the ``remotepath`` parameter: :: +Here is an example use of the the ``remotepath`` parameter:: SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep" @@ -625,7 +625,7 @@ This fetcher supports the following parameters: - *"manifest":* Name of the manifest file (default: ``default.xml``). -Here are some example URLs: :: +Here are some example URLs:: SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml" SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml" @@ -648,11 +648,11 @@ Such functionality is set by the variable: delegate access to resources, if this variable is set, the Az Fetcher will use it when fetching artifacts from the cloud. -You can specify the AZ_SAS variable as shown below: :: +You can specify the AZ_SAS variable as shown below:: AZ_SAS = "se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>" -Here is an example URL: :: +Here is an example URL:: SRC_URI = "az://<azure-storage-account>.blob.core.windows.net/<foo_container>/<bar_file>" |