The term "Poky" refers to the specific reference build system that the Yocto Project provides. Poky is based on OE-Core and BitBake. Thus, the generic term used here for the build system is the "OpenEmbedded build system." Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with changes always being merged to OE-Core or BitBake first before being pulled back into Poky. This practice benefits both projects immediately. For a fuller description of the term "Poky", see the poky term in the Yocto Project Development Manual.

You can use a stand-alone tarball to provide Python 2.6. You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:

These tarballs are self-contained with all required libraries and should work on most Linux systems. To use the tarballs extract them into the root directory and run the appropriate command:

     $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
     $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
                

Once you run the command, BitBake uses Python 2.6.

There are three areas that help with stability;

Support for an additional board is added by creating a BSP layer for it. For more information on how to create a BSP layer, see the Yocto Project Board Support Package (BSP) Developer's Guide.

Usually, if the board is not completely exotic, adding support in the Yocto Project is fairly straightforward.

The software running on the Vernier LabQuest is built using the OpenEmbedded build system. See the Vernier LabQuest website for more information. There are a number of pre-production devices using the OpenEmbedded build system and the Yocto Project team announces them as soon as they are released.

Because the same set of recipes can be used to create output of various formats, the output of an OpenEmbedded build depends on how it was started. Usually, the output is a flashable image ready for the target device.

To add a package, you need to create a BitBake recipe. For information on how to add a package, see the section "Adding a Package" in the Yocto Project Development Manual.

The OpenEmbedded build system can build packages in various formats such as ipk for opkg, Debian package (.deb), or RPM. The packages can then be upgraded using the package tools on the device, much like on a desktop distribution such as Ubuntu or Fedora.

GNOME Mobile is a subset of the GNOME platform targeted at mobile and embedded devices. The the main difference between GNOME Mobile and standard GNOME is that desktop-orientated libraries have been removed, along with deprecated libraries, creating a much smaller footprint.

You are probably running the build on an NTFS filesystem. Use ext2, ext3, or ext4 instead.

To get the Yocto Project working under RHEL/CentOS 5.1 you need to first install some required packages. The standard CentOS packages needed are:

On top of these, you need the following external packages:

Once these packages are installed, the OpenEmbedded build system will be able to build standard images. However, there might be a problem with the QEMU emulator segfaulting. You can either disable the generation of binary locales by setting ENABLE_BINARY_LOCALE_GENERATION to "0" or by removing the linux-2.6-execshield.patch from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.

Nothing is wrong. The OpenEmbedded build system checks any configured source mirrors before downloading from the upstream sources. The build system does this searching for both source archives and pre-checked out versions of SCM managed software. These checks help in large installations because it can reduce load on the SCM servers themselves. The address above is one of the default mirrors configured into the build system. Consequently, if an upstream source disappears, the team can place sources there so builds continue to work.

Set SRC_URI_OVERRIDES_PACKAGE_ARCH = "0" in the .bb file but make sure the package is manually marked as machine-specific in the case that needs it. The code that handles SRC_URI_OVERRIDES_PACKAGE_ARCH is in base.bbclass.

Most source fetching by the OpenEmbedded build system is done by wget and you therefore need to specify the proxy settings in a .wgetrc file in your home directory. Example settings in that file would be

     http_proxy = http://proxy.yoyodyne.com:18023/
     ftp_proxy = http://proxy.yoyodyne.com:18023/
                

The Yocto Project also includes a site.conf.sample file that shows how to configure CVS and Git proxy servers if needed.

The *-native targets are designed to run on the system being used for the build. These are usually tools that are needed to assist the build in some way such as quilt-native, which is used to apply patches. The non-native version is the one that runs on the target device.

If the same build is failing in totally different and random ways, the most likely explanation is that either the hardware you're running the build on has some problem, or, if you are running the build under virtualisation, the virtualisation probably has bugs. The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and CPU activity and is sensitive to even single bit failures in any of these areas. True random failures have always been traced back to hardware or virtualisation issues.

