summaryrefslogtreecommitdiffstats
path: root/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
diff options
context:
space:
mode:
Diffstat (limited to 'bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst')
-rw-r--r--bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst243
1 files changed, 131 insertions, 112 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
index a8815f3e22..f62ddffe8e 100644
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
+++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
@@ -27,22 +27,28 @@ and unpacking the files is often optionally followed by patching.
27Patching, however, is not covered by this module. 27Patching, however, is not covered by this module.
28 28
29The code to execute the first part of this process, a fetch, looks 29The code to execute the first part of this process, a fetch, looks
30something like the following: src_uri = (d.getVar('SRC_URI') or 30something like the following: ::
31"").split() fetcher = bb.fetch2.Fetch(src_uri, d) fetcher.download() 31
32 src_uri = (d.getVar('SRC_URI') or "").split()
33 fetcher = bb.fetch2.Fetch(src_uri, d)
34 fetcher.download()
35
32This code sets up an instance of the fetch class. The instance uses a 36This code sets up an instance of the fetch class. The instance uses a
33space-separated list of URLs from the :term:`SRC_URI` 37space-separated list of URLs from the :term:`SRC_URI`
34variable and then calls the ``download`` method to download the files. 38variable and then calls the ``download`` method to download the files.
35 39
36The instantiation of the fetch class is usually followed by: rootdir = 40The instantiation of the fetch class is usually followed by: ::
37l.getVar('WORKDIR') fetcher.unpack(rootdir) This code unpacks the 41
38downloaded files to the specified by ``WORKDIR``. 42 rootdir = l.getVar('WORKDIR')
43 fetcher.unpack(rootdir)
44
45This code unpacks the downloaded files to the specified by ``WORKDIR``.
39 46
40.. note:: 47.. note::
41 48
42 For convenience, the naming in these examples matches the variables 49 For convenience, the naming in these examples matches the variables
43 used by OpenEmbedded. If you want to see the above code in action, 50 used by OpenEmbedded. If you want to see the above code in action,
44 examine the OpenEmbedded class file 51 examine the OpenEmbedded class file ``base.bbclass``
45 base.bbclass
46 . 52 .
47 53
48The ``SRC_URI`` and ``WORKDIR`` variables are not hardcoded into the 54The ``SRC_URI`` and ``WORKDIR`` variables are not hardcoded into the
@@ -61,30 +67,37 @@ URLs by looking for source files in a specific search order:
61 from ``SRC_URI``). 67 from ``SRC_URI``).
62 68
63- *Mirror Sites:* If fetch failures occur, BitBake next uses mirror 69- *Mirror Sites:* If fetch failures occur, BitBake next uses mirror
64 locations as defined by the :term:`MIRRORS` 70 locations as defined by the :term:`MIRRORS` variable.
65 variable.
66 71
67For each URL passed to the fetcher, the fetcher calls the submodule that 72For each URL passed to the fetcher, the fetcher calls the submodule that
68handles that particular URL type. This behavior can be the source of 73handles that particular URL type. This behavior can be the source of
69some confusion when you are providing URLs for the ``SRC_URI`` variable. 74some confusion when you are providing URLs for the ``SRC_URI`` variable.
70Consider the following two URLs: 75Consider the following two URLs: ::
71http://git.yoctoproject.org/git/poky;protocol=git 76
72git://git.yoctoproject.org/git/poky;protocol=http In the former case, 77 http://git.yoctoproject.org/git/poky;protocol=git
73the URL is passed to the ``wget`` fetcher, which does not understand 78 git://git.yoctoproject.org/git/poky;protocol=http
74"git". Therefore, the latter case is the correct form since the Git 79
80In the former case, the URL is passed to the ``wget`` fetcher, which does not
81understand "git". Therefore, the latter case is the correct form since the Git
75fetcher does know how to use HTTP as a transport. 82fetcher does know how to use HTTP as a transport.
76 83
77Here are some examples that show commonly used mirror definitions: 84Here are some examples that show commonly used mirror definitions: ::
78PREMIRRORS ?= "\\ bzr://.*/.\* http://somemirror.org/sources/ \\n \\ 85
79cvs://.*/.\* http://somemirror.org/sources/ \\n \\ git://.*/.\* 86 PREMIRRORS ?= "\
80http://somemirror.org/sources/ \\n \\ hg://.*/.\* 87 bzr://.*/.\* http://somemirror.org/sources/ \\n \
81http://somemirror.org/sources/ \\n \\ osc://.*/.\* 88 cvs://.*/.\* http://somemirror.org/sources/ \\n \
82http://somemirror.org/sources/ \\n \\ p4://.*/.\* 89 git://.*/.\* http://somemirror.org/sources/ \\n \
83http://somemirror.org/sources/ \\n \\ svn://.*/.\* 90 hg://.*/.\* http://somemirror.org/sources/ \\n \
84http://somemirror.org/sources/ \\n" MIRRORS =+ "\\ ftp://.*/.\* 91 osc://.*/.\* http://somemirror.org/sources/ \\n \
85http://somemirror.org/sources/ \\n \\ http://.*/.\* 92 p4://.*/.\* http://somemirror.org/sources/ \\n \
86http://somemirror.org/sources/ \\n \\ https://.*/.\* 93 svn://.*/.\* http://somemirror.org/sources/ \\n"
87http://somemirror.org/sources/ \\n" It is useful to note that BitBake 94
95 MIRRORS =+ "\
96 ftp://.*/.\* http://somemirror.org/sources/ \\n \
97 http://.*/.\* http://somemirror.org/sources/ \\n \
98 https://.*/.\* http://somemirror.org/sources/ \\n"
99
100It is useful to note that BitBake
88supports cross-URLs. It is possible to mirror a Git repository on an 101supports cross-URLs. It is possible to mirror a Git repository on an
89HTTP server as a tarball. This is what the ``git://`` mapping in the 102HTTP server as a tarball. This is what the ``git://`` mapping in the
90previous example does. 103previous example does.
@@ -98,15 +111,24 @@ File integrity is of key importance for reproducing builds. For
98non-local archive downloads, the fetcher code can verify SHA-256 and MD5 111non-local archive downloads, the fetcher code can verify SHA-256 and MD5
99checksums to ensure the archives have been downloaded correctly. You can 112checksums to ensure the archives have been downloaded correctly. You can
100specify these checksums by using the ``SRC_URI`` variable with the 113specify these checksums by using the ``SRC_URI`` variable with the
101appropriate varflags as follows: SRC_URI[md5sum] = "value" 114appropriate varflags as follows: ::
102SRC_URI[sha256sum] = "value" You can also specify the checksums as 115
103parameters on the ``SRC_URI`` as shown below: SRC_URI = 116 SRC_URI[md5sum] = "value"
104"http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" 117 SRC_URI[sha256sum] = "value"
118
119You can also specify the checksums as
120parameters on the ``SRC_URI`` as shown below: ::
121
122 SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
123
105If multiple URIs exist, you can specify the checksums either directly as 124If multiple URIs exist, you can specify the checksums either directly as
106in the previous example, or you can name the URLs. The following syntax 125in the previous example, or you can name the URLs. The following syntax
107shows how you name the URIs: SRC_URI = 126shows how you name the URIs: ::
108"http://example.com/foobar.tar.bz2;name=foo" SRC_URI[foo.md5sum] = 127
1094a8e0f237e961fd7785d19d07fdb994d After a file has been downloaded and 128 SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
129 SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
130
131After a file has been downloaded and
110has had its checksum checked, a ".done" stamp is placed in ``DL_DIR``. 132has had its checksum checked, a ".done" stamp is placed in ``DL_DIR``.
111BitBake uses this stamp during subsequent builds to avoid downloading or 133BitBake uses this stamp during subsequent builds to avoid downloading or
112comparing a checksum for the file again. 134comparing a checksum for the file again.
@@ -182,8 +204,10 @@ time the ``download()`` method is called.
182If you specify a directory, the entire directory is unpacked. 204If you specify a directory, the entire directory is unpacked.
183 205
184Here are a couple of example URLs, the first relative and the second 206Here are a couple of example URLs, the first relative and the second
185absolute: SRC_URI = "file://relativefile.patch" SRC_URI = 207absolute: ::
186"file:///Users/ich/very_important_software" 208
209 SRC_URI = "file://relativefile.patch"
210 SRC_URI = "file:///Users/ich/very_important_software"
187 211
188.. _http-ftp-fetcher: 212.. _http-ftp-fetcher:
189 213
@@ -201,10 +225,11 @@ downloaded file is useful for avoiding collisions in
201:term:`DL_DIR` when dealing with multiple files that 225:term:`DL_DIR` when dealing with multiple files that
202have the same name. 226have the same name.
203 227
204Some example URLs are as follows: SRC_URI = 228Some example URLs are as follows: ::
205"http://oe.handhelds.org/not_there.aac" SRC_URI = 229
206"ftp://oe.handhelds.org/not_there_as_well.aac" SRC_URI = 230 SRC_URI = "http://oe.handhelds.org/not_there.aac"
207"ftp://you@oe.handhelds.org/home/you/secret.plan" 231 SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
232 SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan"
208 233
209.. note:: 234.. note::
210 235
@@ -214,14 +239,14 @@ Some example URLs are as follows: SRC_URI =
214 :: 239 ::
215 240
216 SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47" 241 SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
217 242
218 243
219 Such URLs should should be modified by replacing semi-colons with '&' 244 Such URLs should should be modified by replacing semi-colons with '&'
220 characters: 245 characters:
221 :: 246 ::
222 247
223 SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47" 248 SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"
224 249
225 250
226 In most cases this should work. Treating semi-colons and '&' in 251 In most cases this should work. Treating semi-colons and '&' in
227 queries identically is recommended by the World Wide Web Consortium 252 queries identically is recommended by the World Wide Web Consortium
@@ -230,7 +255,7 @@ Some example URLs are as follows: SRC_URI =
230 :: 255 ::
231 256
232 SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2" 257 SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2"
233 258
234 259
235.. _cvs-fetcher: 260.. _cvs-fetcher:
236 261
@@ -240,20 +265,20 @@ CVS fetcher (``(cvs://``)
240This submodule handles checking out files from the CVS version control 265This submodule handles checking out files from the CVS version control
241system. You can configure it using a number of different variables: 266system. You can configure it using a number of different variables:
242 267
243- *``FETCHCMD_cvs``:* The name of the executable to use when running 268- :term:`FETCHCMD_cvs <FETCHCMD>`: The name of the executable to use when running
244 the ``cvs`` command. This name is usually "cvs". 269 the ``cvs`` command. This name is usually "cvs".
245 270
246- *``SRCDATE``:* The date to use when fetching the CVS source code. A 271- :term:`SRCDATE`: The date to use when fetching the CVS source code. A
247 special value of "now" causes the checkout to be updated on every 272 special value of "now" causes the checkout to be updated on every
248 build. 273 build.
249 274
250- :term:`CVSDIR`\ *:* Specifies where a temporary 275- :term:`CVSDIR`: Specifies where a temporary
251 checkout is saved. The location is often ``DL_DIR/cvs``. 276 checkout is saved. The location is often ``DL_DIR/cvs``.
252 277
253- *``CVS_PROXY_HOST``:* The name to use as a "proxy=" parameter to the 278- CVS_PROXY_HOST: The name to use as a "proxy=" parameter to the
254 ``cvs`` command. 279 ``cvs`` command.
255 280
256- *``CVS_PROXY_PORT``:* The port number to use as a "proxyport=" 281- CVS_PROXY_PORT: The port number to use as a "proxyport="
257 parameter to the ``cvs`` command. 282 parameter to the ``cvs`` command.
258 283
259As well as the standard username and password URL syntax, you can also 284As well as the standard username and password URL syntax, you can also
@@ -282,7 +307,7 @@ The supported parameters are as follows:
282 are forcing the module into a special directory relative to 307 are forcing the module into a special directory relative to
283 :term:`CVSDIR`. 308 :term:`CVSDIR`.
284 309
285- *"rsh"* Used in conjunction with the "method" parameter. 310- *"rsh":* Used in conjunction with the "method" parameter.
286 311
287- *"scmdata":* Causes the CVS metadata to be maintained in the tarball 312- *"scmdata":* Causes the CVS metadata to be maintained in the tarball
288 the fetcher creates when set to "keep". The tarball is expanded into 313 the fetcher creates when set to "keep". The tarball is expanded into
@@ -296,9 +321,10 @@ The supported parameters are as follows:
296 321
297- *"port":* The port to which the CVS server connects. 322- *"port":* The port to which the CVS server connects.
298 323
299Some example URLs are as follows: SRC_URI = 324Some example URLs are as follows: ::
300"cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" SRC_URI = 325
301"cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat" 326 SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
327 SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
302 328
303.. _svn-fetcher: 329.. _svn-fetcher:
304 330
@@ -337,10 +363,11 @@ The supported parameters are as follows:
337 username is different than the username used in the main URL, which 363 username is different than the username used in the main URL, which
338 is passed to the subversion command. 364 is passed to the subversion command.
339 365
340Following are three examples using svn: SRC_URI = 366Following are three examples using svn: ::
341"svn://myrepos/proj1;module=vip;protocol=http;rev=667" SRC_URI = 367
342"svn://myrepos/proj1;module=opie;protocol=svn+ssh" SRC_URI = 368 SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667"
343"svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1" 369 SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh"
370 SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
344 371
345.. _git-fetcher: 372.. _git-fetcher:
346 373
@@ -409,20 +436,22 @@ This fetcher supports the following parameters:
409 parameter implies no branch and only works when the transfer protocol 436 parameter implies no branch and only works when the transfer protocol
410 is ``file://``. 437 is ``file://``.
411 438
412Here are some example URLs: SRC_URI = 439Here are some example URLs: ::
413"git://git.oe.handhelds.org/git/vip.git;tag=version-1" SRC_URI = 440
414"git://git.oe.handhelds.org/git/vip.git;protocol=http" 441 SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
442 SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
415 443
416.. _gitsm-fetcher: 444.. _gitsm-fetcher:
417 445
418Git Submodule Fetcher (``gitsm://``) 446Git Submodule Fetcher (``gitsm://``)
419------------------------------------ 447------------------------------------
420 448
421This fetcher submodule inherits from the `Git fetcher <#git-fetcher>`__ 449This fetcher submodule inherits from the :ref:`Git
422and extends that fetcher's behavior by fetching a repository's 450fetcher<bitbake-user-manual/bitbake-user-manual-fetching:git fetcher
423submodules. :term:`SRC_URI` is passed to the Git 451(\`\`git://\`\`)>` and extends that fetcher's behavior by fetching a
424fetcher as described in the "`Git Fetcher 452repository's submodules. :term:`SRC_URI` is passed to the Git fetcher as
425(``git://``) <#git-fetcher>`__" section. 453described in the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:git
454fetcher (\`\`git://\`\`)` section.
426 455
427.. note:: 456.. note::
428 457
@@ -446,42 +475,33 @@ repository.
446 475
447To use this fetcher, make sure your recipe has proper 476To use this fetcher, make sure your recipe has proper
448:term:`SRC_URI`, :term:`SRCREV`, and 477:term:`SRC_URI`, :term:`SRCREV`, and
449:term:`PV` settings. Here is an example: SRC_URI = 478:term:`PV` settings. Here is an example: ::
450"ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" 479
451SRCREV = "EXAMPLE_CLEARCASE_TAG" PV = "${@d.getVar("SRCREV", 480 SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
452False).replace("/", "+")}" The fetcher uses the ``rcleartool`` or 481 SRCREV = "EXAMPLE_CLEARCASE_TAG"
482 PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"
483
484The fetcher uses the ``rcleartool`` or
453``cleartool`` remote client, depending on which one is available. 485``cleartool`` remote client, depending on which one is available.
454 486
455Following are options for the ``SRC_URI`` statement: 487Following are options for the ``SRC_URI`` statement:
456 488
457- *``vob``*: The name, which must include the prepending "/" character, 489- *vob*: The name, which must include the prepending "/" character,
458 of the ClearCase VOB. This option is required. 490 of the ClearCase VOB. This option is required.
459 491
460- *``module``*: The module, which must include the prepending "/" 492- *module*: The module, which must include the prepending "/"
461 character, in the selected VOB. 493 character, in the selected VOB.
462 494
463 .. note:: 495 .. note::
464 496
465 The 497 The module and vob options are combined to create the load rule in the
466 module 498 view config spec. As an example, consider the vob and module values from
467 and 499 the SRC_URI statement at the start of this section. Combining those values
468 vob 500 results in the following: ::
469 options are combined to create the 501
470 load 502 load /example_vob/example_module
471 rule in the view config spec. As an example, consider the 503
472 vob 504- *proto*: The protocol, which can be either ``http`` or ``https``.
473 and
474 module
475 values from the
476 SRC_URI
477 statement at the start of this section. Combining those values
478 results in the following:
479 ::
480
481 load /example_vob/example_module
482
483
484- *``proto``*: The protocol, which can be either ``http`` or ``https``.
485 505
486By default, the fetcher creates a configuration specification. If you 506By default, the fetcher creates a configuration specification. If you
487want this specification written to an area other than the default, use 507want this specification written to an area other than the default, use
@@ -490,11 +510,8 @@ the specification is written.
490 510
491.. note:: 511.. note::
492 512
493 the 513 the SRCREV loses its functionality if you specify this variable. However,
494 SRCREV 514 SRCREV is still used to label the archive after a fetch even though it does
495 loses its functionality if you specify this variable. However,
496 SRCREV
497 is still used to label the archive after a fetch even though it does
498 not define what is fetched. 515 not define what is fetched.
499 516
500Here are a couple of other behaviors worth mentioning: 517Here are a couple of other behaviors worth mentioning:
@@ -532,34 +549,36 @@ the server's URL and port number, and you can specify a username and
532password directly in your recipe within ``SRC_URI``. 549password directly in your recipe within ``SRC_URI``.
533 550
534Here is an example that relies on ``P4CONFIG`` to specify the server URL 551Here is an example that relies on ``P4CONFIG`` to specify the server URL
535and port, username, and password, and fetches the Head Revision: SRC_URI 552and port, username, and password, and fetches the Head Revision: ::
536= "p4://example-depot/main/source/..." SRCREV = "${AUTOREV}" PV = 553
537"p4-${SRCPV}" S = "${WORKDIR}/p4" 554 SRC_URI = "p4://example-depot/main/source/..."
555 SRCREV = "${AUTOREV}"
556 PV = "p4-${SRCPV}"
557 S = "${WORKDIR}/p4"
538 558
539Here is an example that specifies the server URL and port, username, and 559Here is an example that specifies the server URL and port, username, and
540password, and fetches a Revision based on a Label: P4PORT = 560password, and fetches a Revision based on a Label: ::
541"tcp:p4server.example.net:1666" SRC_URI = 561
542"p4://user:passwd@example-depot/main/source/..." SRCREV = "release-1.0" 562 P4PORT = "tcp:p4server.example.net:1666"
543PV = "p4-${SRCPV}" S = "${WORKDIR}/p4" 563 SRC_URI = "p4://user:passwd@example-depot/main/source/..."
564 SRCREV = "release-1.0"
565 PV = "p4-${SRCPV}"
566 S = "${WORKDIR}/p4"
544 567
545.. note:: 568.. note::
546 569
547 You should always set 570 You should always set S to "${WORKDIR}/p4" in your recipe.
548 S
549 to
550 "${WORKDIR}/p4"
551 in your recipe.
552 571
553By default, the fetcher strips the depot location from the local file paths. In 572By default, the fetcher strips the depot location from the local file paths. In
554the above example, the content of ``example-depot/main/source/`` will be placed 573the above example, the content of ``example-depot/main/source/`` will be placed
555in ``${WORKDIR}/p4``. For situations where preserving parts of the remote depot 574in ``${WORKDIR}/p4``. For situations where preserving parts of the remote depot
556paths locally is desirable, the fetcher supports two parameters: 575paths locally is desirable, the fetcher supports two parameters:
557 576
558- **"module":** 577- *"module":*
559 The top-level depot location or directory to fetch. The value of this 578 The top-level depot location or directory to fetch. The value of this
560 parameter can also point to a single file within the depot, in which case 579 parameter can also point to a single file within the depot, in which case
561 the local file path will include the module path. 580 the local file path will include the module path.
562- **"remotepath":** 581- *"remotepath":*
563 When used with the value "``keep``", the fetcher will mirror the full depot 582 When used with the value "``keep``", the fetcher will mirror the full depot
564 paths locally for the specified location, even in combination with the 583 paths locally for the specified location, even in combination with the
565 ``module`` parameter. 584 ``module`` parameter.
@@ -589,7 +608,7 @@ Repo Fetcher (``repo://``)
589This fetcher submodule fetches code from ``google-repo`` source control 608This fetcher submodule fetches code from ``google-repo`` source control
590system. The fetcher works by initiating and syncing sources of the 609system. The fetcher works by initiating and syncing sources of the
591repository into :term:`REPODIR`, which is usually 610repository into :term:`REPODIR`, which is usually
592:term:`DL_DIR`\ ``/repo``. 611``${DL_DIR}/repo``.
593 612
594This fetcher supports the following parameters: 613This fetcher supports the following parameters:
595 614
@@ -600,10 +619,10 @@ This fetcher supports the following parameters:
600 619
601- *"manifest":* Name of the manifest file (default: ``default.xml``). 620- *"manifest":* Name of the manifest file (default: ``default.xml``).
602 621
603Here are some example URLs: SRC_URI = 622Here are some example URLs: ::
604"repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml" 623
605SRC_URI = 624 SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
606"repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml" 625 SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
607 626
608Other Fetchers 627Other Fetchers
609-------------- 628--------------