Chapter 12. FAQ

-Chapter 12. FAQ

12.1. - How does Poky differ from OpenEmbedded? - -
12.2. - I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7. - Can I still use the Yocto Project? - -
12.3. - How can you claim Poky / OpenEmbedded-Core is stable? - -
12.4. - How do I get support for my board added to the Yocto Project? - -
12.5. - Are there any products built using the OpenEmbedded build system? - -
12.6. - What does the OpenEmbedded build system produce as output? - -
12.7. - How do I add my package to the Yocto Project? - -
12.8. - Do I have to reflash my entire board with a new Yocto Project image when recompiling - a package? - -
12.9. - What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME? - -
12.10. - I see the error 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'. - What is wrong? - -
12.11. - How do I make the Yocto Project work in RHEL/CentOS? - -
12.12. - I see lots of 404 responses for files on - http://www.yoctoproject.org/sources/*. Is something wrong? - -
12.13. - I have machine-specific data in a package for one machine only but the package is - being marked as machine-specific in all cases, how do I prevent this? - -
12.14. - I'm behind a firewall and need to use a proxy server. How do I do that? - -
12.15. - What’s the difference between foo and foo-native? - -
12.16. - I'm seeing random build failures. Help?! - -
12.17. - What do we need to ship for license compliance? - -
12.18. - How do I disable the cursor on my touchscreen device? - -
12.19. - How do I make sure connected network interfaces are brought up by default? - -
12.20. - How do I create images with more free space? - -
12.21. - Why don't you support directories with spaces in the pathnames? - -
12.22. - How do I use an external toolchain? - -
12.23. - How does the OpenEmbedded build system obtain source code and will it work behind my - firewall or proxy server? - -
12.24. - Can I get rid of build output so I can start over? - -

- --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- 12.1. -	- How does Poky differ from OpenEmbedded? -
	- 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. -
- 12.2. -	- I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7. - Can I still use the Yocto Project? -
	- - 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: - - - 32-bit tarball - 64-bit tarball - - - - - 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. - -
- 12.3. -	- How can you claim Poky / OpenEmbedded-Core is stable? -
	- - There are three areas that help with stability; - - - The Yocto Project team keeps - OE-Core small - and focused, containing around 830 recipes as opposed to the thousands - available in other OpenEmbedded community layers. - Keeping it small makes it easy to test and maintain. - The Yocto Project team runs manual and automated tests - using a small, fixed set of reference hardware as well as emulated - targets. - The Yocto Project uses an an autobuilder, - which provides continuous build and integration tests. - - - -
- 12.4. -	- How do I get support for my board added to the Yocto Project? -
	- - 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. - -
- 12.5. -	- Are there any products built using the OpenEmbedded build system? -
	- 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. -
- 12.6. -	- What does the OpenEmbedded build system produce as output? -
	- 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. -
- 12.7. -	- How do I add my package to the Yocto Project? -
	- 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. -
- 12.8. -	- Do I have to reflash my entire board with a new Yocto Project image when recompiling - a package? -
	- 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. -
- 12.9. -	- What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME? -
	- 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. -
- 12.10. -	- I see the error '`chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x`'. - What is wrong? -
	- You are probably running the build on an NTFS filesystem. - Use `ext2`, `ext3`, or `ext4` instead. -
- 12.11. -	- How do I make the Yocto Project work in RHEL/CentOS? -
	- - 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: - - - "Development tools" (selected during installation) - `texi2html` - `compat-gcc-34` - - - On top of these, you need the following external packages: - - - `python-sqlite2` from - DAG repository - - `help2man` from - Karan repository - - - - - 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. - -
- 12.12. -	- I see lots of 404 responses for files on - `http://www.yoctoproject.org/sources/*`. Is something wrong? -
	- 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. -
- 12.13. -	- I have machine-specific data in a package for one machine only but the package is - being marked as machine-specific in all cases, how do I prevent this? -
	- 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`. -
- 12.14. -	- I'm behind a firewall and need to use a proxy server. How do I do that? -
	- - 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. - -
- 12.15. -	- What’s the difference between `foo` and `foo-native`? -
	- 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. -
- 12.16. -	- I'm seeing random build failures. Help?! -
	- 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. -
- 12.17. -	- What do we need to ship for license compliance? -
	- 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. -
- 12.18. -	- How do I disable the cursor on my touchscreen device? -
	- - 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 - - - -
- 12.19. -	- How do I make sure connected network interfaces are brought up by default? -
	- - 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 - - - -
- 12.20. -	- How do I create images with more free space? -
	- - 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" - - - -
- 12.21. -	- Why don't you support directories with spaces in the pathnames? -
	- 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. -
- 12.22. -	- How do I use an external toolchain? -
	- - 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. - -
- 12.23. -	- How does the OpenEmbedded build system obtain source code and will it work behind my - firewall or proxy server? -
	- - 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. - -
- 12.24. -	- Can I get rid of build output so I can start over? -
	- - 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. - -