TipsAndTricks/TeamWorkflows: Difference between revisions
From Yocto Project
Jump to navigationJump to search
Joshua Lock (talk | contribs) (Initial documentation of "production" workflows) |
(→Goals) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 10: | Line 10: | ||
== Goals == | == Goals == | ||
* Quickly build images from pre-existing artefacts. | * Quickly build images from pre-existing artefacts on minimal hardware (e.g. laptops). | ||
* Avoid networking issues fetching from some upstream hosts (i.e. great firewall) | * Avoid networking issues fetching from some upstream hosts (i.e. great firewall) | ||
| Line 16: | Line 16: | ||
* A mirror of sstate objects (i.e. contents of <code>SSTATE_DIR</code>) which the build machine can access via a uri (file://, http://, etc) | * A mirror of sstate objects (i.e. contents of <code>SSTATE_DIR</code>) which the build machine can access via a uri (file://, http://, etc) | ||
* if using the example ''poky'' distro you can use the mirrors on the Yocto Project infrastructure at [http://sstate.yoctoproject.org sstate.yoctoproject.org] | ** if using the example ''poky'' distro you can use the mirrors on the Yocto Project infrastructure at [http://sstate.yoctoproject.org sstate.yoctoproject.org] | ||
* A fixed version of the metadata which matches the sstate mirror (if the metadata isn't identical there's a strong chance of sstate checksum mismatches which result in being unable to use the mirrored objects and having to build recipes and their dependencies) | * A fixed version of the metadata which matches the sstate mirror (if the metadata isn't identical there's a strong chance of sstate checksum mismatches which result in being unable to use the mirrored objects and having to build recipes and their dependencies) | ||
* i.e. if using ''poky'' and the Yocto Project mirrors as above, use a tagged release | ** i.e. if using ''poky'' and the Yocto Project mirrors as above, use a tagged release | ||
* Make use of uninative, this fixed libc implementation ensures greater shared state object reuse for native recipes | * Make use of uninative, this fixed libc implementation ensures greater shared state object reuse for native recipes | ||
* the ''poky'' distro makes use of uninative by default, it's highly recommended that you use uninative in your custom distro | ** the ''poky'' distro makes use of uninative by default, it's highly recommended that you use uninative in your custom distro | ||
* A mirror of the download sources (i.e. contents of <code>DL_DIR</code>) to use as a premirror | * A mirror of the download sources (i.e. contents of <code>DL_DIR</code>) to use as a premirror | ||
* the sources used by the core Yocto Project layers are mirrored on Yocto Project infrastructure at [http://downloads.yoctoproject.org downloads.yoctoproject.org] | ** the sources used by the core Yocto Project layers are mirrored on Yocto Project infrastructure at [http://downloads.yoctoproject.org downloads.yoctoproject.org] | ||
* '''Note''': the ''poky'' distro uses the Yocto Project download mirror as a premirror for non-SCM fetchers by default | ** '''Note''': the ''poky'' distro uses the Yocto Project download mirror as a premirror for non-SCM fetchers by default | ||
== Configuration steps == | == Configuration steps == | ||
Latest revision as of 15:37, 15 June 2017
Note: there's a bug with PREMIRRORS handling. For optimal use of this workflow you should be running with either Morty 2.2.2+/1.32, Pyro 2.3.1+/1.34
OE-Core image builder
How to configure an OE-Core system to build images from shared artefacts.
Goals
- Quickly build images from pre-existing artefacts on minimal hardware (e.g. laptops).
- Avoid networking issues fetching from some upstream hosts (i.e. great firewall)
Requirements
- A mirror of sstate objects (i.e. contents of
SSTATE_DIR) which the build machine can access via a uri (file://, http://, etc)- if using the example poky distro you can use the mirrors on the Yocto Project infrastructure at sstate.yoctoproject.org
- A fixed version of the metadata which matches the sstate mirror (if the metadata isn't identical there's a strong chance of sstate checksum mismatches which result in being unable to use the mirrored objects and having to build recipes and their dependencies)
- i.e. if using poky and the Yocto Project mirrors as above, use a tagged release
- Make use of uninative, this fixed libc implementation ensures greater shared state object reuse for native recipes
- the poky distro makes use of uninative by default, it's highly recommended that you use uninative in your custom distro
- A mirror of the download sources (i.e. contents of
DL_DIR) to use as a premirror- the sources used by the core Yocto Project layers are mirrored on Yocto Project infrastructure at downloads.yoctoproject.org
- Note: the poky distro uses the Yocto Project download mirror as a premirror for non-SCM fetchers by default
Configuration steps
- Use
own-mirrorsto configurePREMIRRORSfor all supported fetchers with a single mirror URL - (optional) add extra protocol-url pairs to
PREMIRRORS - Add
SSTATE_MIRRORS
Example site.conf
# Use Yocto Project source mirror for all sources
SOURCE_MIRROR_URL ?= "http://downloads.yoctoproject.org/mirror/sources/"
INHERIT += "own-mirrors"
# Add extra PREMIRRORS for non-upstream (Yocto Project) components
PREMIRRORS_prepend = "\
https?$://.*/.* http://my-mirrors.example.com/sources/ \n \
git://.*/.* http://my-mirrors.example.com/sources/ \n \
"
# Use Yocto Project sstate mirror and project-specific sstate mirror
SSTATE_MIRRORS = "\
file://.* http://my-mirrros.example.com/sstate/PATH;downloadfilename=PATH \n \
file://.* http://sstate.yoctoproject.org/PATH;downloadfilename=PATH \n \
"
eSDK image builder
How to generate an eSDK to facilitate application development and custom image builds from an existing set of artefacts.
Goals
- Fully contained Yocto Project environment
- go from eSDK install to generated image in <10 minutes