This is a difficult question and you need to consult your lawyer for the answer for your specific case. It is worth bearing in mind that for GPL compliance there needs to be enough information shipped to allow someone else to rebuild the same end result you are shipping. This means sharing the source code, any patches applied to it, and also any configuration information about how that package was configured and built.

You need to create a form factor file as described in the "Miscellaneous Recipe Files" section and set the HAVE_TOUCHSCREEN variable equal to one as follows:

     HAVE_TOUCHSCREEN=1
                

The default interfaces file provided by the netbase recipe does not automatically bring up network interfaces. Therefore, you will need to add a BSP-specific netbase that includes an interfaces file. See the "Miscellaneous Recipe Files" section for information on creating these types of miscellaneous recipe files.

For example, add the following files to your layer:

     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
                

Images are created to be 1.2 times the size of the populated root filesystem. To modify this ratio so that there is more free space available, you need to set the configuration value IMAGE_OVERHEAD_FACTOR. For example, setting IMAGE_OVERHEAD_FACTOR to 1.5 sets the image size ratio to one and a half times the size of the populated root filesystem.

     IMAGE_OVERHEAD_FACTOR = "1.5"
                

The Yocto Project team has tried to do this before but too many of the tools the OpenEmbedded build system depends on such as autoconf break when they find spaces in pathnames. Until that situation changes, the team will not support spaces in pathnames.

The toolchain configuration is very flexible and customizable. It is primarily controlled with the TCMODE variable. This variable controls which tcmode-*.inc file to include from the meta/conf/distro/include directory within the source directory.

The default value of TCMODE is "default" (i.e. tcmode-default.inc). However, other patterns are accepted. In particular, "external-*" refers to external toolchains of which there are some basic examples included in the OpenEmbedded Core (meta). You can use your own custom toolchain definition in your own layer (or as defined in the local.conf file) at the location conf/distro/include/tcmode-*.inc.

In addition to the toolchain configuration, you also need a corresponding toolchain recipe file. This recipe file needs to package up any pre-built objects in the toolchain such as libgcc, libstdcc++, any locales, and libc. An example is the external-sourcery-toolchain.bb, which is located in meta/recipes-core/meta/ within the source directory.

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.

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.

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.

As an example, you could add a specific server for Poky to attempt before any others by adding something like the following to the local.conf configuration file:

     PREMIRRORS_prepend = "\
     git://.*/.* http://www.yoctoproject.org/sources/ \n \
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"
                

These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS requests and direct them to the http:// sources mirror. You can use file:// URLs to point to local directories or network shares as well.

Aside from the previous technique, these options also exist:

     BB_NO_NETWORK = "1"
                

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.

Here is another technique:

     BB_FETCH_PREMIRRORONLY = "1"
                 

This statement limits Poky to pulling source from the PREMIRRORS only. Again, this technique is useful for reproducing builds.

Here is another technique:

     BB_GENERATE_MIRROR_TARBALLS = "1"
                 

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.

Finally, consider an example where you are behind an HTTP-only firewall. You could make the following changes to the local.conf configuration file as long as the PREMIRROR server is up to date:

     PREMIRRORS_prepend = "\
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"
     BB_FETCH_PREMIRRORONLY = "1" 
                 

These changes would cause Poky to successfully fetch source over HTTP and any network accesses to anything other than the PREMIRROR would fail.

The build system also honors the standard shell environment variables http_proxy, ftp_proxy, https_proxy, and all_proxy to redirect requests through proxy servers.

Yes - you can easily do this. When you use BitBake to build an image, all the build output goes into the directory created when you source the oe-init-build-env setup file. By default, this build directory is named build but can be named anything you want.

Within the build directory is the tmp directory. To remove all the build output yet preserve any source code or downloaded files from previous builds, simply remove the tmp directory.