path: root/documentation/poky-ref-manual/faq.xml

<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >

<appendix id='faq'>
<title>FAQ</title>
<qandaset>
    <qandaentry>
        <question>
            <para>
                How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
            </para>
        </question>
        <answer>
            <para>
                Poky is the Yocto Project build system that was derived from <ulink 
                url='&OE_HOME_URL;'>OpenEmbedded</ulink>.
                Poky is a stable, smaller subset focused on the mobile environment. 
                Development in the Yocto Project using Poky is closely tied to OpenEmbedded with 
                features being merged regularly between the two for mutual benefit.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                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?
            </para>
        </question>
        <answer>
            <para>
                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:
                <itemizedlist>
                    <listitem><para><ulink url='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem>
                    <listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem>
                </itemizedlist>
            </para>
            <para>
                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:
                <literallayout class='monospaced'>
     $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
     $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
                </literallayout>
            </para>
            <para>
                Once you run the command, BitBake uses Python 2.6.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How can you claim Poky is stable?
            </para>
        </question>
        <answer>
            <para>
                There are three areas that help with stability;
                <itemizedlist>
                    <listitem><para>The Yocto Project team keeps Poky small and focused.
                        It contains around 650 packages as compared to over 5000 for full 
                        OpenEmbedded.</para></listitem>
                    <listitem><para>The Yocto Project only supports hardware that the 
                        team has access to for testing.</para></listitem>
                    <listitem><para>The Yocto Project uses an an autobuilder,
                        which provides continuous build and integration tests.</para></listitem>
                </itemizedlist>
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I get support for my board added to the Yocto Project?
            </para>
        </question>
        <answer>
            <para>
                There are two main ways to get a board supported in the Yocto Project;
                <itemizedlist>
                    <listitem><para>Send the Yocto Project team information on the board
                        and if the team does not have it yet they will consider adding it.</para></listitem>
                    <listitem><para>Send the Yocto Project team the BitBake recipes if you have them.
                        </para></listitem>
                </itemizedlist>
                Usually, if the board is not completely exotic, adding support in 
                the Yocto Project is fairly straightforward.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                Are there any products using Poky?
            </para>
        </question>
        <answer>
            <para>
                The <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink> is using 
                the Yocto Project build system Poky.  
                See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
                for more information.
                There are a number of pre-production devices using Poky and the Yocto Project team
                announces them as soon as they are released.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                What does the Yocto Project build system Poky produce as output?
            </para>
        </question>
        <answer>
            <para>
                Because the same set of recipes can be used to create output of various formats, the 
                output of a Yocto Project build depends on how it was started. 
                Usually, the output is a flashable image ready for the target device.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I add my package to the Yocto Project?
            </para>
        </question>
        <answer>
            <para>
                To add a package, you need to create a BitBake recipe.
                For information on how to add a package, see the section
                "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Adding a Package</ulink>" 
                in the Yocto Project Development Manual.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                Do I have to reflash my entire board with a new Yocto Project image when recompiling 
                a package?
            </para>
        </question>
        <answer>
            <para>
                The Yocto Project can build packages in various formats such as
                <filename>ipk</filename> for <filename>ipkg</filename>/<filename>opkg</filename>, 
                Debian package (<filename>.deb</filename>), 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.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
            </para>
        </question>
        <answer>
            <para>
                GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink> 
                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. 
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                I see the error '<filename>chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</filename>'.
                What is wrong?
            </para>
        </question>
        <answer>
            <para>
                You are probably running the build on an NTFS filesystem. 
                Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I make the Yocto Project work in RHEL/CentOS?
            </para>
        </question>
        <answer>
            <para>
                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:
                <itemizedlist>
                    <listitem><para>"Development tools" (selected during installation)</para></listitem>
                    <listitem><para><filename>texi2html</filename></para></listitem>
                    <listitem><para><filename>compat-gcc-34</filename></para></listitem>
                </itemizedlist>
                On top of these, you need the following external packages:
                <itemizedlist>
                    <listitem><para><filename>python-sqlite2</filename> from 
                        <ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink>
                        </para></listitem>
                    <listitem><para><filename>help2man</filename> from 
                        <ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem>
                </itemizedlist>
            </para>

            <para>
                Once these packages are installed, the Yocto Project 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 
                <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
                </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
                from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                I see lots of 404 responses for files on 
                <filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
            </para>
        </question>
        <answer>
            <para>
                Nothing is wrong.
                The Yocto Project checks any configured source mirrors before downloading 
                from the upstream sources. 
                The Yocto Project 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 
                Yocto Project.
                Consequently, if an upstream source disappears, the team 
                can place sources there so builds continue to work.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                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?
            </para>
        </question>
        <answer>
            <para>
                Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
                </filename> = "0" in the <filename>.bb</filename> file but make sure the package is 
                manually marked as 
                machine-specific in the case that needs it. 
                The code that handles <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in <filename>base.bbclass</filename>.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                I'm behind a firewall and need to use a proxy server. How do I do that?
            </para>
        </question>
        <answer>
            <para>
                Most source fetching by the Yocto Project is done by <filename>wget</filename>
                and you therefore need to specify the proxy settings in a 
                <filename>.wgetrc</filename> file in your home directory. 
                Example settings in that file would be 
                <literallayout class='monospaced'>
     http_proxy = http://proxy.yoyodyne.com:18023/
     ftp_proxy = http://proxy.yoyodyne.com:18023/
                </literallayout>
                The Yocto Project also includes a <filename>site.conf.sample</filename>
                file that shows how to configure CVS and Git proxy servers
                if needed.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                I'm using Ubuntu Intrepid and am seeing build failures. What’s wrong?
            </para>
        </question>
        <answer>
            <para>
	            In Intrepid, Ubuntu turns on by default the normally optional compile-time security features 
		        and warnings. 
                There are more details at 
                <ulink url='https://wiki.ubuntu.com/CompilerFlags'>https://wiki.ubuntu.com/CompilerFlags</ulink>.
		        You can work around this problem by disabling those options by adding 
                the following to the <filename>BUILD_CPPFLAGS</filename> variable in the
                <filename>conf/bitbake.conf</filename> file.
                <literallayout class='monospaced'>
     " -Wno-format-security -U_FORTIFY_SOURCE" 
                </literallayout>
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                What’s the difference between <filename>foo</filename> and <filename>foo-native</filename>?
            </para>
        </question>
        <answer>
            <para>
                The <filename>*-native</filename> 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 
                <filename>quilt-native</filename>, which is used to apply patches. 
                The non-native version is the one that runs on the target device.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                I'm seeing random build failures. Help?!
            </para>
        </question>
        <answer>
            <para>
                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 Yocto Project 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.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                What do we need to ship for license compliance?
            </para>
        </question>
        <answer>
            <para>
                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.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I disable the cursor on my touchscreen device?
            </para>
        </question>
        <answer>
            <para>
                You need to create a form factor file as described in the
                "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>"
                section and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
                <literallayout class='monospaced'>
     HAVE_TOUCHSCREEN=1
                </literallayout>
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I make sure connected network interfaces are brought up by default?
            </para>
        </question>
        <answer>
            <para>
                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 "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>"
                section for information on creating these types of miscellaneous recipe files.
            </para>
            <para>
                For example, add the following files to your layer:
                <literallayout class='monospaced'>
     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
     meta-MACHINE/recipes-bsp/netbase/netbase_4.44.bbappend
                </literallayout>
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I create images with more free space?
            </para>
        </question>
        <answer>
            <para>
                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 <filename>IMAGE_OVERHEAD_FACTOR</filename>.  
                For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets 
                the image size ratio to one and a half times the size of the populated 
                root filesystem.
                <literallayout class='monospaced'>
     IMAGE_OVERHEAD_FACTOR = "1.5"
                </literallayout>
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                Why don't you support directories with spaces in the pathnames?
            </para>
        </question>
        <answer>
            <para>
                The Yocto Project team has tried to do this before but too many of the tools 
                the Yocto Project depends on such as <filename>autoconf</filename> 
                break when they find spaces in pathnames.  
                Until that situation changes, the team will not support spaces in pathnames.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para>
                How do I use an external toolchain?
            </para>
        </question>
        <answer>
            <para>
                The toolchain configuration is very flexible and customizable.
                It is primarily controlled with the 
                <filename><link linkend='var-TCMODE'>TCMODE</link></filename> variable.
                This variable controls which file to include 
                (<filename>conf/distro/include/tcmode-*.inc</filename>).
            </para>
            <para>
                The default value of <filename>TCMODE</filename> is "default".
                However, other patterns are accepted.
                In particular, "external-*" refers to external toolchains of which there are some basic examples
                included with the core.
                A user can use their own custom toolchain definition in their own layer 
                (or as defined in the <filename>local.conf</filename> file) at the location 
                <filename>conf/distro/include/tcmode-*.inc</filename>.
            </para>
            <para>
                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 
                <filename>libgcc</filename>, <filename>libstdcc++</filename>, 
                any locales and <filename>libc</filename>.
                An example is the <filename>external-csl-toolchain_2008q3-72.bb</filename>, which reuses the core 
                <filename>libc</filename> packaging class to do most of the work.
            </para>
        </answer>
    </qandaentry>

    <qandaentry>
        <question>
            <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
                How does the Yocto Project build system obtain source code and will it work behind my 
                firewall or proxy server?
            </para>
        </question>
        <answer>
            <para>
                The way the Yocto Project obtains source code is highly configurable.
                You can setup the Yocto Project to get source code in most environments if
                HTTP transport is available.
            </para>
            <para>
                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.
            </para>
            <para>
                By default, Poky 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.
            </para>
            <para>
                As an example, you could add a specific server for Poky to attempt before any
                others by adding something like the following to the <filename>local.conf</filename>
                configuration file:
                <literallayout class='monospaced'>
     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"
                </literallayout>
            </para>
            <para>
                These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS
                requests and direct them to the <filename>http://</filename> sources mirror.
                You can use <filename>file://</filename> URLs to point to local directories 
                or network shares as well.
            </para>
            <para>
                Aside from the previous technique, these options also exist:
                <literallayout class='monospaced'>
     BB_NO_NETWORK = "1"
                </literallayout>
                 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.
             </para>
             <para>
                 Here is another technique:
                 <literallayout class='monospaced'>
     BB_FETCH_PREMIRRORONLY = "1"
                 </literallayout>
                 This statement limits Poky to pulling source from the PREMIRRORS only.
                 Again, this technique is useful for reproducing builds.
             </para>
             <para>
                 Here is another technique:
                 <literallayout class='monospaced'>
     BB_GENERATE_MIRROR_TARBALLS = "1"
                 </literallayout>
                 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.
             </para>
             <para>
                 Finally, consider an example where you are behind an HTTP-only firewall.
                 You could make the following changes to the <filename>local.conf</filename>
                 configuration file as long as the PREMIRROR server is up to date:
                 <literallayout class='monospaced'>
     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" 
                 </literallayout>
                 These changes would cause Poky to successfully fetch source over HTTP and 
                 any network accesses to anything other than the PREMIRROR would fail.
             </para>
             <para>
                 Poky also honors the standard shell environment variables 
                 <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
                 <filename>https_proxy</filename>, and <filename>all_proxy</filename>
                 to redirect requests through proxy servers.
             </para>
        </answer>
    </qandaentry>
</qandaset>
</appendix>
<!-- 
vim: expandtab tw=80 ts=4 
-->